On the morning of 20 October 2026, Revolut customers in several European countries found they could not pay by card, move money or withdraw cash. Around the same time, customers of Lloyds, Halifax, Bank of Scotland and HSBC reported problems with online services.
The cause was not a cyberattack or a faulty release. It was a power problem in a single Google Cloud zone in London.
Cloud outages are hardly news. What makes this one worth a CIO's attention is the story of the backup generators that were supposed to keep the lights on. That story raises a question every bank technology leader should be able to answer: how confident are we that our backups will work on a bad day, rather than on the day we test them?
The Instrument That Said All Was Well
Google's follow-up account, reported on 5 November, is unusually candid. One of the site's two primary power feeds, feeder B, had been opened for repairs after a routine quarterly generator load test on 14 October. While it was out, feeder A carried the entire critical load. Then the underground cable supplying feeder A broke.
The UPS systems did their job, but they only cover about five minutes. The generators should have started within that window. They did not. A voltage-sensing design flaw and a PLC misconfiguration meant the control logic believed a healthy utility source was still available, even though both feeds were dead. No start command was ever sent.
Look closely at what actually failed. The backup existed. It had just been tested. What broke was a combination: one component under maintenance, another component failing, and an instrument reporting that nothing was wrong.
Redundancy rarely fails because it is missing. It fails in combinations of conditions nobody tested.
This Is Not a London Problem
It is tempting to file this under "Google's problem". Yet in cloud architecture a zone is designed to be able to fail. The shared responsibility model assumes customers spread critical workloads across zones or regions.
Revolut said customers' money and data were safe. We could find no public technical explanation of why a single-zone event affected its services, so it would be unfair to draw conclusions about any particular bank's architecture. What can be said is simpler. For a customer whose card is declined at the till, the difference between "the provider is down" and "our architecture could not absorb it" does not exist.
This is where the issue becomes every bank's issue. Most organisations have their own version of that PLC. A passed DR test report. A 99.99 percent SLA. Provider certifications and third-party audit results. An architecture diagram labelled multi-zone. Each is an instrument telling the board that the system is healthy. The question rarely asked is when the instrument itself was last tested under bad conditions.
A Pattern, Not an Anomaly
Industry data suggests London was not a freak event. Uptime Institute's annual outage analysis, published in May 2026, found that power remains the leading cause of high-impact outages, dominated by failures of UPS systems, transfer switches and generators. Of the publicly reported outages it has tracked over nine years, about two-thirds involved third-party providers such as cloud, telecoms and colocation operators . The data draws on public reports and surveys, so it is best read as a consistent pattern rather than a precise measure of risk.
Banking supervisors are reaching a similar conclusion from a different direction. At the Basel Committee's international conference of banking supervisors in September 2026, reliance on a small number of critical providers such as cloud was described as raising concentration risk with both bank-level and systemic implications. Mapping system dependencies and maintaining complete ICT asset inventories were listed as persistent challenges. That is the crux. You cannot test what you cannot map.
In Indonesia, OJK is beginning to say this out loud: individual bank risks need to be considered for their wider systemic impact. If several banks depend on the same technology provider, a single disruption there can become a system-wide problem.
On accountability, the rules leave little room for doubt. POJK 11/POJK.03/2022 requires DRP testing of critical applications and infrastructure at least once a year with user involvement. It also makes the bank responsible for managing the risk of using IT service providers, including ensuring that providers have a tested and adequate DRP. The Basel Committee's third-party principles place ultimate responsibility with the board. Even in the UK, which since July 2026 has directly overseen four global cloud and technology providers, the designation does not diminish financial firms' responsibilities in any way. The UK regime does not apply in Indonesia, but the direction is instructive. Supervising the provider does not move accountability away from the bank.
The Exam That Is Too Easy to Pass
In practice, the annual DR test in many organisations follows a familiar script. The date is set weeks in advance. Every team is on standby. A clean switchover happens on a quiet weekend. Such a test proves the plan can be executed under ideal conditions. It does not prove that services will survive a Monday morning, in the middle of a maintenance window, while the vendor is busy with something else.
Consider a hypothetical illustration. A bank moves its mobile banking platform to a cloud region in Jakarta using a multi-zone design. But a third-party authentication service, the session database and the notification gateway still run in one zone, for licensing cost reasons. The annual DR test focuses on the core and the main application, not these supporting components. When that zone goes dark, the app stays up but no customer can log in. On paper the architecture is multi-zone. In reality there is a single point of failure nobody could see.
The Indonesian context adds another layer. The requirement to place data centres and disaster recovery centres in Indonesia may lead many banks' critical workloads to cluster in a small number of local facilities and cloud regions. This is editorial interpretation rather than an OJK finding, but it is reasonable enough to map.
For technology leaders the implications cut across several dimensions. In governance, board reporting should distinguish proven resilience from assumed resilience. In architecture, multi-zone designs need to be verified down to the smallest supporting component. In third-party management, contracts should secure access to evidence, not only service-level promises.
From Assumption to Evidence
Several practical steps can start without waiting for a major programme.
- Map critical services down to zone and facility level. Start with the five most critical business services, such as payments, mobile banking and ATM. Trace each component to the zone, region or building where it runs, including SaaS and the vendor's own dependencies. The Basel principles explicitly ask banks to use their third-party registers to map dependencies and interconnections.
- Test degraded conditions, not only clean failovers. Add one combined-failure scenario to the next DRP test, for example a zone failure while another component is under maintenance. Begin in non-production, then move to production with a limited scope.
- Change what the board sees. "DR test passed" is a metric that turns green too easily. More informative is the share of critical dependencies actually tested under failure in the past 12 months, and the time taken to restore a minimum viable service.
- Ask providers for evidence, not only promises. Build into contracts access to post-incident reports, rapid notification of location-specific incidents, and participation in joint testing. This is consistent with the obligation to ensure a provider's DRP is tested. Google itself has now committed to an automated alerting mechanism for incidents of this kind.
- Treat concentration as an industry issue. Where many banks depend on the same provider or region, joint resilience exercises with peers, industry associations and the regulator will mean far more than tests run in isolation.
Sequence matters. Mapping comes first, because testing without a map only tests what we already know.
A Question for Technology Leaders
Back to London. The generators were not broken. They were simply never told they were needed, because the instrument watching over them was certain all was well.
Many banks have similar instruments: dashboards in green, test reports marked passed, reassuring SLAs. These instruments are useful, but they are only as honest as the conditions under which they were tested.
Perhaps the most useful question a technology leader can ask is a simple one. If one of our cloud zones went dark tomorrow morning, which services would stop, and how do we know? If the answer comes from a document rather than a test, it is still an assumption.