Model Risk Management Policy Template (SR 26-2, PRA SS1/23)

Model Risk Management Policy: [Institution name]

Board-approved policy that defines what a model is, who is accountable for model risk, how models are inventoried and tiered, and the standards for development, validation, ongoing monitoring, use, third-party models, limitations and overlays, issue management and reporting. It follows the US interagency Revised Guidance on Model Risk Management of 2026-04-17 (Federal Reserve SR 26-2, OCC Bulletin 2026-13, FDIC FIL-15-2026), which superseded SR 11-7 (2011) and SR 21-8 (2021); the PRA Supervisory Statement SS1/23 (Model risk management principles for banks, effective 2024-05-17, five principles cited by number and name); and the ECB guide to internal models (revised version of 28 July 2025, reflecting CRR3 and adding machine-learning expectations) for institutions using internal models for own funds. Replace every [bracketed] value and every row marked Example. The worked example uses the fictional Fernhollow Bank, a mid-sized EU credit institution with a US branch. This is a document format, not legal, regulatory or risk advice. Obtain the guidance or regulation for the normative text.

Document control

Approvals

Revision history

Contents

• 1. Purpose and principles
• 2. Scope and model definition
• 3. Roles and responsibilities
• 4. Model inventory
• 5. Model risk tiering
• 6. Development and documentation standards
• 7. Independent validation
• 8. Ongoing monitoring and outcomes analysis
• 9. Model use, limitations and overlays
• 10. Vendor and other third-party models
• 11. AI, machine learning and generative AI
• 12. Model changes and decommissioning
• 13. Issue management
• 14. Reporting, risk appetite and policy exceptions
• 15. Regulatory mapping
• 16. Glossary and references
• Standard and licence note

1. Purpose and principles

This policy sets out how [Institution name] identifies, measures, controls and reports model risk: the risk of adverse consequences from decisions based on model outputs that are wrong or misused. It applies across the model lifecycle, from the first idea for a model to its retirement.

The bank commits to the following principles:

1. Proportionality. The effort spent on a model matches its materiality and inherent risk. Low-tier models receive lighter treatment so that resources concentrate where errors would hurt.
2. Effective challenge. Every material model is challenged by people with the expertise, independence and standing to require change.
3. Transparency of limitations. Every model has documented limitations, and users know them before they rely on the output.
4. Single source of truth. All models in scope are in one inventory that drives validation planning, monitoring and reporting.
5. Accountability. Each model has a named owner who is accountable for its performance and appropriate use.
6. Aggregate view. Model risk is assessed for individual models and in aggregate, including shared data, shared assumptions and chains of models feeding each other.

The policy supports the bank's risk appetite for model risk in the Risk Appetite Statement (finance/risk-appetite-statement) and the internal capital assessment in the ICAAP Report (finance/icaap-report).

2. Scope and model definition

2.1 Entities and activities in scope

This policy applies to [all entities of the group, including branches and subsidiaries]. Local requirements that are stricter apply in addition.

Example: Fernhollow Bank, a significant institution supervised directly by the ECB, applies the policy to the head office in the EU, its two EU subsidiaries (leasing and payments) and its New York branch. For the US branch the bank also considers SR 26-2 where its US supervisor expects it, noting that the guidance is expected to be most relevant to banking organisations above USD 30 billion in total assets and may be relevant below that threshold when model use is significant.

2.2 Definition of a model

For this policy, a model is a quantitative method, system or approach that applies statistical, economic, financial or mathematical theory and assumptions to transform input data into quantitative estimates used for decisions, reporting or risk management. A model has three parts: inputs, a processing component that applies the theory, and an output used by the business.

The following are not models under this policy but are governed as end-user computing tools or IT applications: simple arithmetic calculations, deterministic rule-based processes and software that does not rest on statistical, economic or financial theory. This is deliberately wider than the SR 26-2 definition, which refers to complex quantitative methods based on statistical, economic or financial theory; the bank also captures simpler and mathematical methods so that tiering, not the definition, decides how much governance applies. The exclusions follow SR 26-2. When a rule-based process uses thresholds that were set by statistical analysis (for example, transaction monitoring thresholds tuned on historical alert outcomes), the tuning analysis is in scope as a model even if the runtime rules are not.

2.3 Model identification

Business units must notify model risk management of any new method that may meet the definition before it is used for decisions. Model risk management decides whether it is a model and records the decision. Disputed decisions go to the model risk committee.

3. Roles and responsibilities

Independence of validation means that validators do not report to the model owner or developer, are not paid on the results of the models they review, and have authority to escalate findings to the model risk committee. SR 26-2 places the emphasis on the rigour and effectiveness of the review rather than on organisational structure, so a small bank may use qualified staff from another unit or an external firm, provided that model risk management oversees and integrates their work.

4. Model inventory

Model risk management maintains one inventory covering models in development, in use, and retired within the last [five] years. Model owners must update their entries within [10] business days of any change. The inventory supports the individual and aggregate view of model risk and must hold enough information to understand each model's risks.

4.1 Mandatory fields

4.2 Inventory extract

