SR 11-7 Is Superseded: What SR 26-2 Means for AI Model Risk Management

What changed and when

SR 26-2 states that it supersedes and replaces SR 11-7, issued April 4, 2011, and SR 21-8, the 2021 interagency statement on model risk management for BSA/AML systems. The Federal Reserve lists it among its 2026 SR letters with a posting date of April 17, 2026. The same day, the OCC issued Bulletin 2026-13, which issues the updated interagency guidance and rescinds OCC Bulletin 2011-12, the Comptroller's Handbook booklet on model risk management and OCC Bulletin 1997-24.

The letter says the guidance reflects fifteen years of supervisory experience and industry feedback. It emphasizes a risk-based approach tailored to a banking organization's model risk profile and the size and complexity of its operations, and it says practices appropriately vary among organizations. The OCC adds that the guidance is expected to be most useful for models supporting significant business lines, operations, services and functions. Topics covered include model risk and its management, development and use, validation and monitoring, governance and controls, and vendor and other third-party products.

SR 11-7 remains useful as history. Its structure of development, implementation and use, validation, and governance, policies and controls shaped a decade of practice. It should not be cited as current.

Common misreadings of SR 26-2, corrected

Several readings circulate that conflict with the primary text or with the Federal Reserve's own description of the revision. Each is worth checking against your policies, validation standards and exam-response materials.

• "SR 11-7 is still the current guidance.": Incorrect. SR 26-2 states that it supersedes and replaces SR 11-7, and the OCC bulletin rescinds OCC Bulletin 2011-12.
• "SR 26-2 supplements SR 11-7.": Incorrect. The letter uses the language of supersession and replacement, not supplementation or coexistence.
• "SR 26-2 directly governs generative and agentic AI.": Not as described by the Fed. A May 1, 2026 speech says the revision clarifies that the guidance does not apply to generative or agentic AI and applies narrowly to traditional models and basic AI applications.
• "The Fed website still lists SR 11-7, so it must be current.": Incorrect. A legacy listing on a supervisory information page does not change the supersession stated in SR 26-2.
• "SR 26-2 prescribes one standard for every bank.": Incorrect. It emphasizes a risk-based approach tailored to model risk profile, size and complexity, and says practices appropriately vary.
• "Excluded from SR 26-2 means unregulated.": Incorrect. The speech says the Fed expects other risk management and governance practices to support generative and agentic AI adoption.

Scoping AI systems under SR 26-2

The practical consequence is a scoping problem. The Fed speech separates traditional models and basic AI applications, which the revised guidance covers, from generative and agentic AI, which it does not. The speech also notes that banks currently rely on existing risk management frameworks for AI use and that the Fed is assessing whether supervisory guidance is fit for the future. No boundary test between basic AI and generative or agentic AI is given, so the institution has to define its own and write down the reasoning.

For each AI system, record whether it is treated as a traditional model, a basic AI application, or generative or agentic AI. Record which governance framework applies and why. Name the person or committee that makes the call, and set out how exclusions are challenged and reviewed. An examiner who sees a generative system outside the model risk framework will want to see the other practices that apply to it, described explicitly rather than assumed.

The risk-based principle then governs depth. Validation, monitoring and evidence should scale with the system's model risk profile and with whether it supports a significant business line. Vendor and third-party AI needs its own check, since the OCC bulletin lists vendor and third-party products among the topics the guidance addresses, and the speech mentions separate work on third-party risk management guidance.

First practical step: retire references to SR 11-7 and OCC Bulletin 2011-12 as current, and map existing controls to SR 26-2 and the OCC bulletin.

What examiners can reasonably expect as runtime evidence

SR 26-2 is guidance on model risk management, and the question for generative and agentic AI is what a sound governance framework would produce. The primary text relied on here does not provide a runtime evidence checklist, so the following is derived from model risk management principles and from a reference regime, not from a stated bank examination requirement.

FINRA's generative AI oversight material applies to broker-dealers, not banks. It is still a useful reference for what concrete evidence looks like. It says a governance or model risk management framework may include comprehensive documentation, and that testing may include storing prompt and output logs, tracking which model version was used and when, and human-in-the-loop review of outputs, including checks for errors or bias.

Translated into an examiner's questions, the focus is on individual production events. For a given interaction or tool call, can the institution show which policy governed it, which model version ran, what the system did, and whether a person approved it? Can it show what happened when a control decision was made, such as a block, a redaction or an escalation? These are questions about runtime behavior. They differ from pre-deployment questions about whether a model is conceptually sound and well validated.

Retention periods, log integrity and access controls for this evidence are not specified in the guidance, so the institution must set and document its own standards.

What runtime evidence covers and what it does not

Enforcing policy at runtime produces a record of how AI was allowed to operate and what it did. It does not show that a model is sound, validated or correctly inventoried. Treating the two as interchangeable is the main mapping error to avoid.

• Policy applied to each interaction or tool call: Addressed at runtime, by enforcing the policy and recording the decision.
• Allow, redact, block or escalate decisions: Addressed at runtime, with a durable record per event.
• Human approval of escalated actions: Addressed at runtime where escalation for approval is enforced in the path.
• Conceptual soundness and validation: Separate model validation process. Runtime records do not substitute.
• Model inventory and scoping decisions: Separate inventory and governance process, including the documented scoping rationale.
• Model lineage and data provenance: Separate lineage work. Runtime enforcement does not supply it.

Where Trussed fits

Trussed enforces policy in the execution path across models, agents, tools, MCP servers, AI sites and coding assistants. Decisions are enforced at runtime, not reviewed after the fact: allow, redact, block, rate limit, or escalate for human approval. The scope is individual interactions and tool calls. That enforcement generates continuous, audit-ready evidence of which policy applied and what decision was made, mapped to frameworks including NAIC, NYDFS and NIST. The platform can be self-managed in the customer cloud, with configurable retention and data residency, which matters when the guidance leaves retention standards to the institution.

This does not replace model validation, model inventory or lineage work. Trussed does not provide model provenance, model lineage or dataset provenance, and the scoping and governance decisions described above remain with the institution. Runtime evidence is one input to the examiner conversation, alongside those processes.

Trussed has no financial-services customers to cite. Insurance, a regulated financial sector, is where it is deepest, with customers across four regulated verticals: insurance, pharma, healthcare and education. It has run in continuous production in a regulated enterprise for more than 18 months.