AI Operational Resilience in Banking: DORA, Important Business Services, and Emergency Controls

An AI system failure during a payment processing window doesn't ask which regulator has jurisdiction before it happens. A bank running that system across multiple geographies, though, has to answer four different operational resilience frameworks' questions about the same failure — on different timelines, in different formats, to different regulators — and that reporting-clock mismatch is a bigger practical problem than any single framework's substantive requirements.

DORA's ICT scope was always broad enough to reach AI — the only real news is confirmation, not a new rule

DORA (the EU's Digital Operational Resilience Act, in force since January 17, 2025) governs ICT risk management, incident reporting, resilience testing, and third-party oversight for EU financial entities, and an AI system supporting a critical or important function has always fit that definition on its face. . Whatever the exact confirmation date turns out to be, a bank that waited for an explicit statement before applying DORA's incident-reporting and resilience-testing requirements to its AI systems was reading the scope too narrowly from the start — "ICT system" was never going to exclude the AI system sitting inside your payment or fraud-detection stack just because it's newer technology.

A named human who can actually pull the plug is the control examiners keep asking for

. Whether or not any single regulator has written this exact phrase into a rule, the underlying test is one every bank should be able to pass today: can you name the person with both the authority and the actual technical access to shut down this AI system, how long does it take in practice, and when did you last test it for real rather than assume it on paper. A bank that answers "we believe we could do that" instead of "we tested it on this date and it took this long" has an incomplete control regardless of which framework is asking.

India's requirements are distinct, not a smaller version of DORA

RBI's expectations require business continuity plans that explicitly address AI system failure scenarios, with emergency-halt mechanisms expected under the RBI's 2024 AI framework specifically for AI used in critical functions. Where a bank's AI supports UPI services, NPCI's own payment-system standards layer on top of RBI's general expectations, and hyperscaler concentration risk mitigation is its own named requirement, not folded into generic third-party risk management. This isn't DORA with different terminology — it's a separately constructed set of expectations that happens to cover similar ground, which means a bank can't just relabel its DORA compliance package and submit it to RBI.

Impact tolerances mean nothing until you've actually broken the AI system on purpose

Every framework here converges on the same real test: can the bank maintain its important business services — payment processing, credit decisioning, AML monitoring, customer service — within a defined impact tolerance when the AI system supporting that service actually fails or degrades. Theoretical impact tolerance statements that have never been tested against an actual AI failure (not a generic system outage, an AI-specific one — degraded model output, not just downtime) are not evidence of resilience; they're evidence of a document.

The real operational problem is four incident clocks running on the same incident

A single AI failure affecting EU, UK, and India operations simultaneously triggers DORA's incident-reporting timeline, the PRA/FCA framework's operational incident reporting, and RBI's own incident-reporting expectations — each with different thresholds for materiality, different formats, and different clocks starting from different trigger definitions. Banks that have built one incident-response runbook per regulator, rather than one incident-response process that branches into each regulator's specific reporting requirement at the right moment, are going to miss at least one deadline the first time a real cross-border AI incident happens — this is a process-design problem to solve before the incident, not during it.

What a bank should actually do

1. Treat every AI system supporting a critical or important function as in-scope for DORA's (or the equivalent domestic framework's) incident reporting and resilience testing — don't wait for explicit regulatory confirmation to apply ICT-risk scope that was always broad enough to cover it.
2. Name the specific human with both authority and technical access to halt each critical AI system, and actually test the shutdown — document the date and the time it took, not just the intention.
3. Build India-specific AI business continuity plans that address NPCI/UPI standards and hyperscaler concentration separately — don't assume a DORA-equivalent package satisfies RBI's distinct expectations.
4. Run resilience tests against actual AI degradation scenarios (bad outputs, not just downtime) for payment, credit, AML, and customer-service functions, and record the results against defined impact tolerances.
5. Build one cross-border AI incident response process with built-in branches for each regulator's reporting clock and format, rather than separate per-regulator runbooks that nobody has tested together.