SR 26-2 Implementation Checklist for Banks: 90-Day Plan

What SR 26-2 Implementation Requires

Banks operating AI or model-driven systems are increasingly expected to demonstrate governance, oversight, and risk management capabilities that go beyond traditional IT controls. This category of supervisory expectation typically requires an accurate inventory of AI and model systems, defined ownership for each system, ongoing monitoring for performance and behavioral drift, and documentation that can withstand examiner review.

Because the specific provisions, effective dates, and terminology used in SR 26-2 have not been independently confirmed in the source material used to produce this guide, compliance teams should treat the milestones below as a structured implementation approach rather than a verbatim summary of the regulatory text. Verify exact requirements against the official supervisory letter and confirm with legal or regulatory affairs counsel before publishing internal policy language or examiner-facing statements.

How AI-Specific Guidance Builds on Existing Model Risk Frameworks

Model risk management guidance issued in 2011 by the Federal Reserve and OCC (commonly referenced as SR 11-7) established foundational practices still used across banking today: model inventories, independent validation, ongoing monitoring, and clear documentation standards. Supervisory attention to AI systems generally extends these same principles to address risks that traditional statistical models did not present, including training data provenance, less interpretable model behavior, reliance on third-party AI tools, and systems that take autonomous or semi-autonomous actions rather than only producing scores or predictions.

Banks with mature SR 11-7 programs typically have a head start, since inventory, validation, and monitoring infrastructure can often be extended rather than rebuilt. Any direct mapping between specific SR 26-2 provisions and SR 11-7 requirements should be confirmed against the official text before being represented to examiners as an equivalence.

90-Day Readiness at a Glance

• Days 1–30

  Governance foundation: inventory, roles, and policy baseline.

• Days 31–60

  Operational controls: monitoring, testing, and escalation paths.

• Days 61–90

  Audit readiness: documentation, evidence packages, and examiner walkthroughs.

Suggested 30/60/90-Day Implementation Sequence

Days 1–30: Governance Foundation

Complete or update the AI and model system inventory, assign system owners, confirm reporting lines to risk and audit committees, and draft a policy baseline covering approval, monitoring, and escalation responsibilities.

Days 31–60: Operational Controls

Implement or validate monitoring for model and AI system performance, define thresholds for drift or anomalous behavior, establish exception handling procedures, and confirm access and permission controls for systems that can take automated actions.

Days 61–90: Audit Readiness

Assemble documentation packages covering inventory, validation, monitoring history, and exception logs. Conduct an internal walkthrough simulating examiner questions and remediate identified documentation or control gaps before the review window closes.

Roles and Cross-Functional Coordination

Implementation plans of this kind typically require coordination across four functions. A board risk committee or equivalent oversight body typically receives periodic reporting throughout the 90-day window rather than a single end-of-period briefing, since supervisory reviews generally expect evidence of ongoing oversight rather than a point-in-time exercise.

Documentation and Audit Trail Readiness

• Maintain a current inventory of AI and model systems with classification by risk tier and business use.
• Retain records of validation activity, including scope, findings, and remediation status for each system.
• Log monitoring results and exceptions in a format that can be reproduced on request rather than reconstructed after the fact.
• Document approval and change history for systems that have been modified, retrained, or reconfigured.
• Record access and permission changes for systems capable of taking automated or semi-autonomous actions.
• Preserve evidence of board or committee reporting on AI risk topics across the implementation period.

Where Runtime Governance Fits

A significant portion of examiner-facing documentation depends on evidence generated while AI systems are operating, not evidence assembled after the fact. Runtime governance capabilities, including runtime policy enforcement, runtime monitoring, and audit logging, are designed to capture this evidence continuously rather than through periodic manual review.

For banks operating AI agents or tool-using systems, capabilities such as agent identity, defined agent permissions, least privilege enforcement, and tool approval workflows can support the operational controls described in the 60-day phase above by producing an ongoing record of what a system was authorized to do and what it actually did.

Frequently Asked Questions