3 See e.g. https://www.bbc.com/news/business-50365609, https://www.reuters.com/article/us-amazon-com-jobs-automation-insight/amazon-scraps-secret- ai-recruiting-tool-that-showed-bias-against-women-idUSKCN1MK08G and many more
4 https://www.oreilly.com/content/introduction-to-local-interpretable-model-agnostic-explanations- lime/
In addition, due to various regulatory initiatives, most notably TRIM in the EU, the scope of model risk management is increasing. Some examples include:
- Model monitoring, i.e. continuously verifying that the performance of models is not deteriorating. This is important to avoid the discovery of model failure after the facts
- Better policies for model calibration: Models are often re-calibrated on an ad-hoc basis. It is important to have a proper procedure in place to decide when, and how, model parameters are being updated, especially when part of the calibration dataset is illiquid
- Data quality: With the ever increasing need for more data (driven by the shift to more complex (ML) models), the need for high-quality large datasets is increasing continuously.
In search of efficiency
In the context of model risk management, the main challenges are cost and capital consumption.
The number of models in financial organizations is increasing by 10-25% yearly, and this is driven by the introduction of new regulatory requirements and accounting standards as well as the introduction of new types of models (such as ML-based algorithms). As an example of the former, the introduction of IFRS9 has caused a near duplication of the credit models in financial institutions. This is driven by certain requirements such as the fact that in IFRS9, credit models are point-in-time, taking into account the current position in the economic cycle, while IRB/Basel models are through-the-cycle, i.e. average credit risk across a long time period. An example of the latter is e.g. the use of a recommendation algorithm to suggest the best investment product to be marketed to a client. Even though the latter would (at least in the EU) not necessarily have to be regulatory validated, best practice suggests that these models have to be risk managed in exactly the same fashion. This gradual increase of the number of models in the model inventory leads to a continuous increase in costs.
Another cost-related challenge is the fact that many financial institutions are using legacy technology to support their MRM operations. However, due to the increased complexity of model risk as well as the fact that the structure of algorithms has changed over time, maintaining and customizing these legacy solutions is sometimes expensive. As an example, if a chatbot is introduced in a model inventory, it has several model components (such as algorithmic text preprocessing, word embeddings etc.). In addition, these components are typically derived from either a vendor or an open source engine and the same engine can be used in different applications. Although this is not entirely uncommon in more classical modelling applications, the emphasis on these features is stronger and these dependencies are often harder to encode in traditional model inventory applications.
A final driver for cost is the competition for quantitative talent that has shifted from traditional statistics towards data science. However, the need for data scientists has grown tremendously in other (high-tech) sectors which implies that financial institutions find it harder to compete for talent.
Regarding capital consumption, the main focus for banks is to either reduce capital add-ons or avoid them altogether by displaying sound model risk management to the regulators. A second point is to potentially reduce risk capital. Indeed, when computing market risk measures through VaR or Expected Shortfall (e.g. in the context of the IM for FRTB) the stability of the underlying pricing algorithms and market data generation models is crucial. If a curve generation algorithm is unstable in 0.5% of all cases, it will have a material impact on market risk. Good model risk management should lead to better models and therefore lower risk capital.
Requirements for technology
Given the current state of the MRM practice, it is natural that many organizations are looking at technology to meet the challenges that we highlighted in the previous chapter. In the current section we will now introduce two key requirements that have to be met by the technology choices made today.
Data-centricity
If we can gather all data related to MRM, we are able to transform the business. We believe two types of data are important: Analytics and Process related data.
Analytics related data
The first and most important data that is needed for efficient MRM is the so-called model execution trace, i.e. the data that is flowing through the models (model input, output and realization – see example below). For a given model, there are multiple types of datasets that are relevant:
- The development dataset: the data that was used during model development and on which the initial testing and documentation happened
- The calibration dataset: the dataset that was used to determine the best possible parameters for the model
- The execution dataset: the dataset providing a snapshot of how the model is functioning in production
Note that the execution dataset can be updated continuously, while the calibration dataset is most often amended at a lower frequency and the development dataset hardly changes. If these datasets are always available, we can monitor models very efficiently and also test accurately that e.g. the development and calibration datasets are still representative for the current use of the model.
If this data is available, model risk managers can compute data quality and model performance metrics. As these metrics should be computed regularly, the underlying calculations will generate an entirely new derived dataset. Such a dataset can then again be analyzed to automatically detect deviations from normal behavior. As an example, suppose we compute on a monthly basis the performance of a set of thousands of credit scoring algorithms. In that case we can run an outlier detection algorithm on these time series to detect sudden change in the normal performance of the model.
Finally, as explained earlier, many organizations use a model risk tier to indicate the amount of model risk carried by a particular model. Depending on the tier the depth and breath of the model validation and monitoring process will differ. Some institutions take this one step further and start to quantify model risk e.g. by monitoring the difference between the model in production and a family of benchmark models. Both model tiering and model risk quantification generate again time dependent data. Being able to use this data to create e.g. a heatmap of model risk across the organization will help executives and managers to understand risk concentration and focus efforts on certain parts of the model inventory.
In conclusion, being able to centralize and make available analytics related data will allow organizations to:
- Increase transparency of model risk across the model inventory
- Drive cultural change since model performance will be available to the different lines of defence
- Improve the overall quality of models
