As reported by BleepingComputer, Revolut is grappling with a widespread service disruption affecting 28 core services — including sign-ins, card payments, transfers, and currency exchange — reportedly linked to a power event at Google Cloud's europe-west2 (London) data center. While Revolut has confirmed customer funds and data remain secure, the outage underscores a structural risk that many digital-first financial institutions have yet to fully address: critical concentration on a single cloud region.

Cloud Security Alert: While Revolut has confirmed customer funds and data remain secure, the outage underscores a structural risk that many digital-first financial institutions have yet to fully address: critical concentration on a single cloud region.

Why This Matters

Revolut serves over 80 million customers across 160+ countries and 800,000 business customers. When a fintech of this scale experiences a multi-hour disruption to its core banking services, the impact cascades far beyond inconvenience. Businesses lose access to payment rails at critical moments, individual customers may be unable to complete transactions or access funds while traveling, and trust erodes — particularly for a company that has already disclosed multiple data breaches in recent years.

The root cause appears to be infrastructure-level, not malicious. But that distinction will be cold comfort to customers who couldn't make card payments this morning. The lesson isn't about threat actors — it's about architectural resilience.

When your entire banking platform depends on one cloud region, a single power event becomes a global outage.

The Concentration Risk Problem

This incident illustrates a well-known but under-addressed problem in cloud architecture: concentration risk. Many organizations — especially fast-growing fintechs that prioritized speed to market — built their infrastructure on a single hyperscaler, often within a single region. The calculus was reasonable: cloud providers offer strong SLAs, and multi-region or multi-cloud architectures add cost and complexity.

But the math breaks down when the underlying assumption — that a single region will remain available — fails. Google Cloud's europe-west2 region experienced a power event, and Revolut's services went dark globally. The failure wasn't in Revolut's code; it was in their deployment topology.

Key Risk Factors Amplifying Impact

The Concentration Risk Problem
Single-region dependency: 28 services reportedly tied to europe-west2 with no apparent automated failover to another region
Monolithic service coupling: Core banking functions (auth, payments, transfers) all failed simultaneously, suggesting tightly coupled architecture rather than isolated, independently resilient services
Customer communication lag: Despite 80M+ users, initial visibility into the scope came largely from Downdetector reports rather than proactive notification
Brand trust erosion: Previous breaches in 2022 and 2026 compound the reputational damage of this operational failure

Regulatory Implications

For organizations operating in the EU, the Digital Operational Resilience Act (DORA) — which entered full application in 2025 — imposes specific requirements around ICT risk management, incident reporting, and testing of operational resilience. A multi-hour outage affecting core banking services across 160 countries would likely qualify as a major ICT-related incident requiring regulatory notification under DORA's framework. Financial entities that fail to demonstrate adequate resilience measures face scrutiny and potential enforcement.

Similarly, organizations subject to NIST Cybersecurity Framework 2.0 should view this through the lens of the Recover function — can your organization restore services within your defined tolerances?

Shield53 Recommendations

Immediate Actions

  • Map your dependencies: Identify every critical service tied to a single cloud provider and region. If you don't know where your failover gaps are, you can't close them.
  • Review your vendor's SLA and status pages: Don't wait for an incident. Subscribe to Google Cloud's status page (or your provider's equivalent) and set up automated alerting for your specific regions.
  • Test your disaster recovery: If you have multi-region failover configured, when was the last time you tested it under simulated failure conditions? Untested failover is assumed risk, not resilience.

Strategic Actions (30-90 Days)

  • Implement active-active multi-region deployment for your top-tier critical services. Active-passive is better than nothing, but failover introduces delay and risk of failure.
  • Decouple critical services: If authentication goes down, should card payments also fail? Designing for partial degradation — where some services remain available even when others fail — significantly improves customer experience during incidents.
  • Invest in customer communication infrastructure: During an outage, your status page and notification systems must survive even when your core services don't. Consider hosting these externally or on a different provider.
  • Conduct a DORA readiness assessment if you operate in the EU financial services ecosystem. Identify gaps between your current resilience posture and regulatory expectations before a regulator does it for you.
  • Model your blast radius: For every cloud dependency, calculate the business impact if that dependency fails. Use this to prioritize multi-region or multi-cloud investments where they matter most.

This outage was caused by infrastructure, not adversaries. But the next one might not be. Organizations that build resilience for operational failures are better positioned to withstand the intentional ones too. Single-region cloud dependency is a known risk — the question is whether your organization has chosen to accept it or address it.