UK and EU critical-provider lists name different Oracle entities

Four names on the United Kingdom's first list of designated critical technology providers also appear, at the group-brand level, on the European Union's broader list of nineteen critical ICT third-party providers. A direct comparison of the two official documents, however, establishes a less obvious fact: only three of the four UK designations match the EU's published legal-entity names. Amazon Web Services EMEA SARL, Google Cloud EMEA Limited and Microsoft Ireland Operations Limited appear on both. The UK names Oracle Corporation UK Limited; the EU names Oracle Nederland B.V. The Oracle brand is common to both lists, but the regulated designation is not addressed to the identical corporate entity. That is a meaningful distinction for cross-border brokerage groups mapping their technology contracts and supervisory responsibilities.[3][1]

The finding emerges from a reconstruction of two regulatory systems that began on different dates and operate under different laws. The EU supervisory authorities published their initial nineteen-provider list on 18 November 2025 under the Digital Operational Resilience Act, known as DORA. The UK's Prudential Regulation Authority, Financial Conduct Authority and Bank of England began jointly overseeing the first four Treasury-designated critical third parties on 13 July 2026. The UK regime is not an application of EU DORA, and the EU does not simply extend the UK's designations into another territory. The two official lists describe jurisdiction-specific oversight relationships rather than a single international certificate of cloud safety.[3][1][2]

For a brokerage operating in London and several EU member states, the difference is practical. A group may rely on a cloud platform, a market-data provider, a managed database or a trading connectivity service across subsidiaries. Its commercial master agreement can be signed by one supplier entity, its invoices issued by another, and its actual data-processing service performed by infrastructure managed across several countries. A brand-only list can conceal those differences. Regulatory designation of a named third party does not, without further documents, prove that every affiliated entity, subcontractor, customer contract or product is covered in the same manner.[3][1][2]

The list comparison that changes the denominator

The UK list contains four entities; the EU list contains nineteen. Of the UK four, three reproduce the same provider names on the EU list, with immaterial spelling or capitalisation differences. The fourth matches at corporate-group level, because both designations concern the Oracle business, but its formal legal name differs. Counting exact designated legal entities produces three overlaps. Counting the corporate groups represented produces four. Those are different counts, with different operational meanings.[3][1]

The legal-entity distinction is clearest in the Oracle entries. A brokerage compliance inventory that labels both Oracle designations simply 'Oracle' may be useful for board-level exposure mapping but insufficient for identifying the actual entity against which a regulator exercises specific powers. Conversely, it would be wrong to infer that the Oracle businesses in Britain and the Netherlands are operationally unrelated merely because they are different companies. The public designation lists do not map their internal service agreements, subcontracting chains or ownership in the way a full corporate due-diligence exercise would require.[3][1]

The EU's other fifteen names broaden the picture beyond the three exact overlaps and the distinct Oracle entity. Its list includes Accenture, Bloomberg, Capgemini, Colt, Deutsche Telekom, Equinix (EMEA), Fidelity National Information Services, IBM, InterXion, Kyndryl, LSEG Data and Risk, NTT DATA, Orange, SAP and Tata Consultancy Services. These are not all equivalent cloud-hosting businesses. Some supply market data, enterprise software, network infrastructure or other critical information-technology functions. That breadth helps explain why a raw comparison of '19 versus 4' is not a quality ranking of European and British oversight.[1]

The lists also cannot tell us how many brokers use each provider. A designation is a supervisory decision made against statutory criteria, including the systemic consequences of a disruption. It is not an industry census, contract registry, market-share report, or certification that a product never experiences outages. A provider omitted from the first UK list may still provide vital outsourced services to an individual firm. Its absence does not exempt a regulated broker from monitoring that dependency.[3][1][2]

Two mechanisms, not one international licence

The FCA's explanation is specific about what the new UK oversight targets. The rules apply to a designated critical third party from the effective date of its Treasury designation. The regulators' scrutiny is directed at the systemically important services the provider supplies to UK financial firms and market infrastructures, not the entirety of its commercial business. UK regulators can obtain information, conduct resilience assessments and coordinate supervision of those services. The FCA also says the rules complement, rather than replace, firms' existing risk-management obligations.[3][2]

The EU framework has its own legal architecture. DORA identifies critical ICT third-party service providers at Union level and places them within a European supervisory-oversight framework involving the European Supervisory Authorities. The naming of a provider gives the authorities a route to assess and address system-level information-and-communications-technology risks. The obligations borne by financial entities using those providers continue alongside the oversight regime. Treating a designation as the transfer of a broker's own operational-resilience duties to a cloud supplier would misunderstand the structure of both systems.[1][3]

The respective start dates matter. The UK's critical-third-party framework took effect in January 2025, but the first specific designations became effective in July 2026. The EU list was published the previous November under DORA. An article dated July 2026 that described UK oversight as newly commencing referred to the designation date, not the first day the concept existed in law. Similarly, a contract review performed against the EU list in late 2025 would not necessarily contain the UK's later legal names. The inventory needs an as-of date, not merely a permanent yes/no column.[3][1][2]

