While foundational elements such as the definition of a model and some overarching governance principles remain unchanged, some amendments have been made to the policy. Several elements that we consider particularly noteworthy include:
- Alterations to Principle 1.3 (c) to clarify that the choice of factors determining model complexity (for model tiering) is not prescriptive;
- Adjustments to Principle 2.2 to clarify the responsibilities of the Senior Management Function (SMF);
- Edits to Principle 3.3 to specifically include dynamic and cumulative small parameters adjustments (e.g. for ML models) as part of model change management.
In the PS6/23 document, the PRA has also clarified that the guidance in the policy will initially only apply to banks that have secured approval for their internal models intended for regulatory capital purposes. As the PRA advances its policy concerning simpler-regime firms, it will provide further guidance on how the MRM policy will be implemented for banks without internal model approvals.
Principle 2: Governance
- Principle 2.1 (a) and (b) -The MRM framework should be applicable company-wide but granular enough to understand idiosyncratic model risk aspects. Requirements should be a function of the model tier (e.g. to set validation and ongoing monitoring frequency).
- Principle 2.1 (d) – [WHAT?] Aggregate model risk measures (e.g. KPIs) should be available to feed the model risk appetite for informed management decisions. This will also lead to more robust reporting capabilities (which should also include monitoring reports – see Principle 4.4). [WHY?] KPIs for model risk are both qualitative (e.g. complexity) and quantitative (e.g. performance). Especially the quantitative measures may vary quickly, which puts strong emphasis on the need for proper monitoring reporting.
- Principle 2.4 – Roles and responsibilities are clearly defined, documented and enforced throughout the model lifecycle.
- Principle 2.6 (b) – Third-party vendor models are subject to the same MRM standards as internal models.
Principle 3: Model development, implementation and use
- Principle 3.1 – [WHAT?] Model purpose, modelling choices and model limitations should be defined and be transparent to model users. [WHY?] Many model risk incidents happen because model users rely on models that are not fit for purpose. This is why it is critical that model users are made aware about any known limitations of the model, and properly understand what use case the model has been created for.
- Principle 3.3 (b) and (c) – Performance tests should be defined and results should be made available, including for (cumulatively observed) material model changes.
- Principle 3.5 – Model development documentation should be kept up to date and should cover data, methodology, testing and limitations.
Principle 4: Independent model validation
- Principle 4.1 (b) and (c) – Both independent initial review and periodic re-validation are needed. The validation team also has shared responsibility for ongoing monitoring (e.g. reviewing results and requesting developers to further investigate).
- Principle 4.4 (c) and (d) – Model monitoring should include benchmarking (e.g. by running models in parallel), sensitivity analysis and outcome analysis. Regular reports should be produced.
Principle 5: Model risk mitigants
- Principle 5.2 – Usage restrictions should be defined and be transparent to users, and remediation of model issues should be tracked and follow an auditable process.
- Principle 5.3 – Temporary approvals for the usage of unvalidated models should be captured within an auditable process.
Share