5. Model risk tiering

Tier each model by combining two assessments. SR 26-2 describes materiality as the product of exposure (the size of the decisions or portfolios that depend on the output) and purpose (for example, regulatory and financial risk uses weigh more), and inherent risk as driven by assumptions, complexity, input quality and data constraints. PRA SS1/23 Principle 1 also expects a model risk classification. The bank's method is as follows.

5.1 Materiality score

Materiality is the highest of the three factor scores.

5.2 Inherent risk score

Inherent risk is the rounded average of the four factor scores.

5.3 Tier matrix

Example: MOD-001 has materiality 3 (regulatory capital) and inherent risk scores of 2 (complexity), 2 (assumptions), 2 (data) and 3 (feeds ECL, pricing and stress testing). The average is 2.25, rounded to 2, so the model sits at materiality High and inherent risk Medium, which is Tier 1.

Model risk management may raise a tier by judgement and must record the reason. Lowering a tier below the matrix result requires model risk committee approval.

6. Development and documentation standards

Development starts with a clear statement of purpose and intended use, agreed with the model owner and key users. SR 26-2 treats this as the basis for choosing data, methods and tests. Developers then document the work in the Model Development Document (finance/model-development-document), which must cover, at a depth proportionate to the tier:

1. purpose, scope, users and intended uses, with uses that are not permitted;
2. theory and design choices, including alternatives considered and why they were rejected;
3. data sources, definitions, quality checks, exclusions and their effect;
4. methodology, estimation and calibration;
5. key assumptions and expert judgements, each with support;
6. developmental testing: performance, stability, sensitivity, out-of-sample and out-of-time testing, and benchmarking;
7. limitations and their mitigants;
8. implementation and user acceptance testing;
9. the ongoing monitoring plan with metrics and thresholds.

Use the Model Card (ai-data/model-card) as the short summary that travels with the model to users and committees.

7. Independent validation

7.1 Scope of validation

Validation assesses whether a model performs as intended and identifies its limitations. It covers, in proportion to tier:

• conceptual soundness: design, theory, assumptions, judgements, data selection and developmental evidence;
• data: relevance, quality, representativeness and lineage;
• implementation: whether the production code and process match the documented design, including input feeds and output use;
• outcomes analysis: comparison of outputs with realised outcomes, including back-testing, benchmarking and outlier analysis;
• the ongoing monitoring plan and its thresholds;
• use: whether actual use matches the approved purpose.

Validators record results in the Model Validation Report (ai-data/model-validation-report). For market risk internal models, the back-testing evidence is documented in the VaR Backtesting Report (finance/var-backtesting-report).

7.2 Timing and frequency

Validation normally takes place before first use. A model may be used before validation completes only for an urgent business need, with model risk committee approval, documented limitations, communicated restrictions and compensating controls such as usage limits or closer monitoring. The exception expires on a set date.

After first use, model risk management sets the next validation date for each model based on tier, the size and frequency of changes, monitoring results, data limitations and supervisory expectations.

The intervals above are the bank's own choice and must be justified in the validation plan. Supervisory requirements for internal models used for own funds (for example, CRR requirements for IRB validation and the ECB guide to internal models chapter on internal validation) may require annual validation activities for those models; where they do, they prevail.

7.3 Validation ratings and findings

Findings carry a severity (High, Medium, Low), an owner and a due date and are tracked under section 13.

8. Ongoing monitoring and outcomes analysis

Every model in use has an ongoing monitoring plan that defines metrics, thresholds, frequency and the response to a breach. The plan is part of the development document and is reviewed by validation. Use the Model Monitoring Plan (ai-data/model-monitoring-plan) as the detailed format.

When a metric turns red, the model owner investigates within [20] business days and proposes a response: no action with justification, an overlay, recalibration, or redevelopment. Model risk management approves the response and may bring validation forward. SR 26-2 links deterioration directly to overlays, adjustment or redevelopment under the bank's policy, so the response must be documented, not implied.

9. Model use, limitations and overlays

9.1 Approved use

A model may be used only for the purposes recorded in the inventory. Extending a model to a new portfolio, product, geography or decision requires a use assessment by the owner, review by model risk management, and, for Tier 1 and Tier 2, validation of the new use before it starts.

9.2 Limitations

Each model's limitations are recorded in the development document, the model card and the inventory. Users must confirm that they have read the limitations before access is granted to Tier 1 model outputs.

9.3 Overlays and post-model adjustments

An overlay is any adjustment to model output outside the model's own logic. Every overlay must have:

• a reason linked to a known limitation or monitoring result;
• a quantified amount and a method that can be reproduced;
• an approver at the level set in the delegation table below;
• an expiry or review date, and a plan to remove it by fixing the model.

Example: For MOD-004 (deposit behavioural model) monitoring showed faster outflows of non-maturity deposits after rate rises. The ALM team applied an overlay shortening the modelled duration of core deposits, approved by the model risk committee with an expiry on 2026-12-31, the date of the planned redevelopment.

10. Vendor and other third-party models

