Google Cloud outage disrupts Revolut and UK banking payments after London power failure
A major Google Cloud infrastructure outage on October 20, 2026 disrupted Revolut banking services, payment processing and Open Banking connections in the United Kingdom and parts of Europe after an electrical event in Google's London cloud region.
Google identified a power event affecting the europe-west2-b availability zone, within the europe-west2 region. The incident began at 06:08 UTC (07:08 in London; 08:08 in Italy). Multiple cloud products subsequently experienced service errors and network disruption, while financial institutions and payment providers reported failures involving authentication, account access and transaction authorization.
Revolut's Italian service dashboard listed 31 partially unavailable functions, including card payments, cash withdrawals and business services. Worldpay separately reported issuer-related transaction errors and subsequently identified Revolut; Open Banking provider Volume linked its payment failures to the Google Cloud incident. These observations do not demonstrate a network-wide failure of Visa or Mastercard.
Google later reported that the electrical event had been mitigated, while infrastructure recovery continued. Restoring electrical power is distinct from restoring payment services, which may require database recovery, reconnection of authorization systems and reconciliation of interrupted transactions.
··········
THE GOOGLE CLOUD FAILURE AND ITS IMPACT ON BANKING SERVICES.
A power incident in one London availability zone affected multiple cloud components and exposed dependencies within financial-service applications.
Google Cloud identified europe-west2-b as the zone affected by the electrical event, with disruptions reported across services operating in its London region. The service-health dashboard listed affected cloud products spanning computing, container orchestration, networking, databases and storage, including Google Compute Engine, Google Kubernetes Engine and managed data services.
An outage in a single availability zone does not necessarily disable an entire cloud region. However, application failures can propagate where database instances, authentication components, network routes or other dependencies remain concentrated in the affected zone. Even when frontend servers respond, the absence of a required backend service can prevent an account login or payment from completing.
The available operator notices document several distinct manifestations of the disruption. They must be interpreted at the level of the specific platform or integration that reported them.
........
Operator or service | Observed disruption | Scope and evidence |
--- | --- | --- |
Google Cloud | Elevated errors and intermittent network disruption | Power event in europe-west2-b; impacts within London region |
Revolut | Partially unavailable banking and payment functions | 31 functions listed on Italian status page, including cards and withdrawals |
Volume | Open Banking payment failures | Explicitly linked failures to Google Cloud; Lloyds Group and Revolut connections affected |
Lloyds, Halifax and Bank of Scotland | Problems with specific banking connections | Partial outages recorded by Volume, not a confirmed total bank-wide shutdown |
Tink Italy / Revolut | Authentication and payment-initiation problems | HTTP 500 responses at token endpoint in the monitored Open Banking integration |
Worldpay | Increased authorization errors | Third-party issuer incident, later associated with Revolut |
........
Revolut's status dashboard reported disruptions across consumer and business functions, including card payments, bank transfers, cash withdrawals, currency exchange and some merchant-facing services. The figure of 31 is a count of affected features on the Italian dashboard, not 31 separate incidents or a measure of the number of customers affected.
Volume's status history offers direct evidence of the cloud connection. At 08:15 UTC, the provider attributed ongoing payment failures to the Google Cloud outage. At 09:20 UTC, it reported that a fix had been deployed and that monitoring continued, while some banks, including Lloyds Group institutions and Revolut, were still experiencing problems. Its bank-connection statuses should not be generalized to every service operated by those banks.
Tink's Italian service-status page identified a major incident affecting its Revolut Open Banking integration. It cited HTTP 500 responses from an authentication-token endpoint, with account-information and payment-initiation flows affected. Tink's indication that 100% of users were affected applies to the monitored integration, not to all Revolut account holders.
Worldpay reported elevated transaction-processing errors associated with a third-party issuer and identified Revolut in a subsequent update. Its notice is evidence of an issuer-related authorization problem; it is not evidence that Worldpay's entire acquiring infrastructure, or the global card networks, had become unavailable.
··········
HOW A CLOUD FAILURE CAN INTERRUPT CARD PAYMENTS AND OPEN BANKING.
Cloud connectivity, issuer authorization and authentication services are separate operational layers, so payment failures can occur without a failure of the card network or a loss of customer funds.
In a typical card purchase, a merchant's payment provider forwards an authorization request through the acquiring institution and the relevant card network to the card issuer. The issuer evaluates the transaction against available funds, account status and security rules, and returns an approval or rejection within a limited processing window.
If the issuer's systems cannot respond or a required backend dependency is unavailable, a request can time out or fail even when the merchant's payment gateway and the card network remain operational. This distinction is consistent with Worldpay reporting problems associated with Revolut while its other platform functions were still operating.
Cash withdrawals can be affected through a similar dependency. The ATM can function normally, but a request involving a particular card issuer may not receive the authorization needed to dispense funds. A failed withdrawal therefore does not independently identify which component of the underlying network is responsible.
Open Banking relies on a different workflow. Authorized third-party providers use bank interfaces to obtain account information or initiate payments, subject to customer consent and authentication requirements under the applicable PSD2 framework. These integrations depend on identity services, token issuance, APIs and access to banking backends.
An HTTP 500 error at a token endpoint, as reported by Tink, indicates a server-side failure in the affected integration's authentication path. Without a valid access token, a third-party application may be unable to retrieve account data or initiate a payment, even where the customer's underlying account remains intact.
Interrupted requests introduce an additional risk during recovery. A client might lose the confirmation of a payment that was already accepted by the processing service. Repeating that request without reliable transaction identifiers or idempotency controls could create a duplicate instruction. Payment applications therefore need a clear method for distinguishing requests never accepted, transactions rejected and operations whose final result is uncertain.
Cloud redundancy is useful only when it covers the complete critical path. Replicating application servers across availability zones may not restore a transaction workflow if those servers still rely on a database, identity component or network dependency in the failed zone. Multi-region recovery requires compatible data replication, routing and transaction-consistency arrangements.
For financial services, recovery speed and transaction correctness must be evaluated together. A rapidly restarted application does not represent successful recovery if it produces inconsistent balances, repeated payment instructions or incomplete reconciliation.
··········
FINANCIAL EXPOSURE AND DORA OPERATIONAL RESILIENCE REQUIREMENTS.
The relevant business risk is the interruption of customer transactions and the concentration of critical technology dependencies, rather than an assumed loss of deposited funds.
Banks and card issuers can experience reduced transaction availability, increased support demand and complex reconciliation work when authorization or account services fail. Payment processors may face higher decline and timeout rates, while merchants can lose sales through abandoned checkouts or repeated unsuccessful purchase attempts.
The financial consequences depend on outage duration, affected transaction volumes, service-level agreements, contract terms and the eventual resolution of payments left in uncertain states. No independently verified aggregate loss estimate has been established for this incident, and a temporary application outage does not on its own demonstrate a compromise of customer balances or data.
In the European Union, the Digital Operational Resilience Act (DORA), Regulation (EU) 2022/2554, has applied since January 17, 2025. It establishes requirements for ICT risk management, incident handling and reporting, resilience testing and third-party technology dependencies for financial entities within its scope.
DORA is pertinent because shared cloud services can create correlated operational exposures across otherwise independent institutions. The regulation does not mean that an outage automatically constitutes a compliance violation: determining whether an entity breached a specific obligation requires evidence concerning its risk controls, incident classification, contractual arrangements and response.
........
Operational exposure | Resilience control | Question for the financial institution |
--- | --- | --- |
Failure of one cloud zone | Tested multi-zone failover | Can essential services function without that zone? |
Regional cloud disruption | Multi-region continuity planning | Can critical processing move to independent infrastructure? |
Shared authentication dependency | Redundant identity services | Can customer and API access recover without invalidating transactions? |
Indeterminate payment outcome | Idempotency and reconciliation | Can failed and accepted requests be distinguished reliably? |
Supplier concentration | ICT third-party mapping and contingency plans | Are common dependencies identified across critical services? |
Slow detection of failures | End-to-end transaction monitoring | Are payment failures detected before they accumulate? |
Prolonged service interruption | Defined recovery objectives and escalation | Are restoration and reporting obligations actionable and tested? |
........
These controls solve different problems. A multi-zone application deployment does not ensure resilience when its identity and database services remain single points of failure. Similarly, a secondary region provides little practical protection if it cannot access sufficiently current transaction data or cannot be activated within the institution's recovery objectives.
A sound assessment distinguishes recovery time objective (RTO), which concerns how quickly a service must resume, from recovery point objective (RPO), which concerns acceptable data loss or replication lag. Financial payment processing may require stricter transaction integrity than ordinary content-serving applications, regardless of the chosen infrastructure.
The operational information required after this incident includes observed transaction failure rates, affected customer functions, time to recovery, outstanding uncertain payments and the degree of dependence on the disrupted cloud environment.
··········
RESTORING PAYMENT OPERATIONS AFTER THE LONDON INCIDENT.
Mitigation of the initial power event does not establish that every dependent bank, issuer and payment integration has completed recovery.
Google Cloud stated during its October 20 updates that the electrical incident had been mitigated, while some affected cloud services still required restoration. Banking and payment-provider status notices continued to describe disruptions or recovery monitoring during the same period.
These reports are not contradictory. Cloud infrastructure can become available before applications have restored database connections, refreshed authentication services, processed queued requests and reconciled transactions whose status was unclear during the incident.
Customers encountering a failed or unconfirmed transfer should check its recorded status before resubmitting it, particularly where the first instruction may have reached the provider without returning a confirmation. The appropriate next step depends on the payment type and the institution's own recovery guidance.
The confirmed Google Cloud cause is an electrical event affecting London cloud infrastructure. The available operator evidence describes service-specific banking, authorization and Open Banking failures. It does not establish a cyberattack, a compromise of deposits or a simultaneous collapse of the global Visa and Mastercard networks.
A defensible declaration of full recovery requires stable underlying infrastructure, normal authorization success rates, functional authentication services and reconciliation of interrupted operations. For banks and payment processors, the operational test is whether their critical transaction paths can meet defined recovery and data-integrity requirements when an external cloud dependency becomes unavailable.
··········
FOLLOW US FOR MORE.
·····
DATA STUDIOS
·····
