SR 26-2 vs NIST AI RMF: Which Framework Governs Bank Generative AI Controls?

Legal and supervisory standing

SR 26-2 is a Federal Reserve supervisory letter titled Revised Guidance on Model Risk Management, dated April 17, 2026. It attaches Supervisory Guidance on Model Risk Management, which describes itself as highlighting sound principles for effective model risk management. It recognizes that practices appropriately vary with each bank's risk profile and model usage. It also states that each banking organization is ultimately responsible for adopting practices that are appropriate and effective for the risks it faces.

The NIST AI Risk Management Framework (AI RMF 1.0, NIST AI 100-1) was published on January 26, 2023 and is intended for voluntary use. Its purpose is to help organizations manage risks to individuals, organizations and society associated with AI. NIST released the Generative AI Profile, NIST AI 600-1, on July 26, 2024. It is a companion resource to the AI RMF for generative AI, not a separate framework, and the final version superseded the earlier draft.

The practical consequence, as of November 2026, is an asymmetry. A bank should expect to explain its generative AI practices against the supervisory guidance. It chooses whether and how to cite NIST. Adopting the NIST AI RMF does not transfer or satisfy the bank's own responsibility under SR 26-2. Internal policy should label each reference accurately so that neither status is overstated.

Crosswalk by generative AI control category

The table maps each control category to the SR 26-2 language that bears on it and to the NIST resource a bank could use to structure it. The mapping is interpretive. Neither document prescribes it, and SR 26-2 is written around models generally. Applying it to generative AI is a judgment each bank makes and documents.

• Inventory: SR 26-2: an effective inventory holds enough information to understand model risk individually and in aggregate, with detail varying by complexity and usage. NIST: AI RMF and AI 600-1 vocabulary can inform which attributes to record. The attributes are the bank's decision.
• Validation: SR 26-2: model governance across the lifecycle, including regular assessment of limitations. NIST: testing, evaluation, verification and validation (TEVV) resources from the NIST AI Resource Center.
• Usage policy: SR 26-2: policies that define risk management expectations and a framework for assessing the magnitude of model risk. NIST: the AI RMF and AI 600-1 offer structure for defining permitted uses and risk tiers.
• Monitoring: SR 26-2: an ongoing monitoring plan may assess limitations over time and include procedures for responding to issues before and after approval. NIST: measurement and management of risk after deployment.
• Evidence: SR 26-2: adequate documentation supports effective model risk management. NIST: documentation practices can be organized against AI RMF categories. What counts as sufficient evidence is a bank design choice.

Where generative AI strains model-centric controls

Traditional model risk practice centers on a model that is developed, validated, approved and then monitored. Generative AI stresses three assumptions in that sequence.

First, outputs are non-deterministic. The same input can produce different outputs, so pre-approval validation characterizes behavior under test conditions but cannot fully describe behavior in production. Ongoing monitoring and runtime controls carry more weight.

Second, systems can call tools. Once a model can retrieve records, send messages or trigger actions, the risk sits in what the system is permitted to do, not only in what it says. A control set that covers only model outputs leaves that authority unexamined.

Third, many generative models are supplied by third parties. The bank does not control the weights or the timing of vendor changes. The inventory, the usage policy and the monitoring plan all have to cover externally hosted models, and the bank still owns the outcome.

These pressures do not make SR 26-2 inapplicable. Its principles of risk-commensurate policy, inventory, monitoring and documentation still apply. They change how a bank satisfies those principles, and the evidence an examiner would find convincing.

Building one control set with dual references

Start with SR 26-2 principles as the rows of the crosswalk. Use the control categories of inventory, validation, usage policy, monitoring and evidence as the columns, and place the NIST AI RMF and AI 600-1 elements in the cells as the implementing catalogue. This keeps the supervisory expectation as the organizing logic and prevents the voluntary framework from becoming a second, competing requirement set.

Then scale controls to risk. SR 26-2 allows practices to vary by risk profile and model usage, so a tiering scheme for generative AI use cases is defensible. A low-risk internal drafting assistant and an assistant that can call tools against customer data should not carry identical controls.

Assign ownership inside the policy structure. Each control needs a named owner, and the policy should specify how model limitations are assessed and how issues are handled before and after approval. Finally, check the mapping against the full texts of SR 26-2, NIST AI 100-1 and NIST AI 600-1 before it is adopted. Cited references that overstate either document's status create more examination risk than they remove.

• Rows: SR 26-2 principles. Columns: the five control categories
• Cells: NIST AI RMF and AI 600-1 elements, each with an internal control reference
• Tiers: control depth set by use-case risk and model usage
• Owners: one accountable owner per control, defined in policy

Where runtime enforcement fits

Inventory, validation and policy ownership are bank processes. The runtime layer is different. It determines whether a policy is applied to each interaction and whether evidence of that application exists.

Trussed enforces policy in the execution path across models, agents, tools and MCP servers. It can allow, redact, block, rate limit or escalate for human approval, on individual interactions and tool calls. Enforcement happens at runtime, not after the fact, and it generates audit-ready evidence mapped to NIST, among other frameworks. This addresses the runtime decision records and approval records listed above. It does not replace the inventory, validation or policy work, and it does not provide model lineage or end-to-end tracing of agentic workflows.

Trussed is deepest in insurance, a regulated financial sector, and runs in production for customers across four regulated verticals. Banks should evaluate any runtime control against their own SR 26-2 crosswalk, not against vendor framing.