Tuesday, December 26, 2006

Making Risk Measures Agree with Accounting 100%

In my consulting experience, there are clients that use risk software to compliment financial reporting (accounting). Instead of being used solely by the risk department, even financial controllers use it. This is due to the current trend of making financial reporting reflective of the firm's economic value based on the risks it is taking (IAS 39 and even Basel II). As a consequence, they expect the results form the risk software to be consistent with accounting results to the last cent. I guess this is the ideal state that everyone wants to achieve but is this really necessary?

Though related, I believe that risk measurement and accounting are serving different purposes. Risk measurement need not be exact because of the uncertainty of risk. Because of the future-centric nature of risk measurement, generalizations and simplifications in the models are made and may not necessarily result into exact market values, etc. In risk measurement, benchmark results are acceptable as long as they are reasonable (where you can see the degree of sensitivity to different types of risks). So what is important in risk measurement is not the valuation of your positions to the exact cent but the model on how this value reacts with different types of risk. Contrary to risk measurement, accounting focuses on past performance. People tend to be very meticulous in this field to the point that they want things to be correct to the last cent. This is because in most organizations, even in today's banks, profit and loss (past performance) is still more important.

Nowadays, with all the innovation in software and the computing power of currently availabe hardware, people tend to assume that risk software can double as accounting software. But in reality, these two fields have different requirements (although they may be similar in some ways). It is true that a software can be made flexible enough to accommodate both requirements. Results may not be exact but good enough. But getting values to agree with the accounting system would result into more computing time due to the increase in inputs, variables, and complexity of models. Is the additional cost justifiable given that additional benefit is only to reconcile a few dollars and cents? Probably not today but probably (and hopefully) in the near future when hardware specs get better while prices get cheaper.

Tags:

Model Validation - Not Just for Quants

In an article recently published in the ERisk Monthly Newsletter, it is stated that model validation is not a purely quantitative endeavor. Below is a quote from the article.

Model validation is often thought of as a rather technical and mathematical exercise. However, bank losses from model risk are often caused by poor governance of the wider modeling process, or by a poor understanding of the assumptions and limitations surrounding the model results, rather than by errors in equations.


The growing importance of models in helping executives answer some of banking’s most critical questions – from compliance and capital adequacy to business performance and risk-adjusted compensation – suggests that model validation is too important to be narrowly defined or left to the “quants”.


For both best practice and regulatory compliance reasons, senior bank executives must begin to take a more commanding role in ensuring that model validation is aligned with the overall interests of the bank – and that the bank’s investment in sound risk modeling can be easily communicated and proved to third parties.


Tags: