SR 26-2 Model Risk Tiering: What It Means for Runtime Policy Enforcement and Audit-Ready Evidence

What SR 26-2 establishes

The Federal Reserve's SR 26-2 letter states that, based on supervisory experience and industry feedback since SR 11-7 was issued, the agencies updated the model risk management guidance. The stated purposes are to clarify model risk management principles and to emphasize a risk-based approach tailored to a banking organization's model risk profile and the size and complexity of its operations. The guidance also recognizes that practices appropriately vary among banking organizations based on their risk profiles and model usage. This is the position as of November 2026.

For a risk leader, the operative idea is proportionality. A program that applies identical controls to every model is hard to defend as risk-based, and so is one that applies minimal controls to everything. The tiering decision is where proportionality becomes visible: it is the documented link between how much risk a model carries and how much control, review and monitoring it receives. The mechanics in the following sections describe common practice for materiality and tiering rather than quoted requirements of the letter.

How materiality and tiering work in practice

Materiality is a judgment about how much a model's failure or misuse could matter to the institution. Institutions commonly express it through factors such as the exposure the model creates, the business impact of its outputs, its complexity, and how heavily decisions rely on it. For generative AI, NIST's Generative AI Profile adds considerations for tier definitions: information integrity impacts, dependencies on other IT or data systems, harm to fundamental rights or public safety, and objectionable or untruthful output. NIST materials are voluntary and are not SR 26-2 guidance, but they are useful for structuring the exercise.

A typical approach combines impact and likelihood, often on a qualitative scale such as red, amber and green, and assigns every model to a level. Industry practice under SR 11-7 has included tiering models, classifying risks into categories such as accuracy, stability and potential for misuse, and requiring compensatory actions depending on tier. The tier then determines how much oversight and how many resources the model receives.

Three practices make a tiering program easier to defend. Use standardized, documented scales so that tiers mean the same thing across business lines. Record why each system received its tier and why its controls were set at that level. Be able to show who approved the tier criteria and the risk tolerance behind them. Because organizations set their own tolerance, the approval trail matters as much as the scale itself.

Tiering also has to cover everything in use. That includes vendor-provided and generative AI systems, which tend to enter production through business teams rather than through model development. An inventory with a tier and an owner for each system is the precondition for everything that follows.

Mapping tier expectations to runtime actions

The mapping below is an analytical design choice, not a requirement stated in SR 26-2. The idea is that a tier already implies how much latitude a system should have, and that latitude can be written as policy applied to each interaction and tool call. The tiers and actions are illustrative and should be replaced with the institution's own definitions.

• Higher tier: Narrow approved use. Sensitive data redacted before it reaches the model or leaves it. Tool calls with external effects escalate for human approval. Requests outside the approved scope are blocked.
• Moderate tier: Allowed within a defined scope. Sensitive fields redacted. Exceptions and unusual tool calls escalate for review. Prohibited categories are blocked.
• Lower tier: Allowed under baseline rules. Prohibited content and data categories are blocked or redacted. Few interactions require approval.
• Tier change: When a tier is recalibrated, the matching policy is versioned and updated, so the record shows which rules applied before and after.

Evidence at the level of individual interactions and tool calls

Tiering is usually documented as a policy exercise: a methodology, an inventory and approval minutes. That documentation shows what the institution intended. It does not show what an AI system was actually permitted to do on a given day, or what it did. The gap is widest for systems already in production, where behavior shifts with prompts, connected tools and data.

Runtime enforcement can narrow that gap if each decision leaves a record. For a given interaction or tool call, an examiner-ready record would show the system involved, the tier in force, the policy version applied, the action taken (allow, redact, block or escalate), the outcome, and, where a human approved or rejected an action, who decided and when. Policy parameters need a documented link back to the tier assignment and its rationale, otherwise the record shows enforcement without showing why it was set that way.

Two limits are worth stating plainly. First, continuous records are one way to evidence ongoing monitoring of risk through the lifecycle, but whether a particular examiner accepts them for a given purpose is a supervisory question, so they are best treated as a complement to pre-deployment documentation rather than a replacement. Second, a record shows what was enforced against the policy as written. It does not show that the policy or the tier was right.

What stays outside runtime enforcement

Model risk management covers more than controlling behavior in production. NIST places testing, evaluation, verification and validation in its Map and Measure functions, and uses their outputs for risk treatment later. Validation is an analytical activity, separate from controls applied at runtime. The same applies to independent review, which depends on critical analysis by objective, informed parties and on records of testing and validation that can be examined independently.

Model development documentation, model lineage and dataset provenance also sit outside what an interaction-level enforcement record can demonstrate. Pre-deployment approval, including go or no-go decisions and minimum performance thresholds, is its own governance layer. Pre-deployment approval and runtime controls should each be evidenced, and neither substitutes for the other.

A practical sequence for risk teams is to confirm every AI system, including vendor and generative AI tools, has a tier and an owner. Then define, per tier, which actions are permitted, redacted, blocked or escalated, and where that is documented. Next, confirm that the tier, policy and outcome can be retrieved for a single interaction. Finally, assign an owner to each expectation that lives outside runtime, such as validation, lineage and independent review, and set a regular cycle for recalibrating tiers and policies.

Where Trussed fits

Trussed enforces policy in the execution path across models, agents, tools, MCP servers, AI sites and coding assistants. Policies can allow, redact, block, rate limit or escalate for human approval, applied to individual interactions and tool calls. Enforcement is at runtime, not reviewed after the fact, and it generates continuous audit-ready evidence mapped to frameworks including NIST, HIPAA, NAIC, NYDFS and the EU AI Act. Deployment is self-managed in the customer cloud, with configurable retention and data residency.

This supports the runtime portion described above: expressing tier decisions as enforced policy and producing a record of what was allowed and what happened. Trussed does not replace model validation, independent review or development documentation. It does not provide model provenance or model lineage, and it does not claim SR 26-2 certification or coverage.