With few banks in a position to answer the question of who is authorized to stop a faulty AI system, even a kill switch may not be useful, write Elaine F. Duffus and Aoife May of Wolters Kluwer Financial & Corporate Compliance. Regulators are making one thing clear: Someone must be accountable by name when an AI capability goes wrong.
Many financial institutions have put AI into processes like lending, fraud and collections ahead of the appropriate governance to oversee it. And the control that protects customers goes beyond technology. It depends on a named person with authority to act, vendor contracts that grant it and a clear way to answer regulators.
Also, many banks cannot produce a current, risk-tiered inventory of where AI runs across the business, a serious deficiency for an industry that is looking to increase adoption. A bank that knows which laws govern its business should also know where its automated decisions are being made. That shortfall shows up most sharply when something breaks. Once an AI system is in the wrong, few banks can say who is authorized to stop it, or who informs and answers to the regulator. Industry attention remains on more sophisticated failures like model drift and autonomous agents, while this simple accountability problem is far less scrutinized in the functions where risk runs highest.
An AI kill switch needs a named owner
A kill switch — the final option in stopping a technology that has gone too far — only works when a clear owner can take a production model offline, when clear conditions trigger that decision and when someone is responsible for explaining the failure to the regulator afterward. Few banks have settled all three for their highest-risk systems.
Just as important, a kill switch requires a continuity plan. If management is unwilling to disable a failing AI system because critical business processes would stop with it, then the kill switch exists only on paper. Institutions should identify in advance how affected activities will continue if a model is taken offline, whether through manual processing, fallback rules, reduced-function operations or alternative systems. The question is not simply who can stop the model but whether the institution can continue serving customers, meeting regulatory obligations and controlling risk once that decision is made. A kill switch without a tested fallback plan is an operational vulnerability rather than a genuine safety control.
Regulators have made clear that someone must be accountable by name when an AI capability goes wrong. Accountability spread across a committee or a process, with no individual able to act, tends to stall when speed matters most. Earlier tools did not work this way because a developing problem could be spotted and corrected before it spread across workflows. AI removes that margin, since a model can potentially repeat the same fault across thousands of decisions before anyone notices the pattern. That authority must exist before an incident, not be assembled in the middle of one. In a recent Wolters Kluwer survey of 230 US banking professionals, regulatory reporting for AI failures and model kill switch protocols were the two areas respondents felt least prepared, with about 72% naming one or the other.
10 Questions Every Organization Should Ask a Potential AI Vendor
Adopting AI without understanding how it was built and how it handles data can expose an organization to risks that surface only once something goes wrong
Read moreDetailsNo rulebook is expected soon
The guidance banks would normally lean on leaves the relevant AI out. On April 17, the Federal Reserve, Office of the Comptroller of the Currency and FDIC issued revised model risk management guidance that supersedes a 2011 standard but excludes generative and agentic AI from its scope, on the grounds that the technology is new and fast-moving. The guidance is principles-based and nonbinding, with only a future request for information promised on how banks use AI. A binding AI rule is not expected soon.
Excluding these systems from the guidance does not mean they go ungoverned. Regulators expect each bank to rely on its own risk and governance practices for anything the guidance does not cover, which puts the responsibility back on the institution. Supervision has turned risk-based and tailored, closer to the European approach. Banks should consider using the references that already exist. The NIST AI risk management framework offers a workable structure, and the Treasury Department worked with the Cyber Risk Institute on a financial-services AI framework that appears little-known despite being sector-specific and free.
When the AI belongs to a vendor
Often, the ability to act lies outside the bank. Banks generally obtain their AI from third parties, which means the power to spot a problem, take the system offline and report it often belongs to the vendor rather than the bank, even though it’s the bank that must answer to regulators. And a named owner inside the bank holds no real authority if the contract with the third-party never granted it. Legacy software agreements typically do not contain that provision and should be reviewed. Important terms to consider include prompt notice of any incident, visibility into the model and the data behind it, a duty to flag complaints that point to AI trouble and the right to be told when the vendor changes the model. A common gap is where oversight checks a vendor’s outputs but never how the vendor reaches them, which may be the part that fails first.
Collection activities show what is at stake when this authority is missing. The same recent Wolters Kluwer survey ranked collections and recovery as the function where AI poses the greatest risk of customer harm, ahead of credit and underwriting by roughly 10 points, because the customer there has the least disclosure and protection and is often in distress when the contact with AI happens. A small drift in an automated system can begin treating similar customers differently long before anyone notices. When a third party makes AI-driven contact with those customers and has no duty to flag rising complaints, if the bank has no one watching the system and no way to stop the harm, it falls on the customer least able to absorb it.
Where to start
As part of their governance process, every bank should identify who has the authority to stop a failing model, what triggers that decision and who reports it to the regulator. The first steps are concrete and within reach.
- List and risk-tier every AI use case.
- Give each identified as high-risk a named owner.
- Define the trigger(s) and the stop-and-report path before anything goes wrong, then test it.
- Review vendor contracts to ensure they contain the important terms relevant to your bank.
The work begins where the problem began, with a clear understanding of where AI operates, what it influences and who is accountable for it. Banks that act now can govern AI on their own terms, establishing the controls, oversight and resilience needed to protect customers, maintain trust and realize the benefits AI can deliver. The institutions that succeed will not be those that deploy AI the fastest but those that can demonstrate they remain firmly in control when it matters most.
Elaine F. Duffus
Aoife May
