At 06:08 UTC on Tuesday 20 October, a power event took down one of the three availability zones in Google Cloud's London region, europe-west2. Before long, Revolut's status page flagged 28 services as partially unavailable, from sign-ins and card payments to transfers, currency exchange and stock trading, and its 3.4 million Irish customers were caught up too, losing card payments, transfers, cash withdrawals and account sign-in. One zone in one region lost power, and the transaction processing behind a fintech with more than 60 million customers stalled for hours. The question worth answering is why a failure the cloud is designed to absorb still reaches a bank's customers, and what a bank has to build so the next one doesn't.
Picture one of those Irish customers tapping a Revolut card for coffee in Dublin at 7.15 that morning, minutes after the zone went dark. That tap is the simplest thing a bank does, and it's the thread this piece follows.
What a bank rents when it rents the cloud
For a bank, cloud means running its software on computers it doesn't own. A provider such as Google, Amazon or Microsoft builds the data centres, keeps the power and cooling on, and rents out computing, storage, databases and networking by the hour. Those data centres are grouped. A region is a cluster in one metropolitan area; europe-west2 is London. Inside each region sit availability zones, usually three, each made up of one or more data centres with independent power, cooling and network, spaced so a fault in one shouldn't spread while staying near enough to copy data between them in milliseconds.
The appeal is capacity a bank never has to build. A Google case study describes Revolut building its core infrastructure on Google Compute Engine, and Revolut has since signed a multi-year, multi-million dollar partnership to run its growing global systems on Google Cloud. It operates in more than 35 markets and handles over half a billion transactions a month, a volume that swings with every payday and holiday. Renting lets a bank add machines for the spike and hand them back afterwards. The market has consolidated around three suppliers: Synergy Research Group put Amazon at 28%, Microsoft at 20% and Google at 15% of a USD 143 billion quarter of cloud infrastructure spending in Q2 2026.
Now follow the tap. The terminal sends an authorisation request through the merchant's acquirer and the card scheme to Revolut, whose systems have a few seconds to check the card, score the transaction for fraud, confirm the balance on the ledger and send back an approval. On cloud, each of those steps runs on rented machines in specific zones. Revolut later attributed Tuesday's disruption to the Google Cloud outage and said customer money and data stayed safe throughout.
Zones exist so this morning doesn't happen
Three zones exist so a bank can lose one and keep serving. Spread the authorisation service, the fraud model and the ledger across all three, and a power fault in zone b leaves zones a and c to carry the load. That's the architecture the providers sell, and it's why a single-zone failure should be close to invisible to a customer.
It wasn't. Google's status page said its services were unavailable in europe-west2-b, while some services across the wider region saw elevated errors and intermittent network issues. Disruption was still being reported well into the afternoon. Lloyds, Halifax and HSBC customers also reported online banking problems.
London has seen this before. In December 2020, a configuration change left around 60% of virtual machines in europe-west2-a unreachable from outside the zone. Google has said it will publish an analysis once its internal investigation concludes, and Revolut hasn't said which of its systems sat in zone b. The shape is already visible, though: a fault the region was designed to contain reached customers anyway.
Why one dark zone can stop a card payment
The Dublin tap succeeds only if every system in its path answers in time. Authorisation, fraud scoring, the ledger, the scheme connection and, for the app, the login service all have to respond before the scheme times out. The availability of the whole journey is set by its weakest link.
In many banks that path is a chain of separately bought and separately deployed components: a card processor from one supplier, a fraud engine from another, a core ledger from a third, a login provider from a fourth. Each makes its own decisions about zones, replication and failover. One of them running in a single zone is enough. If the ledger is copied across three zones and the fraud service lives in one, the tap fails the moment that zone goes dark, and the customer sees a declined card however well the ledger was built.
That's the fragmentation cost, and it shows up in the record. Between January 2023 and February 2025, the nine largest UK banks and building societies logged at least 158 IT failures adding up to more than 803 hours of unplanned outages, according to the Treasury Committee, and banks named third-party supplier problems among the most common causes.
Hidden dependencies make it harder. Exactly a year before Google's outage, on 20 October 2025, a fault in Amazon Web Services' Northern Virginia region temporarily took down services including Coinbase, Robinhood, Venmo and Lloyds Bank. The incident showed that many AWS services billed as global still relied on control APIs in that one region. A bank can deploy carefully across zones and still discover, on the bad morning, that something in the chain was pinned to one place.
Oversight of the provider leaves the bank holding the outage
Regulators now supervise the providers directly. The Bank of England, the PRA and the FCA began overseeing Google Cloud EMEA and three other cloud and technology providers as critical third parties on 13 July 2026, 99 days before this outage. In the EU, the European Supervisory Authorities designated 19 critical ICT third-party providers under the Digital Operational Resilience Act (DORA) on 18 November 2025, Amazon Web Services, Google Cloud and Microsoft among them. RTÉ reported that Tuesday's outage renewed attention on UK and EU regulators' concerns about the financial sector's reliance on a small number of technology providers.
Neither regime moves the obligation off the bank. Under DORA, financial entities remain fully responsible for their operational resilience and third-party risk, including where the provider is directly overseen, and the Bank of England has said designation under the UK regime is different from authorisation. Where a bank places its systems, and whether its transaction path survives losing a building, remains the bank's decision and the bank's exposure.
What transaction processing looks like when a zone goes dark
For the Dublin tap to clear while zone b is dark, three things have to hold.
The authorisation path has to run as one deployment across every zone in the region, live in all of them at once. A unified payment switch that handles authorisation, fraud checks and multi-channel routing in a single layer gives the bank one deployment to replicate across zones and one failover to rehearse.
There has to be one ledger of record, replicated across zones, so the balance zone c checks is the balance zone b last wrote. After a failover the expensive work is reconciliation, matching what the scheme approved, what the ledger posted and what the customer saw. One ledger turns that from a cross-system investigation into a check.
And routing has to detect a failing path and move traffic before the scheme times out, with stand-in processing as the final fallback. When an issuer's systems are unreachable, Mastercard's processing service can authorise transactions on the issuer's behalf using offline balances the issuer has supplied. That only works if those balances are current, which is far easier when card issuing and the ledger share one platform.
Get those right and the Dublin customer pays for coffee from zone c and never learns there was a zone b.
Google's root-cause report will most likely be about power. The questions that decide the next outage belong to each bank's own team:
- If one zone in your primary region lost power at 7am tomorrow, which step of a card authorisation would fail first?
- How many separately deployed systems does a single tap touch, and when did each last pass a live zone-failure test?
- If your primary region went down entirely, where would your transaction processing run, and has that ever been tested?
Whether a bank stays up on the next bad morning is decided years before the power fails.
