Migrating Bank Model Risk Management Policies from SR 11-7 to SR 26-2

How SR 26-2 relates to SR 11-7

The Federal Reserve lists SR 26-2 as Revised Guidance on Model Risk Management, dated April 17, 2026. Its framing is principle-based: it highlights sound principles for effective model risk management and recognizes that practices appropriately vary among banking organizations based on their risk profiles and model usage. SR 11-7, issued by the Federal Reserve and OCC in 2011, is the baseline most bank programs were built on. It describes an effective framework as robust model development, implementation and use; effective validation; and sound governance, policies and controls.

That shared structure shapes the migration. Most programs will not be rewritten from scratch. They will be compared provision by provision, and each provision will be superseded, revised, or retained. The disposition should come from the text of the letter, as of November 2026, and not from assumptions about what a revision usually changes.

The principle-based framing also means a crosswalk should capture more than changed clauses. When practices vary with risk profile and model usage, the bank's tailoring decisions and their rationale become part of what an examiner reads. The crosswalk should record those decisions.

Build the gap assessment and policy crosswalk

Start with the crosswalk, because every later workstream depends on it. Use one row per SR 11-7 provision, covering development, implementation and use, validation, governance, policies and controls, documentation, and internal audit. Pair each row with the corresponding SR 26-2 provision, and add the columns below. Record the effective date and any transition expectations from the letter at the top of the crosswalk, so every disposition is read against the same timeline.

• SR 11-7 provision: The baseline requirement as your current policy implements it, with the policy section that cites it.
• SR 26-2 provision: The corresponding text in the revised guidance, or a note that no counterpart exists.
• Disposition: Superseded, revised, or retained, with a short statement of the change in expectation.
• Policy owner: A named role accountable for conforming the affected document.
• Affected artifact: The policy, standard, procedure, template, or inventory field that must change.
• Evidence of operation: The record that will show the revised control working, such as a report, approval, or exception log.

Ownership, internal audit, and AI-enabled models

Policies should define risk management expectations and set a framework for assessing the magnitude of model risk, with practices commensurate with that risk. Ownership follows from that framework. Each crosswalk row needs one accountable role, and each control needs a named operator.

Keep internal audit's scope separate from model risk management ownership. Internal audit evaluates whether model risk management practices are rigorous and effective and whether related policies are implemented accordingly. SR 11-7 also expects internal audit to assess the framework's overall effectiveness, including for individual models and in the aggregate. If the same team writes the controls and attests to them, the evidence loses independence.

AI-enabled models need explicit attention. Whatever the revised text says about their scope, a bank that uses them inside model risk scope should name an owner for each one, place each in the inventory with a risk tier, and define how it is validated and monitored. Third-party models deserve the same treatment. A model the bank did not build still carries the bank's accountability, and an inventory row without an owner is a finding waiting to happen.

Where runtime enforcement supports controls over AI-enabled models

Nothing in the supervisory text reviewed here states that runtime enforcement is required. It is a design option for banks that run AI-enabled models and want controls that can be shown operating, not only described in policy. When a policy says a type of data must not reach a model, or a tool call needs approval, an examiner will ask for the record showing what happened in practice.

Trussed enforces policy in the execution path for AI interactions and tool calls: allow, redact, block. Policy is enforced at runtime, not reviewed after the fact, and each decision produces audit-ready evidence. That evidence can be linked to a specific row in the crosswalk, so a control in the policy points to the record showing it operating. This supports the documentation and exception-tracking themes above. Trussed does not validate models and does not provide model lineage or provenance. It addresses control and evidence at the point of use.

Trussed has run in continuous production in a regulated enterprise for more than 18 months, and insurance is the regulated financial sector where it is deepest. Banks should judge any such approach by one test: whether the evidence it produces maps to their own controls and stands up under examination.