SR 26-2 Bank CIO Requirements: Controls and Evidence for AI Systems

What SR 26-2 is, and what it is not

SR 26-2 is titled Revised Guidance on Model Risk Management. The Federal Reserve, OCC and FDIC are issuing it, and the Federal Reserve letter is dated April 17, 2026. It supersedes and replaces SR 11-7, issued April 4, 2011, and SR 21-8, the 2021 interagency statement on model risk management for bank systems supporting BSA/AML compliance. The Federal Reserve states that the letter is expected to be most relevant to banking organizations with more than $30 billion in total assets that it regulates.

The guidance text states that it does not set forth enforceable standards or prescriptive requirements. That shapes how a CIO should use this page. As of November 2026, SR 26-2 is a statement of supervisory expectations, not a rule set with a control checklist. Each organization remains responsible for adopting practices that are appropriate and effective for the risks it faces. The CIO's task is therefore to build a defensible, documented position, not to chase a list of mandated controls.

What changed from SR 11-7 that matters to technology leadership

The agencies say they updated the guidance based on supervisory experience and industry feedback since SR 11-7, citing technological advancements in modeling over the past several years. The stated aims are to clarify model risk management principles and to emphasize a risk-based approach tailored to the bank's model risk profile and the size and complexity of its operations.

Two implications follow for a CIO. First, the guidance ties the relevance of model risk to the nature, scale and use of models in relation to business risk. An AI system's risk tier will therefore depend on how the bank uses it, not on the technology alone. A drafting assistant for internal staff and an AI system that touches customer decisions or customer data should not carry the same control burden. Second, because practices are expected to vary by risk profile, the control set should be scaled and documented, with the reasoning for each tier written down. Banks below the $30 billion level should confirm how applicability affects them before deciding how much of this to adopt.

What examiners can reasonably ask AI systems to show

Many banks can produce a written policy. Fewer can show what an AI system was permitted to do and what it actually did at the level of individual interactions and tool calls. Reviewing activity after the fact leaves gaps, because logs written for debugging rarely record which policy applied or who approved an exception.

For a given interaction or tool call in the last 90 days, a CIO should be able to answer five questions. Which policy version applied? Who or what was the caller? What was requested? What was the decision: allow, redact, block or escalate? Was a human approver involved, and when? Records that answer these questions are most reliable when they are produced at the moment the decision is made, not reconstructed later from scattered system logs.

The records need to be tamper-resistant, retained for a defined period, and linked to an approved policy version and to an inventory entry. That link lets an examiner move from an individual decision to the rule that governed it and to the system's documented risk tier.

What runtime enforcement covers, and what it does not

Enforcing policy in the AI execution path helps with the parts of the checklist that concern behavior in operation: access limits on tools and models, handling of sensitive data through redaction or blocking, human approval for higher-risk actions, and evidence of each decision. It also gives monitoring a factual base, because blocked and escalated actions are recorded as they occur.

It does not replace validation, conceptual soundness review, independent challenge or the model inventory. Whether a model is fit for purpose is a different question from whether it stayed within approved limits. Keep the two bodies of evidence separate, each owned and produced independently, with each able to reference the other. Board and senior management oversight is also unchanged: the Security Guidelines place supervision of the information security program with the board or a board committee. A bank that treats runtime records as a substitute for governance will find examiners asking for both.

Where Trussed fits

Trussed enforces policy in the execution path across models, agents, tools, MCP servers, AI sites and coding assistants, with decisions to allow, redact, block, rate limit or escalate for human approval, scoped to individual interactions and tool calls. Enforcement produces continuous audit-ready evidence, and deployment is self-managed in the customer cloud with configurable retention and data residency. Trussed does not provide model validation, a model inventory or model lineage.

Insurance, a regulated financial sector, is where Trussed is deepest. Trussed has customers in four regulated verticals: insurance, pharma, healthcare and education. It has run 18+ months in continuous production in a regulated enterprise, with 99.95% uptime on live production traffic and 100+ models under one policy plane. That is general operating experience, not a claim about bank deployments.