SR 26-2 vs CRI Financial Services AI RMF: Building One Control Map After the Model Risk Guidance Amendment

What changed in the supervisory baseline

The Federal Reserve's SR 26-2 page, dated April 17, 2026, describes revised model risk management guidance. It highlights sound principles for effective model risk management and recognizes that practices appropriately vary among banking organizations based on their risk profiles and model usage. Proportionality is therefore built into the guidance, and any control map should record why a given control is applied at a given depth.

On May 1, 2026, a Fed official said in a speech that the Fed, together with the OCC and FDIC, recently amended its model risk management guidance to clarify that it does not apply to generative or agentic AI. The same speech said supervisors had over time expanded the scope of the previous guidance beyond its original purpose and applied it in unintended ways. It also stressed flexibility for banks to develop and manage AI in line with their own structure and business.

The practical consequence is that older assumptions need review. A control inventory that treated every AI system as an in-scope model under the earlier guidance should be revisited. Record the current applicability position and the date of the amendment, and avoid citing earlier expansive interpretations.

Supervisory expectation versus voluntary alignment

The CRI Financial Services AI RMF is a sector-specific framework. The NIST AI RMF, released in January 2023, is intended for voluntary use to improve how organizations build trustworthiness considerations into the design, development, use and evaluation of AI systems. Neither is a bank regulatory requirement by default. Alignment becomes an obligation for a bank only when its own policy adopts it.

This distinction drives the structure of a consolidated map. Each control needs a column stating its basis: supervisory guidance, bank policy, or voluntary framework alignment. Examiners can then see which controls the bank must defend as expectations and which it chose to adopt. For generative and agentic AI, runtime controls may rest on bank risk policy or voluntary frameworks rather than on model risk management guidance, and the map should say so plainly.

A control should be labeled overlap, partial overlap, unique or silent only after the framework text has been read side by side. Pre-filling those labels from assumption is how duplicate inventories become inconsistent ones.

Control domains classified by enforcement point

The table applies a general classification to the control domains risk teams usually compare: inventory, tiering, validation, monitoring, third-party risk, access and data controls, human oversight, and documentation. It describes where a control of that kind is typically enforced and what evidence it produces. It does not restate the wording of either framework.

• Inventory and risk tiering: Organizational. Decided by governance process before deployment. Evidence: inventory records, tiering rationale and approvals.
• Validation: Pre-deployment. Independent testing and review of a model before use. Evidence: validation reports and sign-offs. No runtime equivalent.
• Ongoing monitoring: Mixed. Performance and drift review is periodic and organizational. Policy conformance on each interaction can be checked at runtime. Evidence differs by type.
• Third-party AI risk: Mixed. Vendor due diligence and contracts are organizational. Limits on what data goes to a vendor model and which tools it may call can be enforced at runtime.
• Access and data handling: Runtime for individual requests: allow, redact or block based on user, data type and destination. Evidence: a decision record per interaction.
• Human oversight: Runtime for defined actions that require approval before a tool call proceeds. Accountability structures remain organizational.

Which overlapping controls can be enforced at runtime

Runtime enforcement acts on individual AI interactions and tool calls. A control qualifies when its requirement can be expressed as a decision on a single request: may this user send this data to this model, may this agent call this tool with these parameters, does this action need a human to approve it first. Access and data handling, restrictions on third-party model use, and approval gates for consequential actions fit that description. Each decision, whether allow, redact, block or escalate, can be recorded at the moment it is made.

That record is useful to an examiner because it shows what the system was permitted to do and what it did, rather than a statement of intended policy. It does not replace the rest of the stack. Model validation, model lineage and dataset provenance depend on pre-deployment testing and governance processes, and runtime enforcement does not address them. Those controls need their own owners and their own evidence, kept separate so the scope boundary is visible.

The broader point comes from general monitoring practice. Continuous monitoring supports near real-time risk management in a way that point-in-time review cannot, but it is a different activity from testing, evaluation, verification and validation. A bank needs both, and the map should show which is which.

Where Trussed fits, and where it does not

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 for human approval, at the level of individual interactions and tool calls. Enforcement is at runtime, not reviewed after the fact, and it generates audit-ready evidence that is mapped to frameworks including NIST. Deployment is self-managed in the customer cloud, with configurable retention and data residency.

Trussed does not cover model validation, model lineage or dataset provenance, and it is not a pre-deployment testing product or a GRC platform. In a consolidated map, it addresses the runtime rows and leaves the governance rows to the bank's existing processes. Trussed has run continuously in production at a regulated enterprise for more than 18 months. Insurance, a regulated financial sector, is where it is deepest. This page makes no claim of bank deployments.