Model Validation of Runtime Enforcement Policies under SR 26-2

What changed: SR 26-2 replaces SR 11-7

Many validation standards still cite SR 11-7 and OCC Bulletin 2011-12. On April 17, 2026, the Federal Reserve, OCC and FDIC issued the Revised Guidance on Model Risk Management as SR 26-2. It supersedes and replaces SR 11-7 and SR 21-8, the BSA/AML model risk interagency statement. The OCC issued the same guidance as Bulletin 2026-13. The agencies say the revision reflects about fifteen years of supervisory experience, industry feedback and advances in modeling.

The revised guidance is risk-based. It is tailored to a banking organization's model risk profile and to the size and complexity of its operations, and each organization remains responsible for adopting practices that are appropriate and effective for its own risks. It is expected to be most relevant to banking organizations with more than $30 billion in total assets. Smaller organizations are typically subject to internal practices suited to their size and risk, although the guidance may be relevant to those with significant model risk exposure.

The guidance describes generative AI and agentic AI models as novel and rapidly evolving, and states that its principles apply to traditional statistical and quantitative models and to non-generative, non-agentic AI models. As of November 2026, any MRM policy or validation standard that still points to SR 11-7 or OCC 2011-12 should be reviewed against the revised text.

Deciding whether runtime enforcement policies are in scope

A runtime enforcement policy is a rule set that decides, for each interaction or tool call, whether the action is allowed, redacted, blocked, rate limited or escalated for human approval. In production, it shapes what a generative model or agent can actually do, regardless of how the model performed in testing.

SR 26-2 frames validation as evaluating whether a model performs as expected, including its reliability and limitations, with rigor aligned to the model's approach, use and materiality. It also describes controls on known limitations, such as limits on model use or closer monitoring. Treating a runtime policy as that kind of control is an inference rather than a quoted requirement, but it is a defensible one. If a policy materially bounds how a model is used in a material process, leaving it outside independent challenge creates a gap an examiner can ask about: how were its design, coverage and effectiveness assessed?

The practical step is a documented scope decision. Record which enforcement policies are in scope, which are not, and the materiality-based rationale for each. Independence matters here. Under the earlier SR 11-7, work performed by developers or users needed critical review by an independent party, and validators should confirm the equivalent wording in the current text. The team that writes and operates the policies should not be the only team that assesses them.

What a validator should review

Policy design and rationale. Each rule should trace to a stated risk or obligation, such as preventing disclosure of customer data or restricting a tool call to approved actions. Validators can challenge whether the rule logic matches that intent, whether thresholds are justified, and whether the chosen action (redact, block, escalate) is proportionate. Testing can include reviewing rule logic and running test cases, including boundary and adversarial inputs, against the policy as written.

Coverage. A policy that works but does not see all traffic is a weak control. Ask for an inventory of models, agents, tools and entry points, and compare it with the set actually routed through enforcement. Document any path that bypasses the layer and the compensating control for it.

Change control. Policies change more often than models. Review how changes are requested, approved, tested and versioned, who can change a rule in production, and how a decision can be tied back to the exact policy version in force at the time.

Escalation and exception handling. Where an action goes to human approval, validators should test whether the route works, who the approvers are, what they see, and what happens on timeout. Exceptions and overrides need an owner, an expiry and a record. Where a vendor or third-party layer is customized, the customizations should be documented, justified and evaluated as part of validation.

Evidence integrity and retention. Decision records are only useful if they are complete, tamper-evident, access-controlled and kept for as long as the institution's retention schedule requires. Validators should test completeness by sampling interactions and confirming that each has a corresponding record.

How runtime enforcement fits with validation and monitoring

Pre-deployment validation asks whether a model is sound for its intended use. Under SR 26-2 this generally occurs before first use, although circumstances such as an urgent business need may require use before validation is complete. Ongoing monitoring and outcomes analysis compare model outputs with real-world outcomes against established performance thresholds, and persistent deviations may warrant adjustment, recalibration or redevelopment. Runtime enforcement sits in a different place: it constrains what a model or agent may do in each interaction, whatever its measured performance.

The same outcomes logic can be applied to the enforcement layer itself. Block and escalation rates, for example, can be compared with what the policy intended, and unexpected shifts can trigger review. This is an application of the principle rather than a stated requirement.

Validators should also document the limits. Enforcement does not assess conceptual soundness, data quality or the accuracy of model outputs. It acts only on traffic that passes through it, and its rules are only as good as the risks their authors anticipated. Where escalation depends on human reviewers, the effectiveness of that review is a separate question. Stating these limits in the validation report keeps stakeholders from treating enforcement as a substitute for the other two layers.