Internal Capital Adequacy Assessment Process (ICAAP): Prevention and Limitation of Model Risks

2 mins read

Internal models used in the Internal Capital Adequacy and Assessment Process (ICAAP) exposes the bank to model risk. This post discusses some of the ways in which this risk may be avoided or limited. It is based on the paper “Model Risk” by Emanuel Derman (Quantitative Strategies Research Notes – April 1996).

Prevention / Limitation of Model Risks

  • All those involved in the process must have knowledge of all the areas of the model building process so that errors can be detected and diagnosed at an early stage. The modelers, computer programmers and users of the computerized model should be able to work closely so that each understands the other’s work processes. This ensures that errors are noticed immediately. There should be a strategy in place between all those involved for testing the model and identifying its limitations. All those involved should be invested in the model building process and take pride of ownership in their work.
  • The model should be able to be solved for, for simple cases with known solutions. The results from the model should match exactly with the known solution.
  • Certain models are derived from older or simpler models. In certain instances the behaviour of and solutions from these new models should match those of the older simpler models. These instances are known as its boundaries. The model should be tested to ensure that besides working for the new features being modelled it also works well for these boundary cases.
  • Small discrepancies in the model should not be ignored because they could be a signal to more significant errors in the model.
  • It is important that the user interface for the model be flexible and friendly. Usually graphical depictions of the results are useful in identifying outliers and possible errors in the model.
  • The model should be released to the users and clients in an orderly fashion. It should first be tested thoroughly by the developers who built it, then released to other developers and then to the users. By the time the program reaches the intended end-user the intention of this slow release process is that most of the errors in the system have been identified and resolved.

We have looked at some ways in which model risks may be avoided or limited. In the next post we will look at one methodology of modeling/ calculating Probability of Default (PD), an important parameter in the quantification of Credit Risk.

Comments are closed.