# 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.

<!--
Guidance: How to use this template
- This is the policy layer. Procedures (validation methodology,
  monitoring thresholds, inventory workflow) sit below it and may change
  without board approval as long as they stay within this policy.
- Fill section 2 (scope and model definition) and section 5 (tiering)
  first. Every later requirement scales with the tier, so a vague
  tiering method makes the rest of the policy unenforceable.
- SR 26-2 is risk-based and states that it sets no enforceable
  standards; it is expected to be most relevant to banking
  organisations with more than USD 30 billion in total assets. Do not
  copy fixed cycles from older policies (for example "validate every
  model every year") unless the bank chooses them as its own rule.
- Generative AI and agentic AI models are outside the scope of
  SR 26-2. Govern them under the AI policy and cross-reference it in
  section 11; do not leave them ungoverned.
- Related documents: Model Development Document
  (`finance/model-development-document`), Model Validation Report
  (`ai-data/model-validation-report`), Model Card
  (`ai-data/model-card`), Model Monitoring Plan
  (`ai-data/model-monitoring-plan`), VaR Backtesting Report
  (`finance/var-backtesting-report`), ECL Methodology
  (`finance/ecl-methodology`), Risk Appetite Statement
  (`finance/risk-appetite-statement`), AI Risk Assessment
  (`ai-data/ai-risk-assessment`), GenAI Risk Profile
  (`ai-data/genai-risk-profile`).
-->

## Document control

<!-- Guidance: The board or its risk committee approves the policy; the chief risk officer owns it. Record the minute reference so supervisors can trace the approval. -->

| Field | Value |
|---|---|
| Document ID | [MRM-POL-001] |
| Institution and scope | [Legal entity, LEI, consolidated group, branches] |
| Version | [1.0] |
| Status | [Draft / In review / Board approved / Superseded] |
| Owner | [@chief-risk-officer] |
| Policy administrator | [@head-of-model-risk-management] |
| Approvers/reviewers | [@board-risk-committee-chair], [@chief-financial-officer], [@head-of-internal-audit], [@head-of-compliance] |
| Approving body and minute reference | [Board risk committee, minute BRC-YYYY-NN] |
| Effective date | YYYY-MM-DD |
| Next scheduled review | YYYY-MM-DD (at least annually) |
| Last updated | YYYY-MM-DD |
| Classification | [Internal] |
| Supervisory frameworks considered | [SR 26-2 / PRA SS1/23 / ECB guide to internal models / national] (SS1/23 applies to UK-authorised firms; keep it only if the group has a UK entity) |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Head of model risk management (drafts) | [@name] | [Submit] | YYYY-MM-DD |
| Chief risk officer (recommends) | [@name] | [Recommend] | YYYY-MM-DD |
| Board risk committee (approves) | [@name] | [Approve / Approve with conditions] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@author] | First draft |
| 1.0 | YYYY-MM-DD | [@author] | Approved by the board risk committee |
| [2.0] | 2026-10-25 | [@author] | [Example: replaced SR 11-7 references with SR 26-2, OCC Bulletin 2026-13 and FDIC FIL-15-2026; removed fixed annual validation cycle; added GenAI exclusion and AI policy link; updated to the July 2025 revision of the ECB guide to internal models] |

## Contents

