Revolut Went Dark. Never Bank on One Rail.

October 20, 2026 · 5 min read · Inglorious Editorial

Revolut spent Tuesday morning reassuring customers that their money was safe. It was. Many of them just could not reach it.

From early on 20 October 2026, users across the UK, Ireland and beyond reported failed card payments, blocked transfers and an app that would not let them sign in. Downdetector logged more than 1,500 reports shortly after 08:00 BST, according to the BBC. Revolut confirmed "a service disruption affecting multiple services", said customer funds and data were secure, and apologised. It has not named a cause.

At the time of writing, Revolut's own status page listed 30 services as partially unavailable in the UK and 31 in Portugal. The list is worth reading slowly, because it is not just the consumer app.

What Actually Broke

The consumer side made the headlines: card payments, transfers, ATM withdrawals, currency exchange, sign-up, sign-in and live support chat. That last one matters. When the app fails and the chat fails with it, customers have no channel left except social media, which is where most of them went.

The business side is what should worry this audience. The same page flagged Business transfers out, the Business API, the business web and mobile apps, Merchant API payments and Merchant Payment. That is outbound payouts, programmatic treasury and merchant acceptance, all degraded at once.

Over the same morning, Google Cloud opened an incident for its europe-west2 region with a start time of 07:08 BST. Google reported elevated errors and intermittent network failures across 31 products, including Compute Engine, Kubernetes Engine, Cloud SQL, Cloud Spanner, Pub/Sub, Cloud Storage and Persistent Disk. Its only suggested workaround, added more than three hours in, was to move affected workloads to another zone or region.

Be precise about what is confirmed. Reuters noted that Revolut uses Google Cloud, but said it was not immediately clear whether the two incidents were related. The Journal reported that the disruption was understood to stem from an outage at a third-party provider. The timing lines up. The root cause is Revolut's and Google's to publish.

One Failure, Thirty Services

Whatever the final explanation, this morning showed how a single failure propagates through a modern financial stack. A neobank is a dense mesh of services: ledger, card authorisation, KYC, FX, fraud scoring, support tooling. When the layer underneath all of them stumbles, they do not fail one by one. They fail together, which is how one status page goes from green to thirty degraded rows before most of Europe has finished breakfast.

Google's workaround tells you everything. Moving a workload to another region is routine if you built for it months ago and close to impossible if you attempt it mid-incident with your own support channels down. Resilience is a decision you make on a quiet Tuesday, not on this one.

Why High-Risk Operators Feel It First

For a retail customer, today meant a declined coffee and an irritated post. For an iGaming operator, a crypto platform or a payment processor running treasury through a single EMI or neobank, it meant something else.

Withdrawals stall. Players and traders judge you on payout speed. They do not care whose infrastructure failed. A delayed withdrawal reads as a solvency problem, and the complaints land on your brand, not your bank's.
Partner payments slip. Scheduled affiliate and supplier runs through a business API do not execute when the API is degraded.
Acceptance degrades. If you take payments through your provider's merchant rails, its bad morning is your lost revenue.
Nobody picks up. When your provider's support desk is part of the outage, your escalation path is a status page.

High-risk businesses are also the most likely to be concentrated in one provider, for a simple reason: they were turned away everywhere else. The one EMI that onboarded you becomes your only account, and the only account becomes a single point of failure that nobody chose on purpose.

The Regulators Already Named This Risk

None of this surprises supervisors. In July we covered HM Treasury designating Google Cloud EMEA Limited, alongside AWS, Microsoft and Oracle entities, as a Critical Third Party to the UK financial system from 13 July 2026. The Bank of England, PRA and FCA now oversee the services those providers supply to financial firms, and the regime expects them to keep regulators and dependent firms informed during major incidents.

In the EU, the European Supervisory Authorities put the same Google entity on the first list of 19 critical ICT third-party providers under DORA on 18 November 2025. Today is precisely the scenario both regimes were built for.

For EU financial entities caught up in an incident like this, the DORA clock is unforgiving. If the incident is classified as major, the initial notification is due within four hours of classification and no later than 24 hours after the firm became aware of it. An intermediate report follows within 72 hours, and a final report within a month of that. The question your supervisor will ask is not whether your provider failed. It is whether you knew which of your important services depended on it, and what you did in the first hour.

What To Do Before The Next One

Hold a second rail at a different institution. Not a second account at the same provider. A separate bank or EMI, ideally on different infrastructure, with live balances and tested payout routes.
Ask your providers where they run. Which cloud, which regions, and whether they fail over between them. If they cannot answer, that is your answer.
Pre-fund the backup. A dormant second account with no float pays nobody. Keep enough there to cover at least a day of withdrawals and payouts.
Build the switch, then test it. Payout routing that moves to the secondary rail with a configuration change, rehearsed on a quiet day.
Monitor independently. Vendor status pages lag reality. Track your own payment and payout success rates and alert on them.
Write the customer notice now. A short, honest message about delayed withdrawals, ready to publish in minutes, does more for retention than an apology drafted under pressure.
Document it. Map the dependency, set an impact tolerance and record the test. Under DORA or the UK operational resilience rules, an undocumented plan counts as no plan.

Revolut will recover, publish its explanation and move on. The operators who come out of today well are the ones whose customers barely noticed. If your answer to "what happens when our bank goes dark" was a shrug this morning, fix it before the next outage makes the decision for you.