SR 26-2 for Large Banks: Model Risk Management, Runtime Enforcement and Audit-Ready Evidence for AI

What SR 26-2 says about the asset threshold

The Federal Reserve's SR 26-2 letter, dated April 17, 2026, attaches revised Supervisory Guidance on Model Risk Management. The OCC announced updated guidance for the institutions it supervises the same day, and the FDIC published a release, all described as coordinated across the three agencies. As of November 2026, the sources reviewed give no separate effective or compliance date beyond issuance.

The letter states that it is expected to be most relevant to banking organizations regulated by the Federal Reserve with over $30 billion in total assets. That wording is about expected relevance. It is not a hard coverage rule, and a bank near the line should not treat it as a bright-line exemption or a bright-line trigger. Institutions supervised by the OCC or FDIC should confirm with their own supervisor how the guidance applies to them.

The agencies also say model risk management should be tailored commensurately to the size, complexity and model risk profile of the organization, and that practices appropriately vary with risk profiles and model usage. For a large bank, tailoring does not mean less. It means the institution needs a documented rationale for why the depth of its controls matches the exposure of each model and use. Model exposure, in the guidance, is the significance of model output to business decisions, and it tends to be greater for models affecting larger portfolios or having larger business impact.

Which expectations bear on AI in production

The reading in this section is interpretation. The guidance addresses models generally, and the agencies have said they plan to issue a request for information on model risk management that would consider banks' use of AI, including generative AI, agentic AI and AI-based models. Until that work lands, risk leaders have to map existing expectations to AI uses themselves.

Four parts of the guidance map most directly. Governance: the guidance states that all components of the model lifecycle benefit from governance supported by clear policies and effective controls, and that effective policies define expectations and a framework for assessing the magnitude of model risk. Monitoring: an effective ongoing monitoring plan may include regularly assessing model limitations at development and over time, with procedures for responding to issues before and after a model is approved for use. Documentation: adequate documentation supports continuity of operations, tracking of recommendations, responses and exceptions, and management of remediation. Internal audit: its role is generally to evaluate whether model risk management practices are rigorous and effective and whether related policies are implemented accordingly.

For AI, exposure suggests scoping controls by use case and business impact, not with one institution-wide setting. An internal drafting assistant and an AI agent that can call tools touching customer data carry different exposure, and the controls and evidence should differ accordingly. Effective challenge, described as critical analysis by objective experts who evaluate model risk and effect appropriate changes, still applies. It is a separate activity from any runtime control.

Where documented policy and enforced behavior diverge

The phrase in the guidance about policies being implemented accordingly is where many programs are weakest. A model risk policy may state what AI systems may do, which data they may touch and when a human must approve an action. In production, that policy is often enforced by review: sampled transcripts, periodic access reviews, or investigation after an incident. Those are legitimate detective controls, but they show what a team found, not what the system was permitted to do at the time of each action.

Runtime policy enforcement changes the timing. A control point in the execution path, covering model calls and tool calls, applies policy before the action completes. The actions are the same four most programs already discuss: allow the interaction, redact sensitive content, block it, or escalate it for human approval. These terms are a design framework used on this page. They are not language from SR 26-2.

The evidence consequence matters as much as the control. If the enforcement point records its own decision, the bank holds a contemporaneous record of what was permitted and what occurred. Records reconstructed later from application logs depend on assumptions about which policy was active and why a call was handled as it was. The guidance does not specify evidence artifacts or examiner procedures, and the principle of generating evidence at the point of enforcement is a design position, not a stated examiner requirement. It is, however, a direct way to support the guidance's expectations on documentation of exceptions and responses.

Evaluating runtime enforcement, and where Trussed fits

When evaluating any runtime control and evidence layer, ask whether it enforces policy in the execution path or only reports afterward. Ask what record it produces for each interaction and tool call, whether that record can be exported for examiner or internal audit review, how policy versions are tied to recorded decisions, and whether human-approval escalations capture the approver and the outcome. Ask equally what it does not cover. No runtime layer should be presented as model validation, effective challenge or a substitute for governance process.

Trussed is a runtime control and evidence layer for regulated enterprises. It enforces policy in the execution path across models, agents, tools and MCP servers, with allow, redact, block, rate limit and escalate-for-human-approval actions applied to individual interactions and tool calls. It generates continuous audit-ready evidence from that enforcement and can be self-managed in the customer's cloud, with configurable retention and data residency. It is not a validation, pre-deployment testing or GRC product.

Trussed is deepest in insurance, another regulated financial sector, and also serves healthcare, pharma and education. Its approved production proof points are 18+ months of continuous production in a regulated enterprise, 99.95% uptime on live production traffic, 100+ models under one policy plane, and 30+ GB of audit evidence generated per day. These describe operating experience under regulatory scrutiny in other sectors, and the evaluation questions above are the right test for any bank's fit.