An AI model kill switch protocol for a bank is a documented, tested procedure that names four things: the conditions that trigger a model suspension, the specific role authorized to pull it, the mechanism used to suspend or roll back the model independent of its own interface, and how fast that revocation actually happens once invoked. No federal guidance uses the phrase “kill switch,” and SR 26-2 does not mandate one by name. What it does carry forward from SR 11-7 is an ongoing monitoring and model retirement expectation that a kill switch protocol is the practical way to satisfy, and a 2026 industry survey found most banks have not built or tested one.
This guide is for the Chief Risk Officer, the head of model risk, and the CISO at a bank or captive finance arm who already has a model inventory and a validation cadence, but has never asked a sharper question: if a model starts producing harmful outputs at 2 a.m., who can turn it off, how, and how fast. It covers the four-part framework for building a kill switch protocol, the failure reporting process most programs skip, and where both fit inside an SR 26-2 program you may already have mostly built. It is scoped to bank model risk programs; a broker-dealer governing AI agents under FINRA’s 2026 guidance faces a related but distinct regime, covered separately in our FINRA AI agent governance for broker-dealers guide.
Want to put this into practice? Use our AI incident scenario builder.
Why kill switches became an exam-adjacent control in 2026
SR 26-2, issued by the Federal Reserve on April 17, 2026 and mirrored in OCC Bulletin 2026-13 and a parallel FDIC statement, replaced SR 11-7 and is principles-based rather than prescriptive. It does not contain a line item requiring a tested kill switch. What it does continue, unchanged in substance from SR 11-7, is the expectation that a model risk program includes ongoing monitoring sufficient to catch performance drift and a model retirement process for models that need to come out of production. A kill switch protocol is what turns that principle into something an institution can actually execute under time pressure, rather than something it merely has a policy sentence about.
The reason this control is getting exam-adjacent attention now is less about new guidance and more about what examiners find when they ask about it directly. Coverage of a 2026 survey of U.S. bank risk and compliance leaders found that kill-switch protocols and regulatory reporting of AI model failures were the two areas respondents most often named as where their institution was least prepared. That lines up with what we see in practice: banks that can produce a validation schedule and an inventory on request frequently cannot produce a tested record of how fast they can disable a model that is actively causing harm.
What “kill switch” means across your different model types
A bank’s AI footprint is not one kind of system, and a single kill switch design does not fit all of it. The mechanism differs by what you are trying to stop.
| Model type | What “kill switch” means in practice | Who typically needs it tested |
|---|---|---|
| Traditional statistical models in SR 26-2 scope (credit scorecards, AML transaction monitoring, pricing engines) | Rollback to the last validated model version, or a manual fallback process that replaces the model’s decision entirely | Model risk, with IT operations executing the rollback |
| Generative and agentic AI (outside SR 26-2’s named scope, but inside the governance track SR 26-2 pushes to other risk-management practices) | Revocation of the system’s credentials, tool access, or customer-facing deployment, independent of the system’s own administrative interface | Information security and the AI governance owner together |
| Vendor-embedded models (a scoring engine inside a decisioning platform, a fraud model inside a payments processor) | A contractual suspension right plus a technical fallback, since the bank rarely controls the vendor’s infrastructure directly | Third-party risk and model risk jointly, with the contract as the actual mechanism |
The traditional-model and generative-AI rows get tested separately for a reason: a rollback to a prior model version works when the model itself is the problem, but it does nothing for an agent that retained inappropriate tool access or a chatbot that is actively mishandling a live customer conversation. Both need their own tested path, not one shared assumption that “we can just turn it off.”
A four-part framework for the kill switch protocol itself
Most of the programs we review that claim to have a kill switch have a sentence in a policy document saying a human can disable the system. That is a design intention, not a control. A control has four named parts, and an examiner, or a real incident, will test all four.
- Trigger definition. Document the specific conditions that activate the protocol for each model or model category: a performance drift threshold crossed in ongoing monitoring, a fair lending or disparate-impact signal, a confirmed consumer-harm report, a vendor-notified model change that was not pre-approved, or a security finding showing the model or its access has been compromised. Vague triggers (“the model seems off”) produce slow, contested decisions in the moment that matters most.
- Authority and chain of command. Name the specific role authorized to invoke the protocol for each model tier, not a committee that has to convene first. A high-materiality model needs a primary and a backup authorized individual, because the person who built the escalation path is not always the person awake when the trigger fires.
- Mechanism, independent of the model’s own interface. The actual technical or procedural action: a version rollback, a credential or API-key revocation, a feature flag that routes traffic to a manual process, or a vendor-contract suspension clause invoked directly. The mechanism has to work even if the system generating the harmful output is unresponsive or compromised, which is why a kill switch that only exists inside the model’s own admin console is not a kill switch.
- Test and evidence cadence. A dated record of the last test, who ran it, the actual time-to-revocation against a documented target, and what the test found. A protocol tested once at launch and never again is not meaningfully different from one never tested, because the model, the vendor relationship, and the surrounding systems have likely changed since.
Failure reporting: the protocol most programs forget sits next to this one
Pulling the kill switch stops the immediate harm. It does not, by itself, satisfy the board reporting and documentation expectations that sit alongside ongoing monitoring in both SR 26-2 and the NIST AI RMF’s MANAGE function. A failure reporting protocol is the companion process that turns a stopped incident into governance evidence, capturing six things for every invocation, whether a false alarm or a confirmed failure:
- What happened, in plain language a board member without a technical background can follow
- The specific trigger that activated the protocol, and whether it was the trigger that should have fired or one caught later than it should have been
- Time to detection and time to containment, measured against the targets set in the kill switch protocol itself
- A consumer impact assessment, including whether any customer received an incorrect decision, price, or communication before containment
- Root cause, to the depth actually known at the time of the report, with a commitment to update it once a full review completes
- Whether the finding was escalated to the model risk committee, the board, or, where fair lending or UDAP exposure is present, legal and compliance
A report that documents the first item and skips the rest reads as an incident summary, not governance evidence. The two, kill switch and failure reporting, function as one protocol with two halves: stop it, then account for it.
Where this fits inside a program built around the SR 26-2 checklist
If your model risk program is already organized around our SR 26-2 compliance checklist, the kill switch and failure reporting protocol is not a ninth item bolted on top. It is the operational detail behind three items you likely already have at a policy level: the validation cadence (item 4), since ongoing monitoring generates the trigger; vendor and third-party model controls (item 5), since a vendor-embedded model’s kill switch runs through the contract rather than your own infrastructure; and board reporting (item 8), since the failure reporting record is what that board line actually carries. A program that scores well on the checklist’s eight items but has never tested a kill switch has a gap at exactly the level examiners probe hardest: not whether the policy exists, but whether it works under pressure.
A tabletop self-check before an examiner or an incident runs one for you
Run this as an actual exercise, not a reading of the policy document, before you assume the protocol would hold up:
- [ ] Pick one high-materiality model and one generative or agentic AI system already in production
- [ ] Have the named authorized role actually invoke the suspension mechanism, not describe how they would
- [ ] Time the gap between invocation and the model or system being fully inaccessible to new requests
- [ ] Confirm the mechanism worked independent of the system’s own administrative console
- [ ] Draft the failure report for the exercise using the six elements above, as if the test had been a real incident
- [ ] Route that draft report through the actual escalation path to confirm it reaches the model risk committee without a manual workaround
A bank that can check all six honestly has a tested control. A bank that stops at the first item has a plan, which is a meaningfully different thing when an examiner or an actual model failure asks for the evidence.
Questions buyers ask
Does SR 26-2 require a kill switch by name?
No. SR 26-2 does not use the term kill switch and sets no prescriptive requirement for one. It continues SR 11-7’s ongoing monitoring and model retirement expectations, and a tested kill switch protocol is the practical mechanism most institutions use to satisfy those expectations when a model needs to come out of production faster than a routine retirement cycle allows.
Is a kill switch only relevant to generative and agentic AI, or does it apply to traditional models too?
Both, with different mechanisms. A traditional statistical model’s kill switch is typically a rollback to the last validated version or a fallback to a manual process. A generative or agentic AI system’s kill switch is typically credential or tool-access revocation, since the risk is often the system’s autonomy or data access rather than a single decision output. A program that only has one of the two has a gap in whichever category it skipped.
How is this different from the kill switch expectation FINRA described for broker-dealer AI agents?
The control concept is similar, a tested, independent way to disable an autonomous system, but the regulatory regime and the buyer are different. FINRA’s 2026 guidance addresses AI agents at broker-dealers under existing supervisory rules like Rule 3110, as detailed in our FINRA AI agent governance guide. This guide addresses bank model risk programs operating under SR 26-2, where the kill switch sits inside ongoing monitoring and model retirement rather than broker-dealer supervisory procedures. An institution that operates both a bank and a broker-dealer affiliate needs both protocols, built separately for their respective regimes.
How often should the kill switch actually be tested?
At minimum, annually for every high-materiality model and generative or agentic AI system, and immediately after any material change to the model, its access scope, or the vendor relationship behind it. A kill switch tested once at launch and never revisited is not evidence of a working control three model updates later.
Can DSE certify that our kill switch and failure reporting protocol satisfies SR 26-2?
No. DSE prepares banks for audit and examination by building the trigger definitions, authority mapping, tested mechanism, and failure reporting structure this protocol needs, and the result is audit-ready and supervisory-framework-aligned. DSE does not certify compliance or guarantee any examination outcome; that determination rests with your examiners and your own model risk function.
The Bottom Line
A kill switch protocol is not a new SR 26-2 requirement, it is the tested, four-part operational control, trigger, authority, mechanism, and evidence, that turns SR 26-2’s ongoing monitoring and model retirement principles into something that actually works at 2 a.m. The failure reporting process that sits next to it is what carries that incident into the board reporting line examiners already expect to see. Most banks have neither tested, which is exactly what a 2026 survey of risk and compliance leaders found when it asked where institutions felt least prepared.
Building and testing the kill switch and failure reporting protocol across your traditional models, generative and agentic AI, and vendor-embedded systems is exactly the work our model risk management lite engagement runs for banks and captive finance arms sizing an SR 26-2 program to their actual institution. Start with the AI governance checklist to see where your current monitoring and escalation evidence stands, or review finserv compliance for the broader financial-services compliance picture.
Key facts
- A 2026 survey of U.S. bank risk and compliance leaders found that the two control areas respondents most often named as least prepared were AI model kill-switch protocols and regulatory reporting of AI model failures (Wolters Kluwer survey, reported by American Banker, 2026).
- SR 26-2 and OCC Bulletin 2026-13 do not use the term kill switch, but both carry forward SR 11-7's ongoing monitoring and model retirement expectations, which require a bank to be able to suspend or roll back a model showing material performance drift (DSE, 2026).