The Critical 19: CCTP List Analysis

The Critical 19: what the CCTP list actually tells us.

Gleb Etinzon, DORA Consultancy.
A boutique consultancy addressing complex regulatory requirements in a pragmatic way. London, UK.

In Part 1, I argued that the DORA Register of Information is being treated as a filing exercise rather than a risk tool, and that the 99.87% of ICT providers below the CCTP threshold are where incidents actually originate. This piece examines the 0.13% — the 19 designated Critical ICT Third-Party Providers — and asks whether the designation itself holds up against the regulator's own statutory criteria.

The short answer: the list is defensible as a political artefact. As an analytical instrument, it has serious structural problems that financial entities need to understand before they let it shape their own concentration-risk assessment.

Observation 1 — The subcontracting clause is the smoking gun, and it points at three providers

The “irrespective … directly or indirectly, through subcontracting arrangements” wording in Article 31(2)(c) is unambiguous. The criticality of a provider should be assessed including the chain of dependencies the financial entity has through subcontracting.

But the published list treats SAP, Oracle, FIS, Kyndryl, Accenture, Capgemini, TCS and NTT DATA as standalone CCTPs — when the public evidence shows that material parts of their service to financial entities are delivered on AWS, Azure or Google Cloud. There are only two ways to read this:

Option A — the criterion was applied properly. In that case, the criticality scores for AWS, Azure, and Google Cloud already reflect the indirect reliance routed through SAP RISE, FIS Modern Banking Platform, Kyndryl-managed Azure environments, Capgemini-Google delivery contracts, and the rest. If true, the real systemic-impact concentration sits at three providers, and the other 16 are at least partially double-counted relative to the same underlying risk.

Option B — the criterion was applied in a literal, contract-counterparty way. In which case, the indirect reliance was not aggregated upward, and the ESAs' criticality scoring understated hyperscaler concentration by attributing dependencies to the immediate counterparty rather than the underlying infrastructure host. If true, the published “Critical 19” understates the actual concentration story.

Either way, the financial entity is the one left to reconcile that gap in its own register.

But the substitutability picture inverts for the on-prem segment

The framing above holds for the cloud-native, hyperscaler-dependent segment of EU banking — the modernised tiers of large banks, fintechs, and digital-first insurers. That is not the entire sector.

A material share of EU financial entities is still substantially on owned data-centre estates or co-located infrastructure. This population includes Tier-1 European banks running core banking on IBM zSeries mainframes (Deutsche Bank, BNP Paribas, Société Générale, Santander, ING all maintain large mainframe estates), custodian banks where settlement-grade latency and historical data sovereignty constraints favour dedicated infrastructure, central counterparties and trading venues running matching engines in co-located cages with sub-millisecond latency to participants, and a long tail of payment institutions, mid-tier banks, and asset managers running their own racks in commercial data centres.

For this segment, the substitutability picture is very different:

Equinix and InterXion become primary infrastructure, not a layer below the hyperscalers. Co-location concentration in the major financial-centre data halls — Equinix LD4/LD5/LD6 in Slough, FR2/FR4/FR5 in Frankfurt, AM3/AM4/AM5 in Amsterdam; Digital Realty's TH1/TH2 in London Telehouse North — is genuinely systemic for trading-floor and clearing workloads. Moving a co-located trading engine across data centres is a 12–18 month programme involving cross-connect re-provisioning, latency re-baselining, and counterparty re-cabling. Substitutability: low.

Colt is the dominant low-latency international network for European trading floors. Substitutes exist, but the cross-connect topology of any given trading venue strongly favours one or two carriers, and migration is multi-quarter and disruptive. Substitutability for general WAN is high; substitutability for low-latency exchange connectivity is low.

IBM and Kyndryl mainframe maintenance is arguably the most locked-in dependency on the entire CCTP list. A mainframe COBOL replatforming programme is a 5–10 year, hundreds-of-millions-of-Euros undertaking (see the publicly disclosed transformation timelines at Lloyds Banking Group, Commonwealth Bank of Australia, and ING). Kyndryl is the spin-off that took the IBM Global Services mainframe-management book; the lock-in transferred with the contracts.

The CCTP list is a single flat list, but the actual concentration topology depends on which segment of the EU financial sector you are in. A fintech populating B_05.01 will produce a register that looks like a tree with three roots (AWS, Azure, GCP). A custodian bank or a central counterparty populating the same template will produce a register that looks more like an estate ledger: data hall, cage, cross-connect, mainframe LPAR, network carrier. Both are accurate; both are CCTP-relevant; neither is the whole picture.

The sub-entity defence does not solve the extraterritoriality problem

A natural defence offered by the US-controlled CCTPs is that the designated entity is an EU sub-entity — Luxembourg-incorporated, Dutch-incorporated, Irish-incorporated — contractually counterparty in EU jurisdiction, with EU-resident data centres. This is true, and it does provide some protection on data-residency and applicable-contract-law questions. It does not solve the extraterritorial reach of US law over the parent. The CLOUD Act and FISA 702 reach the parent regardless of where the data sits or which sub-entity signed the contract.

And one EU-sovereign CCTP runs its flagship on a Chinese hyperscaler

SAP SE, one of the four genuinely EU-controlled CCTPs, publicly documents that RISE with SAP S/4HANA Cloud Private Edition runs on Microsoft Azure, AWS, Google Cloud and Alibaba Cloud. The German national-champion ERP provider, designated as an EU-systemic CCTP, lists a Chinese hyperscaler in its public infrastructure stack. EU-sovereign at the headline; multi-jurisdictional at the substrate. Even the EU-controlled CCTPs only get sovereignty as far down the stack as their own procurement choices permit.

Below the 19, the long tail is even more foreign

The 14,981 ICT providers that did not make the CCTP list are not a parochially European population either. The mid-tier and tail of EU financial-sector ICT supply is dominated by Indian IT services (Infosys, Wipro, HCL, Tech Mahindra — TCS is on the CCTP list; the others are not, but have comparable EU banking footprints), US niche fintech infrastructure (Stripe, Plaid, Twilio, MongoDB Atlas, Snowflake, Databricks), Israeli cybersecurity (Check Point, CyberArk, Wiz, Palo Alto Networks via Demisto — the Israeli vendor concentration in the EU bank security stack is striking), and Eastern European outsourcing (Romania, Poland, Czech Republic, Ukraine) that often sits invisible at the contract surface as subcontractors of larger Western European integrators.