Rewriting a Model Risk Management Policy for SR 26-2

What SR 26-2 changes and what it leaves open

SR 26-2 transmits the agencies' Revised Guidance on Model Risk Management. It replaces SR 11-7 and SR 21-8, the 2021 BSA/AML model risk statement. The agencies describe a risk-based approach tailored to a bank's model risk profile and to the size and complexity of its operations. As of November 2026, no separate effective date appears in the material for this guidance.

The guidance also states that it does not set out enforceable standards or prescriptive requirements, and that non-compliance will not result in supervisory criticism. For policy authors this shifts the justification. The policy should rest on the institution's own risk profile and on practices that are appropriate and effective for its specific risks, rather than on a citation to the guidance.

Two scoping points belong in the policy text. First, the FDIC states the guidance generally does not apply to models at banking organizations with total assets of $30 billion or less, to the extent they lack significant exposure to model risk. Record how your institution reached its scoping conclusion. Second, the guidance notes that generative AI and agentic AI models are novel and rapidly evolving, and says a bank's own risk management and governance practices should guide controls for tools it does not cover. The agencies also plan a request for information on model risk management, with particular attention to AI. Add a policy review trigger tied to that request.

Definition, scope, inventory and tiering

The guidance defines a model as a complex quantitative method, system or approach that applies statistical, economic or financial theories to process input data into quantitative estimates. It excludes simple arithmetic, such as spreadsheet calculations, and deterministic rule-based processes and software that lack such underlying theories. Restate this definition and its exclusions in the policy. Then define a decision path for AI-enabled tools whose classification is not obvious: who decides, on what criteria, and where the rationale is recorded. A determination that a tool is out of scope is itself a record an examiner may ask for.

The inventory section should say which models are inventoried, whether all or only higher-risk ones, and which attributes are recorded. Useful attributes include a risk rating per model, links to documentation and code, data dictionaries and incident response plans. Include vendor-provided and third-party AI that is called at runtime, since these are the entries most likely to be missing.

The tiering section should state that rigor is risk-based and tailored to the size, complexity and extent of model use. Model risk is influenced by inherent risk, exposure, purpose and use. Tiers should visibly drive validation depth and monitoring intensity, so an examiner can trace a tier assignment to the work performed.

Validation, monitoring, change management and vendor models

Validation evaluates whether a model performs as expected, including its reliability and limitations. Conceptual soundness covers assessing and documenting design, including key modeling choices, assumptions, qualitative judgments and data selection, along with construction and developmental testing. For some models, interpretability measures or benchmarking may be more practical than theoretical review, which is relevant to AI models. These activities remain validation work. A runtime control does not substitute for them.

Ongoing monitoring should include assessing model limitations at development and over time, with procedures for responding to issues before and after approval. Documentation should support continuity and the tracking of recommendations, responses and exceptions. Write the policy so every exception has an owner, a response and a closure record.

For vendor models customized to a bank's needs, the guidance says adjustments should be documented, justified and evaluated as part of validation. Policy should define what counts as customization for a vendor AI tool, for example changes to configuration or to the tools and data it can reach, and require the same documentation, justification and evaluation. Vendor AI called at runtime can change between validation cycles, so the change management section should say how such changes are detected and who approves them.

Policy-to-control-to-evidence mapping

Use a table like this one to turn each policy statement into a control with an owner and an artifact. The split between runtime and process controls is a practitioner design choice. The guidance does not prescribe it, and it does not list the artifacts examiners will request. Use-restriction statements about permitted inputs, tools and approvers are the best candidates for runtime enforcement, because they can be tested at the moment of each interaction.

• Scope determination for AI-enabled tools: Process control. Owner: model risk function. Evidence: classification record with the in-scope or out-of-scope rationale and approver.
• Inventory and tier assignment: Process control. Owner: model owner and model risk function. Evidence: inventory record with risk rating, recorded attributes and change history.
• Use restrictions on inputs and tool access: Runtime control: allow, redact or block. Owner: model owner defines, technology enforces. Evidence: per-interaction enforcement records showing the policy applied and the decision.
• Human approval for designated actions: Runtime control: escalate for human approval. Owner: business line approver. Evidence: approval records with requester, approver, time and outcome.
• Validation and conceptual soundness: Process control. Owner: independent validation. Evidence: validation report, benchmarking or interpretability results, and findings tracked to response.
• Exceptions and issue tracking: Process control fed by runtime records. Owner: model risk function. Evidence: exception log with owner, response and closure date.

Where runtime enforcement fits

Many AI-enabled models and tools are called at runtime, between validation cycles. A policy that says only approved data may reach a vendor model, or that certain tool calls need a named approver, describes a control that has to operate on every interaction. Review after the fact can show that a violation happened. It cannot stop it.

Trussed enforces policy in the execution path across models, agents, tools, MCP servers, AI sites and coding assistants. It can allow, redact, block, rate limit or escalate an interaction for human approval, at the level of individual interactions and tool calls. Enforcement generates audit-ready evidence, so the use-restriction and escalation records in the table above come from the control itself rather than from reconstruction. Trussed does not perform model validation or establish model lineage, and those remain with your validation and governance processes. Insurance is the regulated financial sector where Trussed is deepest.

Whatever tooling you choose, test the control against your policy wording. If the policy cannot be expressed as a decision made on a single interaction, it belongs in validation or governance, not in a runtime rule.