Credit Risk Stress Testing Framework
01. August 2018
What did we solve
A frequent and significant exercise for banks is to simulate scenarios of future developments and their impact on the portfolio. These stress test scenarios are also time-defined by the regulators. One of them is the stress test required by EBA in 2018 (https://www.eba.europa.eu/-/eba-publishes-2018-eu-wide-stress-test-results).
Similar assignments are often ad-hoc resolutions using different single-purpose scripts and calculations that are essentially discarded upon completion. For this reason, a clear assignment has emerged in the use of open technologies, reliability and transparency. First of all, reusability for all similar exercises, whether defined by the controller, or for the internal use of the bank was crucial.
What was our solution
To make these tests more effective and automated, we have created a framework made up of several independent modules and a domain specific language that defines individual scenarios. The first task of a new framework, simply called Credit Risk Management (CRM), was the implementation of the EBA 2018 stress tests. All modules had to meet the above criteria and, moreover, required maximal efficiency, because simulations lead to calculations on a much larger number of portfolios than in production RWA or ECL.
IFRS9 Provisions calculation
We have already created this module for other purposes in the past. However, a number of changes had to be made - taking into account the specificities of the simulations. Specific requirements were solved using runtime switches.
Risk Weighted Assets
Another of the risk parameters monitored is the RWA for which we have created a separate module. The module implemented a standard RWA (STD and IRB approach) calculation over the data model we defined for the entire CRM product.
The component is in charge of simulating portfolio development based on defined forecasting models. The simulation is driven by scenarios and transformation matrices for individual parts of the portfolio. Matrices are stored in a user-definable database.
It is able to interpret the defined configuration, aggregate the results of the calculations and insert them into the prepared template in MS Excel.
All components use a central database based on MongoDB as a single storage. This database is accessible to both independent systems and user-defined modules within the CRM. User-defined modules. Except for our standard modules, the user is able to create their own transformation procedures and calculations that can be incorporated into simulation scenarios.
To define the scenarios, we have created a simulation language in which the user is able to transparently run individual components and pass on the outputs of previous calculations or other parameters. It is basically set of functions within Apache Groovy language, so the user can use all language constructs - variables, cycles, exception handling, etc. With this language, it is possible to define a complete scenario that is then run by the system. Writing scenarios does not require programming experience and can be handled by every user who went through on-boarding i.e. business analytics.
How did it end up?
EBA 2018 stress tests are a complicated exercise that requires several domains expert’s co-operation. Our CRM framework has proven to be powerful and flexible enough to be able to implement dynamic requirements without changing its architecture.
The most important output for us is that the framework will be deployed for further simulations and stress tests, which means, in the long term, that its development has paid off.