Vendor models, vendor data and parameters, and models built by consultants follow this policy in full. Before purchase, the model owner obtains from the vendor enough information to assess conceptual soundness, development data, performance and limitations, and secures contractual rights to documentation, change notices, and support for validation and audit. Where the vendor withholds code or data as proprietary, validation relies more on outcomes analysis, benchmarking and sensitivity testing on the bank's own data, and the validation report records the limitation.

Customisations made by the bank or for the bank are documented, justified and validated as part of the model. Vendor releases are treated as model changes under section 12. Vendor models that support critical or important functions are also recorded in the DORA ICT Third-Party Register (compliance/dora-ict-third-party-register) and assessed under the outsourcing and third-party risk policies.

11. AI, machine learning and generative AI

Machine learning models that produce quantitative estimates (for example, gradient boosting for fraud detection or neural networks for pricing) are models under this policy and follow every section, with these additional expectations for Tier 1 and Tier 2: explainability analysis suitable to the use, testing for bias and fair treatment where outputs affect individual customers, and monitoring for drift.

Generative AI and agentic AI models are outside the scope of SR 26-2. The guidance states that institutions should still apply appropriate governance and controls to such tools, and the agencies announced, in the 2026 issuance (FDIC FIL-15-2026), a forthcoming request for information on AI models, including generative and agentic AI. The bank governs these systems under its AI policy and the AI Risk Assessment (ai-data/ai-risk-assessment) and GenAI Risk Profile (ai-data/genai-risk-profile) formats. When a GenAI system's output feeds a model in scope (for example, text extracted by an LLM used as an input variable), the model owner treats that output as a data source with its own quality controls.

For EU entities, also check obligations under Regulation (EU) 2024/1689 (AI Act). AI systems used to evaluate the creditworthiness of natural persons or establish their credit score are listed in Annex III as high-risk (check the exemption for fraud detection); check the consolidated text for the application date, which Article 113, as amended by Regulation (EU) 2026/1744, sets at 2 December 2027 for Annex III systems.

12. Model changes and decommissioning

Model risk management reviews the cumulative effect of non-material changes at each interim review. A retired model stays in the inventory with its retirement date, its replacement, and confirmation that production feeds and user access have been removed.

13. Issue management

Closure requires evidence reviewed by the party that raised the finding or by model risk management. Extensions require approval one level above the normal closure approver.

14. Reporting, risk appetite and policy exceptions

Model risk management reports to the model risk committee monthly and to the board risk committee at least [quarterly]. The report covers: the inventory by tier and status; validations completed and overdue; models in use under exception or with an Unsatisfactory or Needs improvement rating; open findings by severity and age; overlays in force and their total effect; monitoring breaches; and concentrations such as several Tier 1 models sharing one data source or one key assumption.

Exceptions to this policy require a written request with reason, duration, compensating controls and the owner's acceptance of the residual risk. The chief risk officer approves exceptions up to [six] months; longer exceptions go to the board risk committee. Model risk management keeps an exception log and reports it.

15. Regulatory mapping

The US agencies rescinded or superseded earlier documents when they issued the 2026 guidance: SR 11-7 and SR 21-8 (Federal Reserve), the Comptroller's Handbook booklet on model risk management and related OCC bulletins including 2021-19 on BSA/AML systems (OCC), and FIL-22-2017 and FIL-27-2021 (FDIC). Remove references to them from procedures and templates, and keep transaction monitoring systems within the general model risk framework described in this policy.

16. Glossary and references

References:

• Board of Governors of the Federal Reserve System, FDIC and OCC, Revised Guidance on Model Risk Management, SR 26-2 with attachment "Supervisory Guidance on Model Risk Management", 2026-04-17; OCC Bulletin 2026-13; FDIC FIL-15-2026 (US federal works, public domain).
• Prudential Regulation Authority, SS1/23 Model risk management principles for banks, effective 2024-05-17 (cited by name and principle number only).
• European Central Bank, ECB guide to internal models, revised version published 28 July 2025 (replaces the February 2024 version; press release ssm.pr250728).
• Regulation (EU) No 575/2013 as amended by Regulation (EU) 2024/1623, Articles 178 and 185. EUR-Lex.
• European Banking Authority, Guidelines on PD estimation, LGD estimation and treatment of defaulted assets (EBA/GL/2017/16).
• Regulation (EU) 2024/1689 (AI Act), Annex III and Article 113, as amended by Regulation (EU) 2026/1744. EUR-Lex.

Standard and licence note

Based on public-domain US federal guidance (Federal Reserve SR 26-2, OCC Bulletin 2026-13 and FDIC FIL-15-2026) and EU public law (Regulation (EU) No 575/2013 as amended and Regulation (EU) 2024/1689, EUR-Lex, reuse with acknowledgement). Structure also aligned with the PRA Supervisory Statement SS1/23 and the ECB guide to internal models, which are cited by name, number and chapter only; no text from them is reproduced. The ECB guide is used with attribution to the European Central Bank. All text is original. Fernhollow Bank and every model, figure and finding are fictional. Check the current official version of each guidance and regulation before use. Template licence: MIT.