- [1. Purpose and principles](#1-purpose-and-principles)
- [2. Scope and model definition](#2-scope-and-model-definition)
- [3. Roles and responsibilities](#3-roles-and-responsibilities)
- [4. Model inventory](#4-model-inventory)
- [5. Model risk tiering](#5-model-risk-tiering)
- [6. Development and documentation standards](#6-development-and-documentation-standards)
- [7. Independent validation](#7-independent-validation)
- [8. Ongoing monitoring and outcomes analysis](#8-ongoing-monitoring-and-outcomes-analysis)
- [9. Model use, limitations and overlays](#9-model-use-limitations-and-overlays)
- [10. Vendor and other third-party models](#10-vendor-and-other-third-party-models)
- [11. AI, machine learning and generative AI](#11-ai-machine-learning-and-generative-ai)
- [12. Model changes and decommissioning](#12-model-changes-and-decommissioning)
- [13. Issue management](#13-issue-management)
- [14. Reporting, risk appetite and policy exceptions](#14-reporting-risk-appetite-and-policy-exceptions)
- [15. Regulatory mapping](#15-regulatory-mapping)
- [16. Glossary and references](#16-glossary-and-references)
- [Standard and licence note](#standard-and-licence-note)

## 1. Purpose and principles

<!-- Guidance: State why the policy exists in the bank's own terms and list the few principles that guide every later decision. Pitfall: a purpose section that restates the supervisory guidance instead of committing the bank to outcomes. -->

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

<!-- Guidance: The model definition decides what enters the inventory. Too wide and the inventory fills with spreadsheets; too narrow and material estimates escape control. Pitfall: excluding a calculation because it lives in a spreadsheet; the tool does not matter, the method does. -->

### 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.

| Candidate | Decision | Reason |
|---|---|---|
| Retail mortgage PD scorecard *(Example)* | Model | Statistical estimate used for capital and pricing |
| Fee calculation in core banking *(Example)* | Not a model | Deterministic arithmetic |
| Transaction monitoring scenario rules *(Example)* | Not a model at runtime; threshold tuning study is a model | Thresholds derived statistically |
| Customer service GenAI assistant *(Example)* | Outside this policy; governed by the AI policy | Generative AI is outside SR 26-2 scope (see section 11) |

## 3. Roles and responsibilities

<!-- Guidance: Name roles, not people, and make the three lines visible. Supervisors look for conflicts of interest between development and validation reporting lines. Pitfall: model owners who are also the only validators of their own models. -->

| Role | Responsibilities |
|---|---|
| Board and board risk committee | Approve this policy and the model risk appetite; receive model risk reporting at least [quarterly]; ensure enough resources and expertise for model risk management |
| Senior management and model risk committee | Implement the policy; approve Tier 1 models for use; decide on use of models with open high-severity findings; approve exceptions within delegated limits |
| Model owner (first line) | Accountable for the model's purpose, performance and appropriate use; keeps the inventory entry current; funds remediation |
| Model developer (first line) | Builds the model to the standards in section 6; documents data, method, assumptions, limitations and testing |
| Model user (first line) | Uses the model within approved purpose and limitations; reports unexpected outputs; applies approved overlays only |
| Model risk management (second line) | Owns this policy and the inventory; sets tiering; plans and performs or oversees validation; reports aggregate model risk |
| Validators (second line, internal or external) | Independent review of conceptual soundness, data, implementation and outcomes; issue findings and a validation rating |
| Internal audit (third line) | Assesses whether model risk management is rigorous and effective and whether the policy is applied; does not duplicate validation |
| Data owners | Ensure input data quality and lineage for models that use their data |
| Compliance and legal | Advise on fair lending, consumer protection, AI and data protection requirements affecting models |

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

<!-- Guidance: The inventory is the backbone of the policy. Define mandatory fields and who keeps each one current. Pitfall: an inventory updated once a year for the audit, which is out of date for the other eleven months. -->

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

| Field | Description | Maintained by |
|---|---|---|
| Model ID | Unique ID, format MOD-NNN | Model risk management |
| Name and version | Name and current version | Model owner |
| Purpose and uses | Approved uses, including regulatory uses | Model owner |
| Model type and method | For example logistic regression, simulation, gradient boosting | Developer |
| Owner, developer, primary users | Named roles and units | Model owner |
| Tier | Tier from section 5, with scoring | Model risk management |
| Status | In development / Approved / Approved with conditions / In use under exception / Retired | Model risk management |
| Upstream and downstream dependencies | Models and data feeding it, models it feeds | Developer |
| Data sources | Systems and datasets | Developer |
| Vendor | Name and product, if third-party | Model owner |
| Last validation date and rating | Date and outcome | Model risk management |
| Next validation due | Date from the risk-based plan | Model risk management |
| Open findings | Count by severity, with IDs | Model risk management |
| Limitations and overlays | Short list with references | Model owner |
| Regulatory permission | Supervisory approval reference for internal models | Model owner |

### 4.2 Inventory extract

| Model ID | Name | Use | Owner | Tier | Last validation | Rating | Next due |
|---|---|---|---|---|---|---|---|
| MOD-001 *(Example)* | Retail mortgage PD v3.0 | IRB own funds, pricing | Head of retail credit risk | 1 | 2026-03-31 | Satisfactory with findings | 2027-03-31 |
| MOD-002 *(Example)* | IFRS 9 ECL macroeconomic module | Impairment | Head of credit risk modelling | 1 | 2025-11-30 | Satisfactory | 2027-11-30 |
| MOD-003 *(Example)* | Historical simulation VaR | Market risk limits | Head of market risk | 2 | 2025-06-30 | Satisfactory | 2027-06-30 |
| MOD-004 *(Example)* | Non-maturity deposit behavioural model | IRRBB | Head of ALM | 2 | 2025-09-30 | Needs improvement | 2026-12-31 |
| MOD-005 *(Example)* | Card fraud score (vendor) | Fraud detection | Head of fraud operations | 2 | 2026-01-31 | Satisfactory | 2027-07-31 |
| MOD-006 *(Example)* | TM threshold tuning study | AML alert thresholds | MLRO | 3 | 2026-05-31 | Satisfactory | 2028-05-31 |

## 5. Model risk tiering

<!-- Guidance: Tiering combines materiality (how much rides on the model) with inherent risk (how likely it is to be wrong). Publish the scoring so that owners can predict their tier. Pitfall: tiering on complexity alone, which puts a simple but critical capital model in a low tier. -->

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

| Factor | Low (1) | Medium (2) | High (3) |
|---|---|---|---|
| Exposure | Portfolio or decision value below [EUR 100 million] | [EUR 100 million to 1 billion] | Above [EUR 1 billion] |
| Purpose | Internal analysis, no direct decision | Business decision, pricing, limits | Regulatory capital, financial reporting, regulatory submission |
| Customer impact | None | Indirect | Direct decisions about individual customers |

Materiality is the highest of the three factor scores.

### 5.2 Inherent risk score

| Factor | Low (1) | Medium (2) | High (3) |
|---|---|---|---|
| Complexity | Transparent, few variables | Moderate | Highly non-linear, opaque, or many interacting components |
| Assumptions | Few and well supported | Several, partly judgemental | Many or highly judgemental |
| Data | Long, clean, relevant history | Gaps or proxies | Short, low-default or unrepresentative history |
| Interconnection | Stand-alone | Feeds one other model | Feeds several material models |

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

### 5.3 Tier matrix

| Materiality \ Inherent risk | Low (1) | Medium (2) | High (3) |
|---|---|---|---|
| High (3) | Tier 2 | Tier 1 | Tier 1 |
| Medium (2) | Tier 3 | Tier 2 | Tier 1 |
| Low (1) | Tier 3 | Tier 3 | Tier 2 |

*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

<!-- Guidance: Set what every development must produce, scaled by tier. The detailed outline sits in the Model Development Document template. Pitfall: documentation written after approval to satisfy validation, which records what the model does rather than why. -->

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.

| Requirement | Tier 1 | Tier 2 | Tier 3 |
|---|---|---|---|
| Full development document | Required | Required | Short form allowed |
| Benchmark or challenger model | Required | Recommended | Not required |
| Sensitivity analysis of key assumptions | Required | Required | Recommended |
| User involvement and sign-off of purpose | Required | Required | Required |
| Model card summary | Required | Required | Recommended |
| Code under version control with peer review | Required | Required | Required |

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

## 7. Independent validation

<!-- Guidance: Validation must be risk-based in scope and timing. SR 26-2 does not prescribe a fixed annual cycle; the bank sets its own schedule and justifies it. Pitfall: deep validation of every low-tier model on a fixed cycle while Tier 1 reviews slip. -->

### 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.

| Tier | Full revalidation (bank rule) *(Example)* | Interim review *(Example)* | Trigger events that bring validation forward |
|---|---|---|---|
| Tier 1 | At least every [24] months | Annual review of monitoring results and open findings | Material change, monitoring breach, new use, regulatory request |
| Tier 2 | At least every [36] months | Review of monitoring every [12] months | As Tier 1 |
| Tier 3 | Every [48] months or on material change | Owner attestation every [12] months | Material change or monitoring breach |

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

| Rating | Meaning | Use consequence |
|---|---|---|
| Satisfactory | Fit for purpose, minor or no findings | Approved for use |
| Satisfactory with findings | Fit for purpose with findings to fix by set dates | Approved with conditions |
| Needs improvement | Material weaknesses; usable only with overlays or restrictions | Conditional use approved by the model risk committee |
| Unsatisfactory | Not fit for purpose | Use stopped or replaced; exception only by the committee for a set period |

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

<!-- Guidance: Monitoring tells the bank, between validations, whether the model still works in current conditions. Define metrics and thresholds at development, not after the first breach. Pitfall: monitoring reports that show breaches every month with no action because no one owns the response. -->

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.

| Metric family | Typical metrics | Frequency (Tier 1) *(Example)* | Amber and red thresholds *(Example)* |
|---|---|---|---|
| Discrimination | Gini, AUC, KS | Quarterly | Gini drop of more than 5 points amber, 10 points red (model-specific thresholds in the development document prevail) |
| Calibration | Observed versus predicted default rate, binomial test | Quarterly | Red if the test rejects at the 99% level in two consecutive quarters |
| Stability | Population stability index (PSI) | Monthly | 0.10 amber, 0.25 red |
| Back-testing (market risk) | VaR exceptions | Daily, reported quarterly | As per the regulatory zone framework |
| Overrides | Override rate and direction | Monthly | [5%] to [10%] amber, above [10%] red (as for MOD-001) |
| Input data quality | Missing values, out-of-range values | Each run | As per data quality rules |

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

<!-- Guidance: Most model losses come from misuse rather than wrong mathematics. Define approved use precisely and govern every adjustment to output. Pitfall: management overlays that become permanent and are never validated. -->

### 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.

| Overlay size relative to model output *(Example)* | Approver |
|---|---|
| Below 5% | Model owner, notified to model risk management |
| 5% to 15% | Model risk committee |
| Above 15% or affecting regulatory capital | Model risk committee and chief risk officer, reported to the board risk committee |

*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

<!-- Guidance: Buying a model does not transfer its risk. The bank must understand and validate vendor models with the information it can obtain. Pitfall: accepting the vendor's own validation report as the bank's validation. -->

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

<!-- Guidance: State clearly which AI systems this policy covers and which are covered by the AI policy. Gaps between the two policies are where unmanaged risk accumulates. Pitfall: assuming that a GenAI tool needs no control because SR 26-2 excludes it. -->

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

<!-- Guidance: Define what counts as a material change so that owners know when validation is needed. Pitfall: many small "non-material" changes that together transform the model without review. -->

| Change class | Examples | Required before production |
|---|---|---|
| Material | New method, new variables, new segment or use, recalibration of a Tier 1 model, vendor major release | Validation of the change; approval at the tier's approval level; for internal models used for own funds, check whether supervisory approval or notification is required |
| Non-material | Recalibration of a Tier 2 or 3 model within the approved method, code refactoring with identical outputs | Developer testing, model risk management review, inventory update |
| Administrative | Documentation corrections, owner change | Inventory update |

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

<!-- Guidance: Findings from validation, monitoring, audit and supervisors go into one register with consistent severities and due dates. Pitfall: separate lists per source, each looking small, that together show a model nobody should rely on. -->

| Severity | Definition | Maximum remediation period *(Example)* | Escalation if overdue |
|---|---|---|---|
| High | Could lead to materially wrong decisions, reporting or capital | [6] months | Model risk committee and board risk committee |
| Medium | Weakness that could affect outputs under some conditions | [12] months | Model risk committee |
| Low | Improvement with limited impact | [18] months | Model owner and model risk 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.

| Finding ID | Model | Source | Severity | Owner | Due | Status |
|---|---|---|---|---|---|---|
| MRF-2026-011 *(Example)* | MOD-001 | Validation 2026-03 | Medium | Head of retail credit risk | 2027-01-31 | Open |
| MRF-2026-014 *(Example)* | MOD-004 | Monitoring breach | High | Head of ALM | 2026-12-31 | Overlay in place |

## 14. Reporting, risk appetite and policy exceptions

<!-- Guidance: The board needs an aggregate picture, not a list of models. Pitfall: reports that count validations completed but never show where model risk is concentrated. -->

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.

| Model risk appetite metric *(Example)* | Limit | Current |
|---|---|---|
| Tier 1 models in use without a current validation | 0 | 0 |
| High-severity findings overdue | 0 | 0 |
| Tier 1 models rated Needs improvement or worse | At most 1 | 0 |
| Overlays older than 12 months | At most 2 | 1 |

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

<!-- Guidance: Show supervisors where each expectation is met. Cite names, numbers and dates only; obtain the source for the normative text. Pitfall: mapping to superseded guidance such as SR 11-7 after 2026-04-17. -->

| Framework | Element (by number or name) | Policy section |
|---|---|---|
| SR 26-2 / OCC Bulletin 2026-13 / FDIC FIL-15-2026 (2026-04-17) | Purpose and scope, model definition and exclusions | 2 |
| SR 26-2 | Overview of model risk (inherent risk, exposure, purpose, materiality, aggregate risk, effective challenge) | 1, 5 |
| SR 26-2 | Model development and model use | 6, 9 |
| SR 26-2 | Model validation (conceptual soundness, outcomes analysis) and ongoing monitoring | 7, 8 |
| SR 26-2 | Governance and controls (roles, internal audit, inventory, documentation) | 3, 4, 13, 14 |
| SR 26-2 | Vendor and other third-party products | 10 |
| PRA SS1/23 Principle 1 | Model identification and model risk classification | 2, 4, 5 |
| PRA SS1/23 Principle 2 | Governance | 3, 14 |
| PRA SS1/23 Principle 3 | Model development, implementation and use | 6, 9, 12 |
| PRA SS1/23 Principle 4 | Independent model validation | 7 |
| PRA SS1/23 Principle 5 | Model risk mitigants | 8, 9, 13 |
| ECB guide to internal models (revised 28 July 2025), overarching principles chapter | Internal governance, internal validation, internal audit, model use, machine learning, third-party involvement | 3, 7, 9, 10, 11 |
| CRR (Regulation (EU) No 575/2013 as amended), IRB requirements | Validation of internal estimates (Article 185) and default definition (Article 178) for IRB models | 7, and the development document |

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

<!-- Guidance: Keep definitions aligned with the inventory and the validation methodology. -->

| Term | Meaning in this policy |
|---|---|
| Model risk | Potential for adverse consequences from decisions based on incorrect or misused model outputs |
| Materiality | Importance of a model, from its exposure and purpose |
| Inherent risk | Likelihood that a model is wrong, from complexity, assumptions and data |
| Effective challenge | Critical analysis by objective, competent people with the standing to require change |
| Overlay | Adjustment to model output outside the model's own logic |
| Outcomes analysis | Comparison of model outputs with realised outcomes |
| Tier | Category from section 5 that sets the depth of oversight |
| Vendor model | Model, data or parameters supplied by a third party |

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.