SR 26-2 Governs Your Models. It Doesn't Govern Your Generative AI. Here's the Gap Your Program Has to Fill.

TL;DR

• SR 26-2, issued April 17, 2026, replaces SR 11-7 with risk-based validation cadence, a narrowed model definition, and explicit vendor model obligations
• The guidance explicitly carves out generative and agentic AI: “novel and rapidly evolving … not within the scope of this guidance”
• SR 26-2 still requires institutions to apply existing governance frameworks to AI outside scope — and examiners are already asking what that looks like
• GenAI governance requires a separate inventory, output controls, vendor due diligence beyond attestations, and consumer disclosure procedures that model risk frameworks don’t traditionally cover

The April 17, 2026 interagency guidance — the Federal Reserve’s SR 26-2, OCC’s Bulletin 2026-13, the FDIC’s companion letter — is the most significant update to model risk management in 15 years. It replaced SR 11-7, the 2011 guidance that had governed model governance across US banking. It modernized the model definition, moved validation cadence to risk-based timing, and brought vendor AI explicitly into scope.

Then it carved out the AI everyone’s actually worried about.

“Generative AI and agentic AI models are novel and rapidly evolving. As such, they are not within the scope of this guidance.”

One sentence. A carve-out that puts ChatGPT integrations, underwriting copilots, customer service bots, and autonomous agent workflows outside the framework regulators just updated for AI risk.

Examiners aren’t waiting for a second guidance cycle to close it.

What SR 26-2 Actually Changed

Before addressing the gap, the updates that are in scope deserve a clear read.

Narrowed model definition. SR 11-7 had an expansive model definition that large institutions applied broadly — including to spreadsheets with business-logic formulas. SR 26-2 explicitly excludes “simple arithmetic calculations, such as those found within spreadsheets, as well as deterministic rule-based processes and software.” For institutions that have been running 500-item model inventories partly composed of Excel models and workflow tools, this meaningfully reduces scope and lets model risk resources focus on systems that carry actual model risk.

Risk-based validation cadence. The informal default of annual revalidation under SR 11-7 is gone. SR 26-2 ties monitoring frequency to model risk magnitude, defined across four drivers: inherent risk (complexity, data quality, number of assumptions, interpretability), exposure (dollar volume, breadth of use), purpose (operational vs. decision support), and use (high-stakes vs. informational). High-risk models still require rigorous, frequent validation. Lower-risk models get proportionate treatment. This is operationally significant for institutions managing hundreds of models across different risk profiles.

Vendor models carry the same validation obligations as in-house builds. This is the sentence every vendor-heavy model governance program needs to re-read: attestations from vendors do not satisfy the validation requirement. If your firm deploys a third-party credit-scoring model, fraud detection system, or AML transaction monitoring engine from a vendor, your validation obligations are the same as if you built it internally. Receiving a vendor’s SOC 2 report and signing a model validation checklist does not satisfy SR 26-2. Your team validates the model against your use case — or you document why you can’t and accept the risk.

Principles-based language is explicit. SR 26-2 states directly that “the guidance does not set forth enforceable standards or prescriptive requirements.” This doesn’t mean ignore it. It means the principles define what good model governance looks like, and your program is evaluated against that standard in examination. The absence of prescriptive requirements shifts authority to examiner judgment — which means clearer documentation of your rationale matters more, not less.

The Carve-Out and Its Consequences

SR 26-2’s exclusion of generative and agentic AI wasn’t a drafting oversight. The agencies knew exactly what they were doing. Technology that changes quarterly can’t be constrained by guidance frameworks that move annually. Writing specific validation requirements for GPT-4 while GPT-5 is already in production would generate outdated standards before publication. The carve-out is pragmatic.

But its consequence is a governance gap at the exact intersection of AI risk that regulators, boards, and bank partners are asking about most.

The AI your CEO is demoing to the board — outside scope. The AI your customer service team uses to draft responses to complaints — outside scope. The AI your compliance team deployed to triage vendor risk questionnaires — outside scope. The agent workflow someone in operations built to route exception reports — outside scope.

SR 26-2 anticipated this tension and left a bridge: the guidance “directs institutions to apply their existing risk management and governance practices to determine appropriate controls for systems not covered.” That bridge clause is not an exemption. It’s a requirement with no defined standard — which is in some ways harder to satisfy than a defined standard, because examiner judgment fills the space.

The CSBS, in its September 2026 AI supervisory framework, put it bluntly (see: State Examiners Just Got an AI Playbook):

“Examiners are now asking every institution — regardless of size — how they govern the AI systems the model risk guidance doesn’t cover.”

What “Apply Your Existing Governance” Actually Requires for GenAI

The bridge clause sends you back to your general governance program. Here’s what that translates to in practice for generative AI.

A Separate GenAI Inventory

Traditional model inventories capture quantitative models. GenAI applications don’t fit cleanly. A GPT integration in your customer portal, an LLM copilot for your compliance team, an agent workflow that triages fraud alerts, a retrieval-augmented generation system pulling answers from internal policy documents — these are neither models in the SR 26-2 sense nor systems your traditional inventory was designed to capture.

They need their own inventory, with their own fields. At minimum: the system and vendor, the use case and user population, what data it accesses, whether outputs are human-reviewed or fed directly into decisions, and the potential harm from incorrect or biased output. This is the foundation every GenAI risk tiering framework — including CSBS’s Tier 1/2/3 classification — requires before you can do anything else.

Output Controls That Don’t Exist in Traditional Model Risk

Model validation tests whether a quantitative model performs as intended under specified conditions. GenAI governance has to test something harder: whether outputs are accurate, appropriate, and safe under conditions your team didn’t specify — including adversarial ones.

