SR 11-7 vs SR 26-2 Model Validation: What Changes and What Evidence Examiners Will Expect

How SR 26-2 relates to SR 11-7

On April 17, 2026, the Federal Reserve, the OCC and the FDIC issued Revised Guidance on Model Risk Management, transmitted by the Federal Reserve as SR 26-2. It supersedes and replaces SR 11-7, issued April 4, 2011, and SR 21-8, issued April 9, 2021. Model risk programs cannot treat it as a patch on SR 11-7. Internal policies, procedures and validation templates that cite SR 11-7 or SR 21-8 now cite superseded documents.

The FDIC is also rescinding FIL-22-2017, its adoption of SR 11-7, and FIL-27-2021, the BSA/AML model risk statement. Model guidance that was once spread across several documents is now consolidated. The Federal Reserve's Bank Holding Company Supervision Manual has also been revised, in section 2126.0, to incorporate the new guidance.

The agencies say the revision reflects fifteen years of supervisory experience, industry feedback and advances in modeling practice. They describe the approach as risk-based and tailored to a banking organization's model risk profile and the size and complexity of its operations, and they state that practices appropriately vary among organizations. For validation teams, that wording matters most: a single standard of effort for every model is no longer the reference point.

Validation and monitoring: SR 11-7 and SR 26-2 compared

SR 11-7 built its framework around three core elements: evaluation of conceptual soundness including developmental evidence, ongoing monitoring, and outcomes analysis. SR 26-2 covers validation and monitoring together in Section V, titled Model Validation and Monitoring. The comparison below covers the points where the two documents' wording lines up directly.

• Instrument status: SR 11-7: the 2011 interagency baseline. SR 26-2: issued April 17, 2026, replaces SR 11-7 and SR 21-8.
• Overall posture: SR 26-2 emphasizes a risk-based approach tailored to model risk profile, size and complexity, and accepts that practices vary among organizations.
• Purpose of validation: SR 11-7: verify that models perform as expected, in line with design objectives and business uses. SR 26-2: evaluate whether models perform as expected, including an assessment of reliability and limitations.
• Scope and rigor: SR 11-7: validate all components (input, processing, reporting), for in-house and vendor models. SR 26-2: nature and rigor generally align with approach, use and materiality.
• Timing: SR 11-7: validation continues on an ongoing basis after go-live. SR 26-2: validation generally occurs before first use, and timing and frequency vary with purpose, methodology, change frequency and data limitations.
• Performance deterioration: SR 26-2: validation can reveal deterioration over time and inform acceptable performance ranges. Meaningful deviation generally prompts adjustment, recalibration or redevelopment.

What this means for validation scope and timing

The most practical change is proportionality. SR 26-2 says sound validation identifies model limitations and errors and clarifies appropriate use, and that its rigor follows approach, use and materiality. A program that applies the same depth of validation to every model in the inventory will struggle to explain itself, because the guidance anticipates different depth for different models. Examiners reviewing a validation file can reasonably ask why a given level of rigor was chosen, so the rationale for scaling belongs in the file, not in the validator's head.

Timing is the second point. Validation generally occurs before first use, but the guidance recognizes that circumstances such as an urgent business need may require using a model before validation is complete. That makes pre-deployment validation the norm and not an absolute gate. It also makes the exception something to control. If a model goes live ahead of validation, record the circumstance, the approval, the interim controls and the plan to complete validation.

Third-party and vendor products are expressly discussed in the revised guidance, including their validation. Vendor model evidence should stay inside the scope of review and should not be assumed to be covered by the vendor's own documentation.

Independence, documentation and examiner evidence

Independence of validators from the people who develop and use a model is a long-standing principle of model risk practice, and it remains a point examiners can test. Keep records showing who developed the model, who uses it and who validated it, along with how those roles are separated. Where one team spans roles, document the compensating arrangement.

For documentation, the evidence a model risk function should be ready to produce follows from the validation statements above. It includes the rationale for the rigor applied to each model, the identified limitations and the appropriate-use conclusions that follow from them, and the acceptable performance ranges chosen for monitoring. It also includes the actions taken when performance deviated, whether adjustment, recalibration or redevelopment, and any use of a model before validation was complete.

Because SR 26-2 pairs validation with monitoring, a validation report alone is not enough. The monitoring record, showing what was measured, against which threshold and with what response, is part of the same evidence story. Policies that still reference SR 11-7, SR 21-8 or the rescinded FDIC letters should be updated so documentation points to the current guidance.

AI in production: what pre-deployment validation cannot cover alone

Pre-deployment validation evidence, such as conceptual soundness review and developmental testing, answers whether a model was fit for its intended use when it was approved. For AI-enabled systems, behavior in production can differ from what was observed before release, because inputs vary and systems can call tools and act on their outputs. That is a different evidence type: a record of what the system was allowed to do and what it did, interaction by interaction.

This is where runtime policy enforcement can support ongoing monitoring. Trussed enforces policy in the execution path across models, agents, tools and MCP servers, with actions to allow, redact, block, rate limit or escalate for human approval at the level of individual interactions and tool calls. Enforcement is applied at runtime, not reviewed after the fact, and it produces audit-ready evidence of each decision. Trussed has run continuously in production in a regulated enterprise for more than 18 months, and insurance, a regulated financial sector, is where it is deepest.

The boundary matters. Runtime enforcement and its evidence are not model validation, testing or model lineage, and they do not replace conceptual soundness review or outcomes analysis. They are a supporting control that gives the monitoring record production-time facts a pre-deployment file cannot contain. Whether a particular AI system belongs in the model inventory is a classification decision the institution should document, and runtime evidence is useful under the wider governance framework either way.