SR 26-2: a plain-English summary of supervisory expectations for model validation leads

Reading SR 26-2 in three layers

Model validation leads are usually asked three different questions about SR 26-2 at once: what does it say, what does it mean for our program, and what can we show. Treating these as one question is how teams end up defending an interpretation as if it were the text.

A workable discipline is to keep three layers apart in every working document. The first layer is the guidance text, quoted directly. The second is interpretation: the team's reading of how the text applies to its model inventory, with the reasoning written down. The third is evidence: the specific artifacts that demonstrate each expectation was met.

This guide is a practitioner walkthrough, not a legal opinion. Where the guidance leaves a question open, for example how far expectations reach into AI systems whose behavior depends on prompts, tools and runtime policy, the validation record should state the team's reading and the basis for it. An examiner can disagree with a documented interpretation. An undocumented one is harder to defend.

A working map from model risk elements to validation evidence

A November 2025 federal supervisory notice describes a sound model risk management framework as having three main elements: an accurate model inventory with an appropriate approach to development, implementation and use; effective model validation and continuous model performance monitoring; and a strong governance framework. Governance covers policies, procedures, resource allocation and mechanisms for checking that policies are followed, including internal audit review.

The table below uses those three elements as a working structure for organizing evidence. It is a translation aid for validation teams, not a restatement of SR 26-2.

• Inventory, development and use: Current inventory entries, intended-use statements, and records showing models are used within those statements. For production AI, this includes the tools and data a model can reach.
• Validation and continuous monitoring: Validation reports, challenge findings and remediation tracking, plus monitoring output that continues after deployment rather than ending at sign-off.
• Governance: Policies, defined roles, resourcing, and evidence that internal audit can test whether the policies are actually followed.

Independence and effective challenge

Independence and effective challenge are the parts of validation practice most likely to be tested in an examination, so it helps to be precise about definitions. The Federal Reserve's Stress Testing Policy Statement defines effective challenge as critical analysis by objective, informed parties who can identify model limitations and recommend appropriate changes. It also describes its own supervisory model validation program as built on independence, technical competence and stature, intended to confirm that models are appropriate for their intended uses.

That statement governs the Federal Reserve's own supervisory stress test models. Its validation unit and advisory council are not a structure that banking organizations are required to copy. They are still useful reference points when a validation lead documents why the team is positioned to challenge model owners credibly: reporting lines, subject-matter competence, and the standing to have findings acted on.

One practical implication follows. Effective challenge depends on validators being able to test claims rather than accept them. For production AI, that means validators need access to records of live behavior, not only to the model owner's description of how the system is supposed to behave.

Pre-deployment validation versus runtime evidence

Validation is typically periodic. It runs before deployment, after a material change, or on a schedule. It answers whether a model is conceptually sound, performs as intended on representative data, and is documented well enough for someone else to understand its limits.

Production AI adds a different question: what actually happened in a specific interaction on a specific day. A validated model can be reached through a prompt nobody anticipated, call a tool outside its intended use, or return content that policy would have prohibited. Periodic validation cannot reconstruct those events after the fact, because it was never designed to record them.

That gap is why continuous monitoring and runtime records matter alongside validation. A reasonable division of labor is this: validation establishes what the model is permitted to do and tests whether that design is sound; runtime controls enforce the permission boundary; and durable evidence records each decision so independent reviewers can check the boundary held. The first is a judgment exercise. The second and third are operational systems, and they need owners, retention rules and access for internal audit.

For third-party and vendor models, the 2023 interagency guidance on third-party relationships frames risk management across all stages of the relationship life cycle. Validation leads should ask what production-use evidence a vendor can provide, since the institution may not control the model's internals but remains responsible for how it is used.

Where policy enforcement fits, and where it does not

Trussed enforces policy in the execution path of AI interactions and tool calls across models, agents, tools and MCP servers. Each interaction is allowed, redacted, blocked, rate limited, or escalated for human approval, and the enforcement generates audit-ready evidence for that individual interaction or tool call. Policy is enforced at runtime, not reviewed after the fact. Trussed has run continuously in production in a regulated enterprise for more than 18 months.

The scope is deliberately narrow. Trussed does not perform model validation, and it does not replace independent challenge, outcomes analysis or the judgment a validation team applies. It also makes no claims about model provenance, lineage or end-to-end tracing of agentic workflows. It is complementary to independent validation: validation decides what a model should be permitted to do, and enforcement in the path produces the evidence of what was allowed and what happened.