Model Risk Management Software vs Runtime Control Plane: What Each Covers Under SR 26-2

What SR 26-2 says that matters for this comparison

SR 26-2 is a Federal Reserve letter dated April 17, 2026, transmitting revised model risk management guidance. The agencies updated the guidance based on supervisory experience and industry feedback since SR 11-7, with an emphasis on a risk-based approach tailored to each banking organization's model risk profile, size and complexity. As of November 2026, the guidance states that it does not set enforceable standards or prescriptive requirements. For that reason, this page avoids saying any tool category is required by SR 26-2.

Three features of the text shape the comparison. First, it 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 and deterministic rule-based processes and software. Whether a given AI system falls inside that definition is a scoping decision each institution should document.

Second, validation evaluates whether a model performs as expected, including its reliability and limitations, and generally occurs before first use. Ongoing monitoring then evaluates performance as products, clients, data relevance or market conditions change. Third, where a model has limitations, sound practice includes controls such as limits on model use or closer performance monitoring, and procedures for responding to issues. That last language is the nearest the guidance comes to in-production control. It does not say those controls must be automated or applied to each interaction.

What model risk management software covers

Lifecycle MRM software organizes the work that surrounds a model. Typical capabilities include a model inventory with risk ratings, documentation, validation workflows, issue tracking and scheduled review. These map directly to the parts of SR 26-2 concerned with scope, validation, ongoing monitoring, governance and documentation.

The evidence it produces is artifact-based: which models exist, who owns them, how they were rated, what validation found, which issues are open and when each model was last reviewed. An examiner asking how the institution identifies, validates and oversees its models is asking a question this layer is built to answer.

The timing is the constraint. These activities happen before deployment or after the fact. Validation assesses a model against expected behavior, and periodic review looks back over a period. Neither constrains what an AI system does during a particular interaction, and neither records what was permitted at that moment.

What runtime enforcement covers

Runtime enforcement applies policy in the execution path, at the level of individual interactions and tool calls. For each request, the policy decision is made before the action completes: allow, redact, block, rate limit, or escalate for human approval. The decision is enforced at runtime, not reviewed after the fact, and each outcome is recorded as audit-ready evidence.

This addresses a question lifecycle tooling cannot: what was this system actually permitted to do at that moment, and what happened? It also gives concrete form to the idea of limits on model use. A limit written in a validation report becomes a policy that is applied and evidenced on each call.

Trussed provides this layer. It enforces policy in the execution path across models, agents, tools and MCP servers, and generates audit-ready evidence mapped to frameworks including NIST. Its deployment is self-managed in the customer cloud, with configurable retention and data residency. Insurance, a regulated financial sector, is where Trussed is deepest. The platform has run 18+ months in continuous production in a regulated enterprise, at 99.95% uptime on live production traffic.

Side-by-side: what each layer addresses

The table separates the two layers by point of control, SR 26-2 coverage, evidence and the examiner question each can answer. The layers are complementary. Gaps appear only when one is assumed to cover the other.

• Point of control: MRM software: before deployment and in periodic review afterward. Runtime enforcement: during each interaction and tool call in production.
• SR 26-2 areas addressed: MRM software: scope, inventory, validation, monitoring processes, governance and documentation. Runtime enforcement: limits on use and response to issues, applied in the execution path.
• Evidence produced: MRM software: inventories, validation reports, issue records, review history. Runtime enforcement: per-decision records of what was allowed, redacted, blocked, rate limited or escalated.
• Examiner question answered: MRM software: which models exist, how they were validated, who is accountable. Runtime enforcement: what a system was permitted to do at a given moment, and what it did.
• What it cannot show: MRM software: behavior in an individual production interaction. Runtime enforcement: why a model was judged sound, or how it was developed and validated.
• Typical owners: MRM software: model risk and validation teams. Runtime enforcement: security and platform teams, with risk oversight of the policy set.

Limits of runtime enforcement and the continuing need for MRM tooling

Runtime enforcement does not validate a model. It cannot assess conceptual soundness, judge whether a model's limitations are acceptable, or decide whether a system belongs in the inventory at all. Those are lifecycle judgments, and SR 26-2 places validation and governance at the center of the framework.

It also does not establish scope. Whether an AI system meets the guidance's definition of a model, or falls under the exclusion for deterministic rule-based software, is a governance decision that belongs in MRM documentation. Runtime enforcement applies policy whichever way that decision goes, but it does not make the decision.

Finally, Trussed does not provide model lineage or dataset provenance, and it does not trace agentic workflows end to end. Its evidence covers enforcement decisions on individual interactions and tool calls. Institutions that need lineage or full workflow tracing must source them elsewhere.

The more useful framing is feedback. Runtime evidence shows how a system behaves under real use. That informs validation, supports ongoing monitoring and gives issue tracking concrete cases. Without the lifecycle layer, enforcement evidence has no inventory or validation context. Without the runtime layer, lifecycle records describe intended behavior but not what occurred.