The UK process also allows the Treasury to designate or de-designate providers. Its present four are a starting list, not a statutory ceiling. In the EU, the published list reflects the relevant designated population at its stated date. Neither document promises that its list will never change. A cross-border broker that hard-codes the names into procurement software and fails to refresh the source will create a compliance and continuity risk even if the initial snapshot was entirely accurate.[3][1]

Why the precise supplier matters at the trading desk

Consider a hypothetical retail CFD broker with an authorised UK entity, an EU investment-firm entity, a common cloud-based CRM, and exchange-data feeds used for pricing checks. The broker needs to know which legal entity purchases the CRM, which group company operates it, whether identity documents or transaction logs are processed elsewhere, and which outsourced service supports a designated important business service. It cannot answer those questions from 'AWS' or 'Oracle' as a brand alone. The designated-party lists supply one important regulatory overlay, but contracts, service maps and technical dependency records supply another.[3][1][2]

For execution infrastructure, the failure mode may be a common dependency. Several apparently separate brokerage brands might obtain price feeds from different front-end vendors whose back-end hosting or messaging runs through the same regional provider. A disruption could propagate across trading, order monitoring and customer communications. The public lists establish regulators' concern about systemic third-party exposure; they do not establish that any named broker has such an architecture or that an outage occurred. Testing shared dependencies requires information the lists do not contain.[3][1]

Vendor identification should also distinguish a direct supplier from a fourth-party subcontractor. A broker may contract with a trading-software company that itself buys database services or infrastructure from a designated provider. The brokerage's vendor register might capture only the direct company. A service map intended to test resilience should identify material underlying dependencies where feasible, subject to contractual visibility and confidentiality. These are reasonable questions arising from the regimes, not a finding that firms have breached them.[3][2]

A separate mistake is to infer legal protection for client money from designation. A technology provider's inclusion on either list says nothing on its own about the treatment of cash in a broker's bank accounts, the adequacy of regulatory capital, protection under a compensation scheme or whether an investor's execution was fair. Those are distinct legal obligations and evidential questions. Critical-technology oversight primarily concerns continuity, resilience, information sharing and wider-system threats. A 'regulated cloud' label cannot substitute for broker financial due diligence.[3][1][2]

A cross-border supervision problem, not proof of a regulatory gap

The lists create at least three mapping tasks for an international financial group. The first is exact-party matching: which UK and EU supplier entities are formally named? The second is group matching: do the companies belong to the same commercial technology group, potentially creating common operational exposure? The third is service matching: which actual systems, contracts, infrastructure regions and regulated business services depend on them? Each layer answers a different question. The first two can be reconstructed from published lists and corporate material. The third requires firms' private data and provider documentation.[3][1][2]

There is a limitation to the term 'overlap'. The EU list names nineteen distinct entries, but that does not mean nineteen separate underlying technical infrastructure stacks or nineteen mutually independent outage risks. Corporate groups may be linked through subcontracting, networks, interconnection services and common software components. Likewise, there are not necessarily four independent stacks behind the four UK names. The present comparison is an administrative legal-entity analysis; it is not a statistical assessment of concentration or a modelled loss distribution.[3][1]

A properly designed control would store the exact designated legal name, jurisdiction, effective date, regulator and official source URL, alongside a separate corporate-group identifier and supplier-contract entity. It would record whether a service is direct or indirect and which critical business process it supports. That prevents both errors: counting Oracle as the same designated legal person in two regimes, or treating differently named Oracle entities as proof of independent underlying resilience. The information should be time-stamped so later designations or de-designations can be reconciled without erasing the original evidence.[3][1][2]

Different named entities do not establish conflicting regulation, an omitted service or a weakness at any provider. The lists identify formal oversight subjects. Assessing the scope of a particular service would require the applicable designation, group arrangements and customer contract together. A legal-name comparison can identify where a broker needs that second layer of work, but it cannot establish how an unidentified contract is supervised.[1][2][3]

The next question the public lists cannot resolve

A more consequential industry-wide inquiry would ask how many brokers and trading venues across the UK and EEA share each provider, how concentrated their material operational services are, and whether apparent multi-cloud arrangements are truly independent across identity services, networking, database management and market-data processing. Such a study could test whether a single failure affects multiple intermediaries and whether continuity plans rely on the same service they are supposed to replace. Public designation names alone cannot answer it; properly anonymised supervisory or industry evidence could.[3][1][2]

For a disruption spanning the two jurisdictions, coordination already has a published framework. The FCA's January 2026 announcement says the UK authorities and European Supervisory Authorities signed a memorandum covering oversight information sharing, including during incidents such as power outages and cyber-attacks. Its stated aims include reducing duplicated oversight and regulatory burden. The open evidential question is how that arrangement performs in a particular incident, which would require incident and supervisory records. It would be inaccurate to infer from the differently named Oracle entities that no coordination mechanism exists.[4]

The two lists therefore support a precise operational finding: all four UK group brands are represented in the EU's inaugural nineteen-entry list, but only three match at the designated legal-name level. Oracle Corporation UK Limited and Oracle Nederland B.V. must remain separate entries in a supplier map. Group ownership, contractual responsibility and shared infrastructure can then be linked to those entries without erasing the legal distinction.[1][2][3]

Report an error or submit an update