Cloud computing can make an individual bank more resilient and innovative. But when thousands of institutions depend on the same small group of technology providers, operational resilience stops being only a firm-level question and becomes a financial-system question.
For years, banks treated cloud migration as a familiar outsourcing decision: compare price, security and service quality, negotiate a contract, and hold the bank accountable for what happens next. That framing is no longer sufficient. In July 2026, UK authorities designated Amazon Web Services EMEA SARL, Google Cloud EMEA Limited and Microsoft Ireland Operations Ltd as Critical Third Parties, alongside Oracle Corporation UK Limited. The reason was explicitly systemic: disruption at the same technology provider can affect many regulated firms and markets at the same time.
The concentration is visible in the data. The Bank of England and FCA 2024 AI survey found that the top three named cloud providers accounted for 73% of reported cloud-provider relationships among respondents. A third of AI use cases were already third-party implementations, up from 17% in 2022. In parallel, the UK Competition and Markets Authority concluded its cloud services market investigation in July 2025 and found Amazon and Microsoft to have positions of significant market power, with switching and multi-cloud constrained by technical and commercial barriers.
THE CORE ARGUMENTThe danger is not that Microsoft, Amazon or Google are inherently less resilient than a bank-run data centre. The danger is correlated dependency: a failure, cyber event, software defect, identity outage, region-wide disruption or contractual bottleneck at a shared provider can transmit across institutions that otherwise appear diversified.
Cloud solved one concentration problem and created another
Banks moved to hyperscale cloud for good reasons. Large providers can spread infrastructure across multiple availability zones, invest heavily in cyber defence, automate patching, provide elastic capacity and give smaller institutions access to technology that would be expensive to reproduce internally. The Bank of England has acknowledged that financial firms depend on external providers in order to capture the productivity benefits of advanced AI, including cloud computing and vendor-supplied models.
The paradox is that decentralisation within a provider can coexist with concentration across the market. A bank may distribute workloads across three data centres and several cloud regions yet still rely on one provider for identity, database services, networking, key management, observability and disaster recovery. Thousands of other firms can make the same choice. The system therefore becomes geographically distributed but commercially concentrated.
That distinction is why regulators increasingly discuss cloud as a source of common-mode risk. The Bank of England Financial Policy Committee has warned that concentration in AI-related services can magnify system-wide operational risk, while its July 2026 Financial Stability Report highlighted the financial sector's dependence on common third-party technology and the possibility that cyber weaknesses at shared suppliers or software components could have system-wide consequences.
The risk is deeper than a simple cloud outage
The most obvious scenario is an outage that makes a bank's application unavailable. But concentration risk reaches further. Cloud platforms increasingly provide the databases, identity systems, developer pipelines, cyber controls, analytics tools, AI services and data layers on which critical banking functions depend. A disruption can therefore affect not only customer-facing channels but also the tools that operations teams need to diagnose and recover from the disruption.
This can create a recovery trap. A bank may have backups, but restoring them can still require the same cloud identity service, the same orchestration tools or the same proprietary database technology that failed. In that case, backup data does not equal service portability. The practical question is not simply whether information exists somewhere else; it is whether the institution can recreate the full business service within its tolerance for disruption.
The ECB's final Guide on outsourcing cloud services reflects this broader view. Published in July 2025, it emphasises risk-based cloud outsourcing, DORA compliance and effective management of security, continuity and exit arrangements. The ECB has also said banks are relying on cloud services from a handful of providers and that this creates IT-security and cyber risks requiring explicit supervisory attention.
A resilience plan that fails unless the original provider is available is not an exit plan. It is a recovery plan inside the same dependency.
Multi-cloud sounds easier than it is
A common answer to concentration risk is multi-cloud: spread workloads across AWS, Microsoft Azure and Google Cloud so no single provider can become a point of failure. In principle, this can reduce dependency. In practice, genuine portability is expensive and technically difficult.
The CMA's cloud investigation found barriers that can make switching and multi-cloud harder, including data egress costs, interoperability constraints, committed-spend arrangements and software licensing practices. Its 2026 concurrency report said the completed investigation found Amazon and Microsoft to have significant market power and identified barriers that limit customer choice. These competition issues have an operational-resilience dimension: the harder it is to move workloads, the less credible an emergency exit becomes.
There is also an engineering trade-off. The fastest way to extract value from a hyperscaler is often to use its proprietary managed services deeply. Those services can improve performance, security and developer productivity, but they make the architecture harder to reproduce elsewhere. A bank that insists every critical system remain portable across three clouds may sacrifice functionality and add significant cost. A bank that optimises aggressively for one provider may gain efficiency while accumulating strategic lock-in.
The realistic objective is therefore not universal portability. It is selective portability: identify the services whose failure would create unacceptable customer or market impact, understand which dependencies are truly substitutable, and design tested alternatives where the value of resilience exceeds the cost.
AI is making the cloud concentration problem more consequential
The cloud debate is becoming an AI debate because modern AI systems often depend on the same providers for computing, foundation models, data tooling and developer infrastructure. The Bank of England/FCA AI survey found that critical third-party dependencies were the systemic AI risk expected to increase the most over the following three years. Firms also reported less complete understanding of externally supplied models than internally developed ones.
This creates stacked dependency. A bank may use a third-party model hosted on a cloud platform, connected to vendor data services and embedded through a software provider. The bank can therefore face concentration at several layers at once: cloud, model, data, identity and application. The immediate vendor named in the contract may not be the vendor whose outage ultimately stops the service.
In a February 2026 speech, ECB Banking Supervision warned that generative AI systems are often sourced from a small number of major providers, rely heavily on cloud infrastructure and create concerns around concentration risk, vendor lock-in, data confidentiality, operational resilience and exit strategies. The risk is not only technological. It is strategic dependency on a small ecosystem that controls both compute and increasingly the models running on it.
Regulation is shifting from outsourcing oversight to infrastructure oversight
The policy response is significant because regulators are no longer relying solely on banks to manage supplier risk contract by contract. In the European Union, the Digital Operational Resilience Act (DORA) created an oversight regime for critical ICT third-party providers. In November 2025, the European Supervisory Authorities published the first list of designated critical ICT third-party providers, using information supplied by financial firms about their ICT arrangements and assessing providers' systemic importance and substitutability.
The UK has now moved from framework to live supervision. The Bank of England, PRA and FCA said oversight of the first designated Critical Third Parties would begin in July 2026, covering AWS, Google Cloud, Microsoft and Oracle. The regime focuses on the resilience of the critical services these companies provide to the financial sector, while leaving regulated firms responsible for their own due diligence, contingency planning and operational resilience.
This is an important conceptual change. The traditional outsourcing model assumed the regulated bank was the primary control point. Critical-third-party regimes recognise that some technology suppliers have become infrastructure-like: their scale and common use mean risks cannot be fully managed through thousands of bilateral contracts. Regulators need a system-wide view of dependencies that no single bank can see.
The counterargument: hyperscalers may reduce risk more than they create it
There is a strong counterargument to the concentration narrative. Large cloud providers can invest more in security engineering, redundancy, specialist staff and continuous monitoring than most individual banks. They operate at global scale, learn from incidents across enormous customer bases and can often recover infrastructure faster than institutions running fragmented legacy estates.
Moving a bank from two ageing proprietary data centres to a resilient public-cloud architecture can reduce single-firm operational risk even if it increases dependence on a shared provider. Cloud concentration should therefore not be treated as evidence that banks should reverse migration or return critical systems wholesale to on-premises infrastructure. The relevant comparison is between realistic architectures, not between an idealised private cloud and an imperfect public one.
The best regulatory frameworks acknowledge this. The ECB's cloud guide is framed around proportionate risk management rather than prohibition, and the UK Critical Third Party regime is designed to oversee shared providers while preserving the innovation and scale benefits they bring. The aim is to make concentrated infrastructure more resilient, not to pretend concentration can be eliminated.
What banks should measure instead of counting cloud providers
A bank can claim to be multi-cloud and still be critically dependent on one identity system. It can use ten technology vendors while all ten run on the same hyperscaler. It can hold data in two clouds while only one environment contains the tooling needed to reconcile accounts after a disruption. Provider count is therefore a weak measure of resilience.
A more useful concentration map starts with important business services and works downward. For each service, the bank needs to identify which cloud regions, identity systems, databases, model providers, networks, software components and subcontractors are required to keep the service running. It should then ask where the same dependencies recur across otherwise separate systems. The FSB third-party risk management toolkit similarly emphasises mapping dependencies, managing concentration and improving coordination between financial authorities and service providers.
Exit testing matters more than exit documentation. A contract can contain portability clauses without proving that a critical service can be moved within a workable timeframe. Banks need evidence: recovery tests that assume a provider control plane is unavailable, restoration from independent backups, pre-arranged connectivity to alternative environments, and a clear understanding of which proprietary services would have to be replaced rather than simply copied.
The ECB's 2025 supervisory reporting also points to the same problem. Its annual report recorded increasing reliance on ICT third parties, concentration in a small number of providers, especially cloud providers, low substitutability and difficulty reintegrating outsourced services. That is why concentration should be measured as a property of the full service chain, not as a procurement statistic.
Implications for banks, fintechs, regulators and investors
For banks, the strategic question is how much proprietary cloud convenience they are willing to exchange for long-term portability. Critical workloads need architecture-level concentration limits, independent recovery capabilities and board-level visibility of provider dependencies. Procurement teams alone cannot manage a risk that can simultaneously affect customer channels, risk systems, data platforms and AI tools.
For fintechs, concentration can cut both ways. Hyperscalers make it possible for a small company to launch secure services rapidly and serve global clients. But a fintech whose entire product, security stack and data layer depend on one provider may transmit that dependency into every bank that uses it. Banks will increasingly ask not only whether a fintech is resilient, but whether its underlying technology chain is diversified and recoverable.
For regulators, the challenge is coordination. The same cloud provider can be critical to banks, insurers, exchanges, payment firms and public services across many jurisdictions. The EU DORA oversight framework and the UK Critical Third Party regime create direct oversight mechanisms, while UK and EU authorities have also established cooperation arrangements. The next frontier is credible cross-border incident testing and information sharing when a provider serves several financial systems simultaneously.
For investors, cloud concentration changes how technology resilience should be assessed. A bank with a modern cloud architecture may be operationally stronger than a legacy peer, but the quality of its exit plans, service mapping, cyber controls and contractual leverage becomes increasingly material. The balance sheet can look diversified while the technology stack is not.
Conclusion: cloud resilience is becoming a collective-action problem
Microsoft, Amazon and Google became central to banking because they solved real problems: scale, speed, cybersecurity, data processing and access to advanced AI. Their importance is not evidence of market failure by itself. It is evidence that technology infrastructure has become a strategic layer of finance.
The hidden risk appears when resilience is assessed one bank at a time. A provider can be exceptionally reliable and still create systemic vulnerability if too many critical services depend on the same technology, the same identity layer or the same recovery path. Diversification on a balance sheet does not protect against a shared control-plane failure.
The regulatory shift in Europe and the United Kingdom recognises this reality. Banks remain responsible for their own operational resilience, but some supplier risks now have to be managed above the level of the individual firm. The practical lesson is not to retreat from cloud. It is to treat cloud architecture, vendor portability and concentration mapping with the same seriousness that banks already apply to capital, liquidity and market infrastructure.
References
1. Bank of England and FCA - Artificial intelligence in UK financial services - 2024 (21 November 2024).
2. Bank of England - Financial Stability in Focus: Artificial intelligence in the financial system (April 2025).
3. Bank of England - UK financial regulators to begin overseeing Critical Third Parties announced by HM Treasury (10 July 2026).
4. Bank of England - Financial Stability Report (July 2026).
5. Competition and Markets Authority - Cloud services market investigation (final decision 31 July 2025).
6. Competition and Markets Authority - Annual report on concurrency for 2026 (2026).
7. European Central Bank - ECB finalises Guide on outsourcing cloud services (16 July 2025).
8. ECB Banking Supervision - Annual Report on supervisory activities 2025 (2026 publication).
9. ECB Banking Supervision - Technology is neutral, governance is not: AI adoption in the banking sector (24 February 2026).
10. European Supervisory Authorities - Designation of critical ICT third-party providers under DORA (18 November 2025).
11. European Banking Authority - DORA oversight framework (accessed August 2026).
12. EUR-Lex - Regulation (EU) 2022/2554, Digital Operational Resilience Act (DORA).
13. Financial Stability Board - Enhancing Third-Party Risk Management and Oversight: A toolkit (December 2023).
14. Bank of England / PRA / FCA - PS16/24 Operational resilience: Critical third parties to the UK financial sector (12 November 2024).