SR 11-7 vs SR 26-2: Side-by-Side Differences for Bank Risk Teams

What SR 26-2 says about itself

The Federal Reserve Board published SR 26-2, titled Revised Guidance on Model Risk Management, on April 17, 2026. The letter says the revised guidance highlights sound principles for effective model risk management and that practices appropriately vary among banking organizations based on their specific risk profiles and model usage. The Federal Reserve's guidance page adds that each banking organization is ultimately responsible for adopting practices that are appropriate and effective for the specific risks it faces or is likely to face.

The attached guidance says it may be useful for any type of model, but that the general expectation is that it will be most useful for models supporting a banking organization's significant business lines, operations, services and functions. It also states that it does not set forth enforceable standards or prescriptive requirements, and that non-compliance with it will not result in supervisory criticism.

That framing shapes how a comparison with SR 11-7 should be done. A gap list against fixed minimums is the wrong tool for principles-based guidance. A better approach is to take each control in an SR 11-7 based program and ask whether it is proportionate to the model's usage, whether the bank can explain why, and whether the bank can show the control ran. This page is a Federal Reserve issuance, so legal and compliance teams should also confirm how the other agencies that supervise their charter treat it.

Mapping an SR 11-7 based program to SR 26-2

Each row below pairs a stated position in SR 26-2 with the practical question it raises for a program built around SR 11-7. The table reflects the revised guidance's stated framing. Any change in a specific provision should be confirmed against the paragraph in each document before a control is retired or reworded.

• Issuance and status: SR 26-2: Federal Reserve letter dated April 17, 2026, titled Revised Guidance on Model Risk Management, with an attached supervisory guidance. Program implication: record the issuance in policy references and map each SR 11-7 derived policy clause to the matching passage of the revised text before changing anything.
• Applicability and emphasis: SR 26-2: most useful for models supporting significant business lines, operations, services and functions. Program implication: test whether inventory tiers and validation priority track the significance of the business line a model supports.
• Nature of expectations: SR 26-2: sound principles, with no enforceable standards or prescriptive requirements. Program implication: write policies so they explain why chosen practices are appropriate, rather than citing fixed minimums.
• Responsibility for practices: SR 26-2: each banking organization is ultimately responsible for appropriate and effective practices. Program implication: governance records should tie practices to the bank's risk profile and model usage.
• Scope of covered models: SR 26-2: may be useful for any type of model. Program implication: check that the bank's own model definition captures AI-enabled systems that make or inform consequential decisions.
• Variation by usage: SR 26-2: practices vary with risk profile and model usage. Program implication: keep records showing that controls operated, at a depth that matches each model's tier.

Practical implications by program area

Model inventory is the first place to look. If the guidance is most useful for models supporting significant business lines, the inventory should make that relationship visible. Each entry should state which business line, operation or service the model supports and why it is tiered as it is. Inventory definitions should also be tested against newer system types, because a system that falls outside the bank's definition of a model also falls outside its validation and monitoring cycle.

Validation and effective challenge come next. Under a principles-based approach, validation depth is a documented judgment. Teams should be able to show why a given model received the scope and frequency of validation it did, and who challenged the assumptions. This is a practice inference from the stated emphasis on usage and risk profile, not a quoted requirement.

Governance and accountability should capture the rationale behind the program's design. Since the Federal Reserve places responsibility for appropriate practices on the bank, board and senior management reporting should show how the program fits the bank's models and risks, not only whether a checklist was completed.

Ongoing monitoring and documentation are where examiner scrutiny tends to become concrete, even where the guidance is non-prescriptive. The guidance's statement about supervisory criticism does not remove the bank's responsibility to adopt effective practices. A bank that cannot show monitoring outputs, approvals, exceptions and remediation for its significant models has little to offer when asked how its program works. Existing SR 11-7 era documentation often still serves, but it should be reviewed for whether it shows operation of controls over time and not only their design.

AI-enabled systems, runtime enforcement and evidence

AI-enabled systems that inform consequential decisions are the clearest case for proportionate, usage-based treatment. Neither issuance prescribes a product or an architecture, so any control design here is the bank's own choice. Validation and monitoring generally assess a model's behavior across a population of cases. They do not by themselves record what a system was permitted to do in a single interaction, or what it did.

That gap is where runtime policy enforcement can support a program. Trussed enforces policy in the execution path across models, agents, tools, MCP servers, AI sites and coding assistants. Each interaction or tool call can be allowed, redacted, blocked, rate limited or escalated for human approval, and the enforcement decisions produce audit-ready evidence. Policy is enforced at runtime, not reviewed after the fact, and the evidence is a by-product of enforcement.

The scope is specific. Trussed works at the level of individual interactions and tool calls. It does not replace model validation, and it does not provide model lineage or dataset provenance. Its relevance to SR 26-2 is limited to one question: for models in the higher tiers of the inventory, can the bank show what its policies allowed and what happened? Scope such controls to the models and usage that your tiering marks as significant.