Digital Operational Resilience: Managing Critical Third-Party Risk

WAU Marketing

2 days ago

5 min read

Your bank can run at 99.99% of its own uptime and still go completely dark in a single day. Because the resilience question is no longer "is my system up?" but "how many third parties does that depend on, and what happens when one of them fails?"

For years, the conversation about banking availability stayed inside the bank's own walls: redundancy, failover, recovery times. All of that still matters. But the real risk moved outward. A modern bank now sits on a stack of third parties—cloud hyperscalers, core providers, payment processors, antivirus, networks—and each one is a single point of failure the bank doesn't control. The paradox is uncomfortable: the more you outsource to gain efficiency, the more you concentrate risk in someone else's hands.

The day a single provider took down the world

This isn't theory. On July 19, 2024, a faulty update from CrowdStrike—a cybersecurity company, not a bank—rendered roughly 8.5 million Windows machines inoperable worldwide, in what is considered the largest IT outage in history, as documented in the incident record. Among those affected were airlines, hospitals and, of course, banks: Chase, Bank of America, Wells Fargo and Capital One in the US; RBC, Scotiabank and TD in Canada; and institutions in South Africa, Israel and the Philippines. None of those banks had a problem in their own system. They went down because of a third party.

The cost makes clear why this is a resilience issue, not a help-desk one. Parametrix estimated direct losses for Fortune 500 companies (excluding Microsoft) at $5.4 billion, with the banking sector absorbing about $1.15 billion of that figure, Fortune reported. A vendor most customers had never heard of paralyzed ATMs, branches and apps across half the planet.

The technical name for the problem: concentration risk

What CrowdStrike made visible, regulators had already been warning about. The problem is called concentration risk: when too many institutions depend on a handful of the same providers, the failure of just one stops being an incident and becomes systemic. The Financial Stability Board (FSB) surveyed nearly 300 financial institutions of varying sizes and found that most tend to rely on a very narrow set of major providers, which could produce systemic effects in a large-scale operational failure or insolvency, per its report on cloud adoption and concentration risk.

The Bank of England put a number on that concentration: as far back as 2020, just two providers—AWS and Microsoft Azure—accounted for around two-thirds of UK banks' cloud infrastructure usage, a figure its Financial Policy Committee flagged as a material risk. The committee's warning is blunt: growing reliance on a small number of cloud providers and other critical third parties could increase financial-stability risks absent direct oversight of their resilience.

What regulators started to demand (DORA as the framework)

Europe was first to turn the warning into law. The Digital Operational Resilience Act (DORA) took effect on January 17, 2025 and applies to 21 types of financial entities and their critical technology providers, according to the European Insurance and Occupational Pensions Authority. The most novel piece: for the first time, critical technology providers fall under regulators' direct oversight, precisely to attack concentration risk. On November 18, 2025, the European authorities published the first list of 19 providers designated as critical—among them AWS, Microsoft, Google Cloud, Oracle and SAP—now facing annual risk analyses, on-site inspections and reporting obligations, FStech reported.

The UK followed the same logic with its Critical Third Parties regime, whose final rules the Bank of England, the PRA and the FCA published on November 12, 2024, per the official statement. The global regulatory message is one and the same: it's no longer enough for the bank to be resilient; the bank must prove its provider chain is resilient too.

LATAM: the requirement is already on the table

The region hasn't lagged. In Mexico, the CNBV regulates third-party contracting within the General Provisions Applicable to Credit Institutions (the CUB), which sets technical, operational and contractual requirements when a bank outsources processes or the administration of databases and systems, per the current text published by the CNBV. In its authorization guidance, the CNBV requires due diligence, service monitoring, subcontracting controls, data confidentiality, audit and access rights, business continuity and—key to this topic—data portability, as its guide for third-party service contracting details. That last word—portability—is where core architecture stops being a technical detail and becomes the difference between complying and being trapped.

How a well-designed core cuts the risk (and a badly designed one amplifies it)

Here's the nuance the noise omits. Concentration risk isn't solved with a stricter contract; it's solved with architecture. A legacy core, coupled to a single provider through proprietary integrations and closed formats, turns any dependency into a hostage situation: if that provider goes down, raises prices, or falls out of compliance, leaving takes years. A modern core does the opposite by design:

Real portability. If your data and logic live behind standard APIs and in open formats, moving a workload from one provider to another is a decision, not a rebuild.
Multi-provider strategy. A decoupled architecture lets you spread critical workloads across providers or regions, so one outage doesn't switch off the whole bank.
Orderly exit. Regulators ask for verifiable continuity plans and exit strategies. On an open core, those plans are executable; on a closed one, they're a wish list.
Chain visibility. You can't manage the risk of a third party you can't see. A modern core exposes what depends on whom—a precondition for any serious resilience test.

Operational resilience, properly understood, isn't buying more redundancy inside your castle. It's not having built the castle on a single foundation you don't control.

How we see it at WAU

At WAU we design the core so that third-party resilience is a property of the architecture, not a patch added later. Data and logic exposed through standard APIs, in open formats, with portability and an exit strategy from day one: that's what makes your continuity plans credible before the CNBV, and what lets you spread risk instead of concentrating it. 24/7 availability is the promise; independence from any single provider is what holds it up when that provider fails.

If you want to know how exposed your bank is today to a critical third-party failure—and what your architecture needs to reduce it—let's talk. 👉 Book a conversation with our team.