Questions Bank Boards Should Ask Management About SR 26-2

What directors are anchoring on

SR 26-2, Revised Guidance on Model Risk Management, was issued on April 17, 2026 by the Federal Reserve, the OCC and the FDIC. It supersedes SR 11-7 and SR 21-8. The OCC rescinded its Bulletins 2011-12, 2021-19 and 1997-24 and the Comptroller's Handbook booklet on model risk management, and the FDIC rescinded FIL-22-2017 and FIL-27-2021. As of November 2026, no amendment or delay has been identified.

The guidance emphasizes a risk-based approach tailored to each bank's model risk profile, size and complexity. It says practices that work for one organization may be ineffective for another, and that each bank is responsible for adopting practices that are appropriate and effective for its own risks. It also states that supervisory action may follow where insufficient management of model risk amounts to a violation of law or an unsafe or unsound practice.

Two consequences follow for a board. First, accountability for fit sits with the bank, so the board should ask management to show how practices were tailored, not simply that a framework exists. Second, because the approach is principle-based, how it applies to AI systems will scale with the nature, scale and use of those systems. That is an inference, and the questions below are a practitioner framework, not regulatory requirements. A useful first question is which legacy procedures built on SR 11-7, SR 21-8 or the rescinded OCC and FDIC issuances have been updated, and by whom.

Scope, inventory, roles and accountability

Ask: does the inventory capture every model and AI system in use, including systems with tool access, and how is completeness verified? Expect a current inventory with a named owner and a risk tiering rationale for each entry, plus a description of how new or informally adopted AI use is found. A weak answer relies on self-reporting by business units, or describes the inventory as a project in progress with no date for completion.

Ask: who is accountable for each AI use case, and how do the first line, second line and internal audit divide responsibility for production behavior? Expect written role assignments and a clear answer on who can stop a system that is misbehaving. The Federal Reserve's internal-control framework describes control environment, risk assessment, control activities, information and communication, and monitoring as functioning through the board, management and other personnel. Boards can use that as a test: each component should have a visible owner for AI. Weak answers name a committee instead of a person, or assign production behavior to no one because the system passed review before launch.

Ask: how were practices tailored to our model risk profile, size and complexity? Expect a rationale for why higher-risk uses receive more intensive validation and monitoring. A weak answer is a generic policy that treats a spreadsheet model and an AI system with tool access identically.

Controls on AI behavior in production

This is where management reporting is usually thinnest. Policies and pre-deployment reviews describe intent. The board's question is what acts on a live interaction or tool call at the moment it happens.

Ask: which controls are enforced at runtime, and which are reviewed after the fact? Both have a place, but they are different. A runtime control sits in the execution path and can allow, redact, block, rate limit or route an action to a human for approval before it completes. An after-the-fact review detects a problem once it has occurred. Expect management to classify each material AI use case this way and explain why the mix is appropriate for its risk. A weak answer says controls are in place without saying when they operate, or describes monitoring dashboards as if they prevented anything.

Ask: how are policy exceptions tracked? OCC examination material directs examiners to determine how management ensures adopted policies are followed and exceptions are documented. Expect an exception record showing what was granted, by whom and for how long. Weak answers cannot say how many exceptions exist.

Ask: what ongoing monitoring and periodic review applies, with what frequency and which owners? The NIST AI Risk Management Framework, a voluntary framework and not an SR 26-2 requirement, calls for planned monitoring and review with clearly defined roles and review frequency. It is a reasonable reference for what a defined cadence looks like.

Evidence retention, escalation and reporting

Ask: what evidence of control operation is retained, for how long, and could it be produced for an examiner on request? Expect management to describe the evidence by type, such as which actions were allowed, redacted, blocked or escalated, under which policy, with the retention period and storage location. A strong answer includes a recent example of retrieval and the time it took. A weak answer points to policy documents and validation reports, which show design, not operation. Another weak sign is evidence assembled manually from several systems only when an exam begins.

Ask: what evidence does each line receive from production systems? OCC material says internal control effectiveness is assessed through risk reviews, often by the second line, and through the audit program, the third line. If those functions can only review samples that the first line prepares, their independence is limited in practice.

Ask: what triggers escalation to senior management and the board, and what do board reports show? OCC examination procedures look at board meeting packages and key risk reports, and at whether management takes timely corrective action on deficiencies. Risk reporting should readily identify significant and emerging risks and issues. Expect reports that include exception counts, blocked or escalated actions, open findings and closure dates. A weak answer is a report that restates policy and shows no operating results, or one where no event has ever reached the board.

Reading the answers: strong versus weak

Use this summary to judge whether management's answers describe demonstrable operating control or documented intent.

• Inventory: Strong: complete, owned, tiered, with a stated discovery method. Weak: self-reported, undated, silent on tool access.
• Accountability: Strong: named individuals and a clear stop authority. Weak: committees, or no owner after launch.
• Production controls: Strong: each control classified as runtime or after-the-fact with rationale. Weak: controls described without timing.
• Evidence: Strong: typed, retained, retrievable on request, with a tested example. Weak: policies and validation reports only.
• Escalation: Strong: defined triggers, exception counts, corrective-action dates. Weak: narrative reports with no operating data.

Where runtime enforcement and audit-ready evidence fit

Any approach that satisfies these answers can work. Some banks will build, and some will buy. The capability worth testing for is the same either way: policy enforced in the execution path of AI interactions and tool calls, with evidence generated by that enforcement rather than reconstructed later.

Trussed provides this capability. It enforces policy in the execution path across models, agents, tools and MCP servers, with actions to allow, redact, block, rate limit or escalate for human approval, scoped to individual interactions and tool calls. Enforcement produces continuous audit-ready evidence, which can be mapped to frameworks including NIST. Deployment is self-managed in the customer cloud, with configurable retention and data residency. Trussed has run continuously in production in a regulated enterprise for more than 18 months, and insurance, a regulated financial sector, is where it is deepest.

This maps most directly to the production controls and evidence questions above. It does not replace inventory, role assignment, validation or board reporting, which remain management's responsibility.