Prompt injection — a user crafting inputs that manipulate system behavior — has no analog in credit model validation. Hallucination — confident, plausible, incorrect responses — is a failure mode that traditional model monitoring doesn’t detect. Context leakage — sensitive data appearing in model outputs to unauthorized users — is a privacy violation that model risk frameworks weren’t built to catch.

Your governance program needs controls for each: input sanitization and scope limits on system prompts, output sampling and review cadence, escalation procedures for anomalous responses, and logging sufficient to reconstruct what the system said and why when a complaint arrives.

Vendor Due Diligence Beyond Attestations

SR 26-2’s prohibition on vendor attestations satisfying model validation applies to models in scope. For GenAI sitting outside scope, the same principle applies under your general TPRM and vendor risk frameworks.

“We use [LLM provider] and they’ve SOC 2’d” is not a risk assessment. Your due diligence for third-party GenAI needs to cover: how the model was trained and whether training data creates regulatory exposure (biased training data, PII, copyright); what data your users send to the vendor’s API; whether fine-tuning or retrieval-augmented generation incorporates proprietary data into vendor training loops; what the vendor’s incident notification SLA looks like; and what happens to your service if the vendor changes, degrades, or discontinues the model.

The vendor questionnaire you use for traditional software vendors doesn’t ask these questions. You need a different questionnaire for AI system vendors — and vendor attestations don’t substitute for having your own answers.

Consumer Disclosure and UDAAP

If a GenAI system produces consumer-facing outputs — explanations, recommendations, adverse action notices, customer service responses — you have compliance obligations that sit entirely outside the model risk framework.

CFPB and banking regulators have been consistent: adverse action explanations produced by AI must be accurate, specific, and principal-reason compliant under ECOA and Reg B. “Our algorithm determined this” doesn’t satisfy the requirement. If your GenAI system contributes to adverse decisions, the disclosure procedure for those decisions needs to be part of your governance program before the use case goes live — not resolved reactively after a complaint.

Board-Level Reporting That Covers What’s Outside SR 26-2

The FS AI RMF’s GOVERN function requires board-level visibility into AI risk, including GenAI, as a governance control. Most model risk reporting frameworks cover traditional model KRIs: validation status, red-flag count, overdue reviews. Most don’t cover GenAI-specific metrics: incident count by use case, output error rate by deployment, prompt injection attempts flagged by monitoring, vendor API changes that could affect behavior.

Boards don’t need to understand the architecture. They need to know which GenAI systems are in production, what the highest-risk use cases are, and what the open issues look like. If your current board AI reporting covers traditional models but leaves GenAI applications off the page, that’s a gap the next examination may surface. (See: AI Governance Board Reporting in 2026 for what the FS AI RMF specifically requires at the board level.)

The Reference Frameworks That Fill the Gap

SR 26-2 was designed as the floor for traditional quantitative model risk. For GenAI, three frameworks fill what the carve-out left open:

CSBS AI Supervisory Framework (September 16, 2026). The Conference of State Bank Supervisors released a five-document package giving state examiners structured tools for reviewing AI — including generative and agentic AI explicitly. Eight examiner questions. Three risk tiers. Nonbank AI Supplements for money transmitters, consumer lenders, and mortgage companies. State agencies supervise 3,355 of approximately 4,233 FDIC-insured banks, plus large nonbank populations. This is the framework the examiner at your next state exam is working from.

FS AI RMF (U.S. Treasury, February 2026). The Financial Services AI Risk Management Framework provides 230 control objectives organized into GOVERN, MAP, MEASURE, and MANAGE functions. GOVERN translates into board and executive AI reporting requirements. MAP provides the use-case categorization methodology for deciding what governance GenAI deployments require. Designed specifically for financial services, it covers GenAI without the SR 26-2 carve-out.

NIST AI RMF 1.1. The updated NIST framework covers the full AI lifecycle — including GenAI and agentic systems — with detailed guidance on incident management, output monitoring, and bias testing. Not financial-services-specific, but the vocabulary and structure are what federal examiners and bank partners reference when their own framework doesn’t address GenAI directly.

For EU-market deployments, the EU AI Act’s Digital Omnibus deferral shifted the compliance deadline for credit-scoring AI to December 2027 — but Article 50 transparency obligations and prohibited practice rules are already in effect.

So What?

SR 26-2 is a meaningful improvement over SR 11-7 for the models it covers. Risk-based validation cadence, vendor model obligations, narrowed definition — these are practical upgrades for model risk programs that had been operating on guidance written before machine learning was mainstream.

But the carve-out created a two-track problem. Traditional quantitative models now have updated, cleaner guidance and proportionate validation overhead. The GenAI tools your business is deploying — tools your executives are presenting to the board, your customers are interacting with, and your regulators are examining right now — operate under a governance framework your organization may not have built yet.

Three questions answer whether you’re exposed:

1. Do you have a GenAI inventory with risk tiers distinct from your SR 26-2 model inventory?
2. Do you have output monitoring and input controls designed for GenAI failure modes — not just quantitative model monitoring?
3. Does your vendor due diligence for third-party LLMs go beyond attestations to your own validation and oversight?

Those three questions are the beginning of the framework SR 26-2 didn’t write.

If you’re building AI governance from a standing start — a structured AI use case inventory, 44-question pre-deployment scorecard, and 31-question third-party vendor questionnaire designed for financial services — the AI Risk Assessment Template & Guide covers all three tracks.

Sources:

• Federal Reserve SR 26-2: Revised Guidance on Model Risk Management
• CIMCON: SR 26-2 Regulates Your Models, Not Your AI Agents
• Domino.ai: What Changes with SR 26-2
• CSBS AI Supervisory Framework — Consumer Finance Monitor
• Baker Tilly: Updated Interagency Guidance on Model Risk Management (SR 26-2)