SR 26-2 vs ISO/IEC 42001: Does an AI Management System Satisfy Bank Model Risk Guidance?

Two documents with different jobs

SR 26-2 is the Federal Reserve's Revised Guidance on Model Risk Management, dated April 17, 2026. It describes itself as highlighting sound principles for effective model risk management and recognizes that practices appropriately vary among banking organizations based on their risk profiles 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. A practice that is effective for one institution may be ineffective for another with a different risk profile or a different model purpose.

ISO/IEC 42001:2023, published in December 2023, is an international standard specifying requirements for establishing, implementing, maintaining and continually improving an AI management system. It is built around a Plan-Do-Check-Act cycle, covers risk assessment through risk treatment for AI, and applies to organizations of all sizes and sectors. It is a voluntary standard, not law. As of November 2026, nothing in either document makes one a substitute for the other.

That difference shapes the comparison. One document describes how an organization runs a management system for AI. The other describes what supervisors expect a bank to do about model risk. Because SR 26-2 allows practice to vary by institution, any crosswalk between them is specific to your bank, not a universal checklist.

Crosswalk across six dimensions

The table compares the nature of each document along the dimensions risk teams usually map first. It is a framing aid, not a clause-level mapping.

• Scope: SR 26-2: model risk at banking organizations, scaled to risk profile and model use. ISO/IEC 42001: AI management across any sector, for organizations developing, providing or using AI systems.
• Accountability: SR 26-2: the bank is ultimately responsible for effective practices. ISO/IEC 42001: the organization sets policies, objectives and roles within its management system.
• Lifecycle: SR 26-2: principles applied to a bank's own model lifecycle. ISO/IEC 42001: lifecycle processes organized under Plan-Do-Check-Act and continual improvement.
• Validation and challenge: Model-level activities the bank must perform and evidence. A management system can define the process but does not itself validate or challenge any model.
• Ongoing monitoring: SR 26-2 expects effectiveness in practice. ISO/IEC 42001 supports review and improvement of the system, which is distinct from performance monitoring of individual models.
• Documentation: Both depend on records. ISO/IEC 42001 documents the management system. Examiners will also look for records of how specific AI systems behaved.

What an AI management system supports

ISO/IEC 42001 is useful where model risk programs are weakest in practice: consistency. It establishes policies, objectives and processes for the responsible development, provision or use of AI systems. For a risk leader, that supports defined roles, a repeatable intake and approval process, an inventory that includes AI systems, documented lifecycle steps and a cycle for reviewing and improving all of it.

This matters most for newer AI use cases that sit awkwardly in a traditional model inventory, such as third-party and generative systems. A management system gives them an owner and a process, and it creates the documentation trail that a model risk function can build on.

For mapping work, NIST has published a crosswalk between the NIST AI RMF and the final draft of ISO/IEC 42001. It is a reasonable starting structure, though it is a NIST document and not a mapping to SR 26-2. Linking either framework to SR 26-2 remains your own analysis, and it should be done against the full guidance text and your bank's risk-based approach.

Where gaps remain

The gaps appear where a management system stops and model-level proof begins. Three stand out.

First, validation and effective challenge. A management system can require that validation happen and define who is responsible. It does not perform the validation, and a certificate does not show that a particular model was independently challenged. NIST AI RMF MEASURE 1.3 points to internal experts who were not front-line developers, or independent assessors, in regular assessments. That is a NIST reference, but it illustrates the independence question your validation function must answer and document.

Second, ongoing performance monitoring. Reviewing the management system on a cycle is different from tracking how a specific model performs against thresholds and acting when it drifts. NIST MEASURE 1.2 similarly calls for regular assessment of metrics and the effectiveness of existing controls.

Third, evidence of behavior. Policies describe what an AI system should be permitted to do. An examiner will reasonably ask what it was permitted to do and what it actually did. Management system records rarely answer that for individual interactions in production. Because accountability stays with the bank, ISO/IEC 42001 conformance should not be presented as satisfying SR 26-2.

Where Trussed fits

Trussed is control, provenance and evidence infrastructure for consequential AI. It enforces policy in the execution path for individual interactions and tool calls across models, agents, tools and MCP servers. Each interaction can be allowed, redacted, blocked, rate limited or escalated for human approval. Enforcement generates continuous audit-ready evidence, mapped to frameworks including NYDFS, NAIC and NIST, with self-managed deployment in the customer cloud and configurable retention and data residency.

This addresses the behavior gap described above. It does not replace model validation, ISO/IEC 42001 certification or a bank's governance program. Trussed customers span four regulated verticals: insurance, pharma, healthcare and education. Insurance, a regulated financial sector, is where Trussed is deepest. Trussed makes no claim of banking deployments. Its relevance to bank model risk management is the runtime evidence it produces, which supports the documentation and monitoring work your program already owns.