SR 26-2, the revised model risk management guidance issued on April 17, 2026, replaces SR 11-7 and places generative and agentic AI outside its scope. That leaves a governance gap: banks still have to control these systems, but there is no supervisory checklist for how. This guide explains what SR 26-2 says, where the gap sits, what examiners are likely to ask, and what evidence a bank should be able to produce. It also shows how Madison, Lyzr’s agentic GRC product for US banks and credit unions, and Opencontroller, Lyzr’s agent control plane, address each part of the gap.
TL;DR
- What changed: SR 26-2 (April 17, 2026, with OCC Bulletin 2026-13 and FDIC FIL-15-2026) replaces SR 11-7 with a risk-based, materiality-sensitive approach to model risk.
- What it leaves out: generative and agentic AI are outside its scope. That is not an exemption: a bank’s own risk management and internal controls should govern them.
- The gap: no checklist, no named owner by default, and traditional model metrics do not show who authorised an agent, what it was allowed to do, or what it actually did.
- What to build: an inventory with owners and risk tiers, defined permissions, approval gates, retained evidence and a way to re-test when a model, prompt or vendor changes.
- Our answer: Madison maps expectations to your policies and controls and holds vendors, models and agents as governed objects with owners and evidence. Opencontroller governs the agents themselves.
- Fair warning: much of the “what examiners ask” commentary online is vendor interpretation, not supervisory text. We label it as we go.
What does SR 26-2 say?
SR 26-2 is the Federal Reserve’s revised guidance on model risk management, issued alongside OCC Bulletin 2026-13 and FDIC FIL-15-2026. It replaces SR 11-7, the 15-year-old framework that banks have used since 2011. Four points matter for AI governance.
| Point | What it means | Source type |
|---|---|---|
| Replaces SR 11-7 | SR 11-7 is retired and should not be cited as a current standard. | Foundational glossary, summarising the guidance. |
| Risk-based, materiality-sensitive | Validation and monitoring effort scales with how material a model is, instead of one checklist for all. | arXiv paper (July 2026) and Domino webinar page. |
| Most relevant above $30B | The guidance states it is most relevant to larger banks. Smaller banks are not formally in its centre but apply it by proportionality. | Law firm summary (Orrick). Verify against the primary text. |
| Generative and agentic AI are outside scope | The guidance excludes them, describing them as novel and rapidly evolving, and says a bank’s own risk management and governance practices should guide the controls. | Foundational, arXiv paper and Curity, each reading the guidance. |
We have not reproduced the guidance text. Confirm every point against the Federal Reserve, OCC and FDIC originals before relying on it.
The exclusion is the part that matters here. As one summary puts it, banks are expected to govern generative and agentic AI through their own AI governance programs, and cannot assume that running an AI system through existing model validation covers it. For the broader distinction between using AI in compliance and governing that AI, see AI in compliance vs AI governance.
What is the AI governance gap?
The AI governance gap is the space between what model risk guidance covers and what banks now deploy. Traditional models, such as credit scorecards, have an inventory, independent validation and monitoring. Generative and agentic AI sit outside that structure, yet they draft adverse-action language, summarise policies, call tools and take actions. Nobody hands the bank a checklist for them.
Commentary on the gap, mostly from vendors and researchers, converges on five problems:
| Gap | What goes wrong |
|---|---|
| No inventory or owner | No observed norm for who owns AI governance. Gaps form at the seams: tool permissions, vendor-embedded features and the retained record. |
| Unclear authorisation | The bank cannot show which agent acted, under whose authority, or what it was permitted to do. |
| Drift without retraining | Behaviour changes through prompt edits, new instructions or a vendor model update, with no retrain event to trigger review. |
| Thin evidence | Pre-deployment testing is a point in time, and periodic review samples behaviour. Neither shows what happened in a specific interaction. |
| Vendor-embedded AI | Externally sourced AI is becoming as hard to govern as internally built AI, and vendor changes may arrive without notice. |
Synthesised from Trussed AI, iTuring.ai, Domino Data Lab and Curity (all vendors) and an arXiv paper on SR 26-2-compatible governance. These are their analyses, not supervisory text.
What are examiners likely to ask?
No supervisor has published a checklist for generative or agentic AI. What exists is commentary. Trussed AI cites Federal Reserve testimony pointing to sound development practices, testing and human-in-the-loop systems, an OCC description of guardrails and human accountability, and an FDIC view that third-party engagement is a critical part of adoption. Its own inference, which it flags, is that examiners will test AI against the bank’s existing third-party, operational risk and information security practices, and any framework the bank chose, such as the NIST AI RMF.
| Likely question | What good evidence looks like |
|---|---|
| What AI do you use, including AI inside vendor products? | An inventory that includes vendor-embedded generative AI, with a risk tier for each use. |
| Who owns each one? | A named owner for each lifecycle stage, not a team alias. |
| What was the system allowed to do? | A written permission scope per use case, enforced and retained. |
| What did it actually do, and who approved or stopped it? | A per-use record of actions and human approvals. |
| How do you know it still works after a change? | A re-test on every model, prompt or vendor change, with results kept. |
| How did you decide what governance to apply? | A written scope decision, approved by a designated body, with a trigger to revisit it. |
An inference from vendor commentary, not an examiner checklist. Reports that examiners are already asking for drift and hallucination evidence come from second-hand sources we could not verify.
The agencies have been reported to be preparing a request for information on model risk management and AI. We could not confirm its timing, so treat it as a reason to build a trigger to revisit your approach, not as a date.
Why do traditional model metrics fall short for agents?
Model risk was built for systems that take inputs and return a number. An agent plans, calls tools and acts, so accuracy of an output is only part of the story. Researchers writing about SR 26-2-compatible controls make the same point: individually acceptable skills can create new risks when they are combined into multi-step workflows.
| Question | Traditional model | Generative or agentic AI |
|---|---|---|
| What is governed? | A model with fixed inputs and outputs. | A workflow: prompts, tools, data it retrieves and actions it takes. |
| What changes behaviour? | Retraining, which is a visible event. | A prompt edit, a new instruction or a vendor model update, which may not be visible. |
| What does validation show? | Performance at a point in time. | Little about a specific interaction. Records of actions matter as much as predictions. |
| Where does risk sit? | In the output being wrong. | In the output, and in what the agent was allowed to do with it. |
| Who is accountable? | A model owner. | A cross-functional group, with named owners at each stage. |
Who authorised the agent, and what could it do?
For agents that act, the sharpest part of the gap is authorisation. Curity, an identity vendor, frames it as a question a bank has to answer: can you establish which agent acted, under whose authority, and what it was permitted to do? The article is vendor content and its reading of SR 26-2 is its own, but the operational points are sound.
| Practice | Risk | Safer pattern |
|---|---|---|
| Agent uses the employee’s own token | Downstream systems cannot tell the agent’s actions from the human’s, and the agent inherits more access than the task needs. | A distinct agent identity, with delegation recorded. |
| Broad standing service account | The audit log shows an agent acted, without the mandate behind it. | Scope bound to purpose, with the accountable owner preserved. |
| High-impact actions run unattended | An agent built to reconcile a ledger could move funds because the initiating employee can. | Explicit approval for high-impact actions. |
Patterns from Curity’s article on agent authorisation (vendor content). Service accounts are not inherently wrong; the issue is broad standing access with no record of delegated authority.
What evidence should a bank be able to produce?
Whatever framework you choose, four records answer most of what a supervisor is likely to ask:
1. An inventory.
Every AI use, including AI inside vendor products, with a risk tier and an immutable ID. You cannot govern what you cannot list.
2. A named owner.
One accountable person per use, with named owners across risk, compliance, security and technology for each lifecycle stage.
3. A permission scope.
What each agent may read and change, written down and enforced, with approval required for high-impact actions.
4. A decision record.
Who approved or stopped what, in what role, on which version, kept so it can be retrieved rather than rebuilt.
Who should own AI governance?
No industry norm exists. Trussed AI offers a starting map, which it presents as something to adapt rather than a standard. It is a useful way to test whether every stage has an owner.
| Function | Suggested responsibility |
|---|---|
| Business owner | The use case, human review and a proposed risk tier. |
| Model risk | Applies lifecycle principles by analogy and sets materiality tiers. |
| Compliance | Maps obligations to the use and sits on the approval path. |
| Information security | Data exposure, access, tool permissions and monitoring. |
| Technology | Inventory, enforcement and evidence records. |
| Senior risk committee | Framework choice, residual risk acceptance and the trigger to revisit. |
One vendor’s suggested map, not a regulatory requirement.
What should a community bank do now?
SR 26-2 states that it is most relevant above $30B in assets, so a smaller bank applies it by proportionality rather than directly. That makes selling or buying “SR 26-2 compliance” a poor frame for a community bank. The practical goal is a governance program a bank can defend, scaled to its size and its use of AI.
Step 1: Write a scope decisionRecord which frameworks govern generative and agentic AI at your bank, who approved that choice and when you will revisit it. Link it to your existing risk management and third-party programs.
Step 2: Build the inventoryList every AI use, including AI embedded in vendor products and agents built by business teams. Give each an owner and a risk tier. See our AI agent inventory guide.
Step 3: Define what each agent may doWrite down the data and tools each agent can reach. Give each its own identity, require approval for high-impact actions and avoid shared tokens.
Step 4: Keep the evidenceRetain a record per use of the actions taken and the human approvals, so an examiner’s question is answered by retrieval.
Step 5: Re-test on every changeRe-run your test set whenever a model, prompt or vendor changes. For a method, see how to evaluate a regulatory change agent.
How does Madison address the gap?
Madison is Lyzr’s agentic GRC product for US banks and credit unions. It plays two roles in this story. It is the compliance layer that holds your obligations, policies, procedures and controls as one connected model, and it holds vendors, models and agents as governed objects on the same map, with owners and evidence attached. It is also an agentic system itself, so the same expectations apply to it. It is built to be governable: agents propose, a named person decides, and it never remediates on its own.
Third-party and AI oversight is live now, alongside regulatory change and coverage, and examinations and issues.
Gap by gap: what a bank needs and how Madison approaches it
| Gap | What a bank needs | How Madison approaches it |
|---|---|---|
| No inventory or owner | Every AI use listed, owned and tiered. | Vendors, models and agents are held as governed objects on the same map as your obligations, policies and controls, each with an owner and evidence. |
| Expectations scattered across documents | AI expectations tied to your policies and controls. | The connected model links an obligation to the policy that carries it and the procedures and controls beneath, and shows coverage gaps such as an obligation with no policy or no control. |
| Unclear authorisation | A named person decides, and the decision is on the record. | Every consequential output is a recommendation waiting on a named person. Each decision is signed against the exact version approved, with the signer’s role at the time. |
| Thin evidence | A trail an examiner can follow. | Every output traces back to the rule text it came from, and examiner requests are answered from the chain behind them. |
| Agents that act | Limits on what a system can change. | Madison reads from your systems and writes nothing back to your core banking system. |
| Findings and remediation | Gaps in AI controls tracked to closure. | The model runs on through tests, findings, remediation and evidence, so a failed control already has its owner, procedure and policy attached. |
Madison governing itself
Because SR 26-2 excludes agentic AI, a bank that adopts Madison has to govern Madison’s agents under its own framework. We think that is the right question to ask of any agentic vendor, ours included. Use the questions below on every agent you adopt.
| Question to ask the vendor | What Madison shows |
|---|---|
| Who decides? | A named person accepts, amends or rejects each consequential output. |
| What can it change? | No write-back to your core banking system. |
| What record is left? | Signed decisions on the exact version, with the signer’s role. |
| Can I trace an answer? | Outputs trace to the rule text they came from. |
| How do I govern the agents themselves? | Register them in a control plane such as Opencontroller, with an owner and approvals. |
Where does Opencontroller fit?
Opencontroller by Lyzr is the control plane that governs the agents. Madison answers what the bank must do and where its coverage has gaps. Opencontroller keeps each agent registered, owned and approved, and records what it did. It complements, rather than replaces, your GRC and model risk tools.
Gap by gap: what Opencontroller adds
| Gap | What a bank needs | How Opencontroller by Lyzr helps |
|---|---|---|
| No inventory | An inventory that matches what is running. | A registry with an immutable ID per agent, plus discovery that compares it with the running estate, including other clouds and devices. |
| No owner | A named person accountable for each agent. | Owner, team, framework, repository, environments and live version on every record. |
| Unclear authorisation | Approval before a change, with duties separated. | Approvals with separation of duties, so a requester cannot approve their own change, even if they are an owner or administrator. |
| Uncontrolled spend and scope | Limits on what agents can consume. | Budgets per agent. |
| Thin evidence | A record an examiner can follow. | A signed audit trail with approver identity, and request traces in OpenTelemetry GenAI conventions. |
| Change without retest | A check before a changed agent goes live. | A simulation engine with golden and challenger datasets, a regression gate and adversarial probes. |
It runs in your own cloud account, and agents hosted elsewhere register as external entries and are governed without being moved. For the concept in depth, read the AI agent registry guide and our overview of AI agents for mid-size banks.
Map your AI governance gap
Bring your policy library and your list of AI uses to a working session. We will show where each sits on the map, where coverage has gaps and how Opencontroller keeps the agents accountable.
Frequently asked questions
What is SR 26-2?
SR 26-2 is the revised model risk management guidance issued on April 17, 2026 by the Federal Reserve, alongside OCC Bulletin 2026-13 and FDIC FIL-15-2026. It replaces SR 11-7 with a risk-based, materiality-sensitive approach to validating and monitoring models, and states that it is most relevant to larger banks.
Does SR 26-2 cover generative AI and agentic AI?
No. SR 26-2 places generative and agentic AI outside its scope, describing them as novel and rapidly evolving. It does not exempt them from oversight: a bank’s own risk management and governance practices should guide the controls for these systems.
What replaced SR 11-7?
SR 26-2 replaced SR 11-7, the Federal Reserve’s model risk guidance from 2011. Summaries of the new guidance say SR 11-7 is retired and should not be cited as a current standard. Check the Federal Reserve, OCC and FDIC texts for the exact wording.
What is the banking AI governance gap?
It is the space between what model risk guidance covers and the generative and agentic AI that banks now use. With no supervisory checklist, banks must define their own owners, inventory, permissions, monitoring and evidence, and prove them to examiners.
Does SR 26-2 apply to community banks?
SR 26-2 states that it is most relevant to larger banks, with $30 billion in assets mentioned as the reference point in summaries of the guidance. Smaller banks are expected to apply it proportionately. Confirm the threshold wording in the primary text and agree your approach with your examiner.
How should banks govern agentic AI if SR 26-2 excludes it?
Write a scope decision naming the governing frameworks, build an inventory with owners and risk tiers, define what each agent may do, require approval for high-impact actions, keep a per-use record of actions and approvals, and re-test on every model, prompt or vendor change.
What are examiners asking about generative AI?
No supervisor has published a checklist. Vendor commentary suggests examiners test AI against the bank’s existing third-party, operational risk and information security practices, and want to see what a system was allowed to do, what it did and where a person approved or stopped it. Treat this as inference, not examiner guidance.
Who should own AI governance at a bank?
There is no industry norm. One vendor suggests a cross-functional model: a business owner for the use case, model risk for tiering, compliance for obligations and approval, information security for access and permissions, technology for inventory and evidence, and a senior risk committee for framework choice and residual risk.
Why are traditional model metrics not enough for AI agents?
Accuracy and completeness describe outputs, but an agent plans, calls tools and acts. Banks also need to show who authorised it, what it was permitted to do, which identity acted and what record remains, and behaviour can change through a prompt edit or vendor update without a retraining event.
What is the NIST AI Risk Management Framework?
The NIST AI RMF 1.0, released in January 2023, is a voluntary framework for managing AI risk. Banks may choose it, or a similar framework such as ISO/IEC 42001, as the basis for governing AI that SR 26-2 does not cover, and document that choice.
How does Madison help with the AI governance gap?
Madison is Lyzr’s agentic GRC product for US banks and credit unions. It holds obligations, policies, procedures and controls as one connected model, holds vendors, models and agents as governed objects with owners and evidence, shows coverage gaps, and records signed decisions. Third-party and AI oversight is live now.
How does Opencontroller fit alongside Madison?
Opencontroller by Lyzr governs the agents themselves. It registers each agent with an immutable ID and a named owner, enforces approvals with separation of duties, keeps a signed audit trail, and provides a simulation engine with a regression gate. It runs in your own cloud account and complements GRC and model risk tools.
Book A Demo: Click Here
Join our Slack: Click Here
Link to our GitHub: Click Here
Got a use case in mind?
8 weeks from use case to agents running in production.
Platform, people and FDEs, all in. Bring your environment. We'll co-build and stay until it's live.
Talk to UsFree resource
101 AI Agents Use Cases
100+ production-ready AI agent use cases across Marketing, Sales, HR, Banking, Insurance, Operations and a lot more
Download now
