The UK payments industry has long depended on “always-on” cloud infrastructure operated by tech giants such as Amazon Web Services (AWS) and Microsoft Azure. When both suffered major outages this October, they exposed a core vulnerability: the fragility of digital systems built on the assumption that hyperscale clouds never fail.
In this article, Noda's Executive Advisor Alex Batlin explores what those disruptions taught us about operational dependency, systemic risk in payments, and how forward-looking businesses can rethink resilience in a cloud-centric world.
The wake-up call of autumn 2025
On 20 October 2025, AWS experienced a large-scale outage, triggered by a DNS-related issue in its US-EAST-1 region. Just over a week later, on 29 October 2025, Microsoft Azure suffered a major outage–root cause traced to a misconfiguration in its Azure Front Door (AFD) global routing infrastructure.
Although each outage lasted only a few hours, the impact was felt worldwide across a huge number of services. The outages affected not only common global messengers or social media like Snapchat, Slack or Zoom but also thousands of local UK businesses, including those in retail, public sector and financial services industries. Among the services disrupted by the AWS outage were Lloyds Bank, Halifax, Bank of Scotland and Coinbase. Thousands of customers of UK banks reported experiencing problems with card payments or accessing their bank accounts.
For many CTOs, the outages highlighted the hidden financial exposure behind cloud dependency. Every minute of downtime meant lost transactions, abandoned checkouts, and eroded consumer trust – losses that ripple far beyond IT teams. The outages translated into millions in missed revenue opportunities across the UK payments landscape. The lesson here is clear: resilience should be treated as a business goal, not just a technical one as it directly affects profitability and customer confidence.
Why the UK payments sector was so exposed
High Concentration in a Few Providers
The payments industry in the UK is heavily reliant on the major cloud providers. While granular industry-specific data is still emerging for 2025, analysts highlight that the UK public sector alone had awarded AWS £1.7 billion in contracts since 2016, showing just how deeply embedded the provider is.
The wider ecosystem shows that when a major hyperscaler fails, critical services including banking apps, checkouts and routing systems become vulnerable. This concentration risk extends beyond direct cloud usage – many third-party services that payment providers depend on themselves run on these same cloud platforms, creating hidden dependencies.
Regulatory Observations
Regulators such as the Financial Conduct Authority (FCA) and the Bank of England (BoE) have previously raised concerns about “concentration risk” in cloud infrastructure: too many firms relying on a small number of large cloud providers poses a systemic risk. The recent AWS and Azure outages crystallise this concern.
Lessons from blockchain: A resilience model worth studying
While the payments industry grappled with these outages, there's an instructive lesson from blockchain infrastructure. A few years ago, Ethereum faced a critical bug in one of its client implementations. The network survived because it runs on multiple independent codebases – Geth, Nethermind, Besu, Erigon and others. When the compromised client failed, operators simply switched to alternative implementations. No single codebase failure could take down the entire system. This demonstrates a principle the payments industry should take seriously: true resilience requires not just geographic redundancy, but genuine technological diversity at the infrastructure level.
How payments firms can apply these lessons
Short-term strategies
The immediate opportunity for payment service providers is to design systems that avoid vendor lock-in. This is more achievable now than ever before but it requires deliberate architectural choices from the start.
- Containerisation with Kubernetes – Building on platforms like Kubernetes allows workloads to run across different cloud providers.
- Cloud-agnostic APIs – Use tools that work across providers rather than building directly on AWS Lambda or Azure Functions. This allows you to deploy the same code across multiple platforms.
- Multi-cloud by design, not retrofit – Adding multi-cloud capability after you've built around one provider is expensive and impractical. Design for resilience during the initial architecture phase or planned technology refresh cycles.
- Active-active deployments – Run across different providers simultaneously rather than primary-backup configurations. This ensures you're always testing your failover capabilities in production.
It is important to note that cloud-agnostic architectures are much more expensive to build and operate than single-vendor solutions. But the cost of downtime during critical payment periods often dwarfs this investment.
Long-term: Rethinking network dependencies
Even if your own infrastructure is resilient, the payment networks themselves – SWIFT, Mastercard, Visa – remain potential single points of failure. This is where blockchain infrastructure and stablecoins become relevant, not as a technological preference, but as a resilience consideration.
Public blockchain networks like Ethereum operate through thousands of independent validators globally with no single operator. Stablecoins on these networks provide payment rails that operate independently of traditional card networks and clearing houses, settling 24/7/365.
Of course, bank transfers and card payments remain dominant and will continue to be for a long time. But as firms undertake multi-year technology refresh cycles, it is increasingly pragmatic to monitor how regulated stablecoin rails evolve – particularly as frameworks like the EU’s MiCA and the UK’s stablecoin regulations bring greater clarity.
A pragmatic path forward
The October 2025 outages won't be the last – so what should payment firms take away? The answer is a shift in mindset: you don't design for "no failure", you design for "continuity when failure happens". Firms building technology roadmaps around this principle, rather than hoping for perfect uptime, will be the ones maintaining service when others cannot.