The UK's Critical Third Parties regime reached an important operating milestone on 13 July 2026. Four cloud and technology providers became the first designated Critical Third Parties (CTPs), bringing the systemic services they provide to the financial sector within joint oversight by the Bank of England, Prudential Regulation Authority and Financial Conduct Authority (FCA).¹
For Open Banking firms and enterprise buyers, direct oversight provides a new source of regulatory scrutiny at a concentrated part of the technology supply chain. It does not transfer responsibility for a payment or data service to the regulators or the cloud provider. The FCA is explicit that firms remain responsible for managing their own third-party risks under existing operational-resilience and outsourcing requirements.¹
That boundary should influence architecture, procurement and governance. A firm needs to know which customer services depend on which cloud capabilities, where common failure modes sit, what its contracts make visible and how it will prove that recovery arrangements work. The designation decision makes this work more urgent and potentially better informed, while leaving the work itself with the firm.
The UK Critical Third Parties regime is now operating
The designated legal entities are Amazon Web Services EMEA SARL, Google Cloud EMEA Limited, Microsoft Ireland Operations Limited and Oracle Corporation UK Limited. The designation regulations took effect on 13 July 2026.²
Scope needs careful wording. The regulators oversee the systemic services that a designated CTP provides to UK regulated firms and financial market infrastructures. The designation does not place every global product, customer relationship or activity of the four corporate groups within the regime. HM Treasury also describes the framework as rolling, so further providers may be designated where disruption could threaten UK financial stability or confidence.²
The rules themselves are not new in July 2026. The regulators consulted from December 2023 to March 2024, published final policy and rules in November 2024, and brought the framework into effect on 1 January 2025. The first designations activate those requirements for the named providers.¹
At CTP level, the rules address outcomes including risk management, dependency mapping, resilience testing, incident management, information sharing and support for orderly termination of services. The Bank summarises the expectation as identifying and managing risks to systemic services while maintaining open and timely communication with regulators and dependent firms, particularly during major incidents.³
This creates a direct oversight relationship where regulators can gather information, assess resilience and intervene in relation to systemic services. It also creates a clearer distinction between two control layers:
- the CTP is accountable for the requirements that apply to its designated systemic services;
- each regulated firm remains accountable for how it uses third parties to deliver its own important business services.
Those layers should exchange information, but they do not collapse into one another.
Direct oversight does not transfer accountability
An Open Banking payment can depend on a long chain: the customer-facing application, identity and access management, consent records, payment orchestration, secrets and key management, API gateways, queues, databases, monitoring, bank interfaces and the Faster Payments path. Some components may sit with one cloud provider, while others depend on software suppliers, an Open Banking infrastructure provider, an Account Servicing Payment Service Provider (ASPSP) or another operator.
A designation at one point in that chain cannot establish whether the end-to-end service will remain within tolerance. Regulators may obtain stronger assurance about a systemic cloud service, yet a firm can still fail because its own configuration is weak, a recovery procedure is untested, an identity dependency is shared across regions, or an application cannot reconcile transactions after restoration.
Existing FCA operational-resilience requirements continue to provide the firm-level frame. They apply to entities authorised or registered under the Payment Services Regulations 2017 and Electronic Money Regulations 2011, among other firms. In-scope firms had to identify important business services, set impact tolerances and complete mapping and testing so that they could remain within those tolerances by 31 March 2025.⁵
Our Open Banking operational resilience playbook explains that foundation. The July 2026 designations add a new oversight context, not a substitute for service ownership.
Boards and senior owners should therefore resist two weak conclusions. The first is that a designated provider is automatically a safe choice for every workload. The second is that direct regulatory oversight makes concentration irrelevant. Provider capability, regulatory oversight and the resilience of a particular service design are separate questions.
The CTP regime and the 2027 reporting rules are different
The CTP framework directly regulates designated providers in relation to systemic services. A separate FCA policy governs how firms will report operational incidents and material third-party arrangements from 18 March 2027. Combining the two can lead to incorrect scope and timing claims.
Under the final 2027 rules, operational incident reporting will cover payment service providers as well as firms with Part 4A permissions and several other categories. Material third-party reporting has a narrower stated scope that includes authorised payment institutions and authorised electronic money institutions. In-scope firms will need to notify the FCA when entering into a material third-party arrangement or significantly changing one, maintain a register and submit it annually.⁶
The FCA defines a material arrangement by its potential effect. Disruption or failure could cause intolerable harm to clients, threaten the soundness or resilience of the financial system, or cast serious doubt on the firm's ability to meet threshold conditions or relevant obligations. The rules cover a wider range of third-party arrangements than traditional outsourcing.⁷
These are final future-effective rules. Firms should prepare during the implementation period, while avoiding the claim that the new reporting duty already applies. Existing notification, outsourcing and operational-resilience obligations continue in the meantime.⁷
For payment firms, the practical benefit of treating the regimes separately is precision. A supplier may be a designated CTP, a material third party for the firm, both, or neither. The classification depends on the legal entity, service, arrangement and applicable rule. A control register should preserve those attributes rather than assigning one broad label to a corporate group.
Map cloud dependencies to customer services
A useful dependency map begins with the service received by the customer, rather than with a list of vendors. For an Open Banking payment service, that might be the ability to initiate a payment, confirm its outcome and recover safely from an uncertain state within a defined period.
Work backwards from that outcome:
- identify the business process and customer journey, including initiation, authentication, authorisation, submission, status retrieval and reconciliation;
- connect each stage to applications, data stores, queues, network paths, identity services, keys, monitoring and operational teams;
- record the direct supplier, relevant subcontractors and the legal entity in the contract;
- show which components share a cloud region, control plane, identity tenant, network, deployment pipeline or support function;
- attach the impact tolerance, recovery objective, test evidence and accountable owner.
The exercise should include non-cloud dependencies. Bank API availability, certificate services, domain name resolution, telecommunications, fraud tooling and settlement information can all determine whether the customer receives a reliable result. The enterprise Open Banking integration checklist provides a broader starting point for supplier assessment.
Mapping at product-name level is too coarse. A statement that a service runs across two regions says little about whether both regions rely on the same identity control plane or whether staff can deploy a fix when a central administration service is unavailable. The map needs enough detail to expose shared failure domains and recovery prerequisites.
Test actual failure domains
Provider diversity can reduce some concentration risks, but a multi-cloud label does not prove resilience. Two deployments may share source-control access, identity, observability, key management, network transit or a small operations team. A failover may also create a consistency problem if consent, mandate or payment state cannot move safely between environments.
Open Banking testing should concentrate on transaction integrity as well as availability. A recovered service must know whether a payment was authorised, submitted, accepted, rejected or left uncertain. Retrying without that evidence can create duplicate instructions. Stopping all retries can leave legitimate payments incomplete.
Severe but plausible tests should therefore cover scenarios such as:
- loss of a primary region while the provider's central control plane is degraded;
- failure of identity or privileged-access services during incident response;
- queue recovery with delayed, duplicated or out-of-order events;
- restoration of consent and payment state from backups with measurable recovery point objectives;
- loss of an observability provider while customer impact is increasing;
- conflicting status information between the Open Banking interface, internal ledger and settlement records;
- extended supplier disruption that requires a controlled reduction of service or an exit plan.
The joint CTP policy expects designated providers to map dependencies and test resilience at their layer.⁴ A firm should use available CTP assurance and incident information as inputs to its own scenarios. It still needs to test the application, data and operational decisions that sit on its side of the service boundary.
Contract for evidence, response and exit
Supplier contracts translate the architecture boundary into enforceable operating arrangements. Standard cloud terms may offer extensive technical capability while leaving the customer to configure, monitor and test it. Regulated firms need to understand that allocation before relying on general descriptions of resilience.
For an important Open Banking service, the contract and supporting schedules should make the following clear:
- the contracted legal entity, service scope, locations and critical subcontractors;
- security, availability, recovery and data-protection responsibilities on both sides;
- incident thresholds, notification routes, update frequency and access to post-incident findings;
- rights to receive assurance, participate in testing or obtain evidence that supports the firm's own testing;
- notice and support for significant service, subcontractor or location changes;
- access to data and logs needed for reconciliation, complaints, regulatory reporting and lessons learned;
- termination support, data return or deletion, portability and the conditions for an orderly exit.
These points are implementation and procurement guidance, not new duties created solely by designation. Their purpose is to give the firm enough information and practical control to meet the obligations that apply to its service.
An enterprise buyer should ask its Open Banking provider how cloud-level assurance flows through the service chain. The answer needs to address application recovery, transaction evidence and operational communications, rather than ending with the name of a hyperscaler.
Build one versioned evidence model
Operational-resilience evidence often becomes fragmented across risk registers, architecture diagrams, supplier reviews, incident tickets and test reports. The CTP designations and the 2027 reporting rules increase the value of connecting those records.
A versioned evidence model can use a stable identifier for each important business service and link it to:
- accountable owners and the applicable regulatory perimeter;
- service maps and current architecture versions;
- suppliers, arrangements, subcontractors and materiality assessments;
- impact tolerances, recovery objectives and approved exceptions;
- contract clauses, assurance reports and remediation commitments;
- scenario tests, findings, owners and retest dates;
- incidents, customer effects, regulatory notifications and lessons learned;
- exit plans, portability tests and decision triggers.
Versioning matters because the correct answer changes over time. A new managed service, identity provider or subcontractor can alter the failure model without changing the product presented to customers. Evidence should show which dependency set, policy and test result applied on a given date.
This also reduces duplicate work. The same controlled data can support board reporting, supplier reviews, operational-resilience testing and preparation for regulatory reporting, provided the firm preserves each regime's scope and required fields.
A practical 90-day sequence
The designation decision does not impose a universal 90-day deadline on firms. A 90-day internal sequence is useful because it creates momentum while leaving room for risk-based prioritisation.
During days 1 to 30, confirm scope. Identify important Open Banking services, the four designated legal entities in the supply chain, the contracted cloud services and the owners of each dependency record. Compare the current map with live architecture and remove assumptions that cannot be evidenced.
During days 31 to 60, test the boundaries. Review concentration across regions, identity, networking, data, observability and operations. Select the highest-consequence scenario, run or schedule a controlled test, and record whether recovery remains within the relevant impact tolerance.
During days 61 to 75, close information gaps. Review contracts, incident routes, assurance access, subcontractor visibility and exit support. Where the firm cannot obtain evidence, record the gap, the risk decision and a funded remediation action.
During days 76 to 90, align reporting preparation. Determine whether the firm falls within each part of the March 2027 FCA rules, map current data to the regulator's templates and assign ownership for notifications and the material third-party register. The result should feed the board or accountable committee rather than remain a procurement exercise.
Keep current decisions separate from open proposals
The CTP designations, existing operational-resilience rules and the March 2027 reporting policy have defined status and dates. Other payment work remains open. HM Treasury is consulting on broader payment-services reform until 6 October 2026, as covered in our guide to modernising payment services regulation. The Retail Payments Infrastructure Board is also consulting separately on future clearing and messaging design, which follows the questions in our article on future retail payments infrastructure.
These programmes may change responsibilities, interfaces and dependency patterns later. They do not alter the present CTP boundary until legislation, rules or final decisions say so.
The next firm-level reporting milestone is 18 March 2027. Before then, teams should monitor guidance arising from initial CTP oversight, any further designations and changes to the services identified as systemic. A useful review asks whether each new official development changes a legal duty, a regulatory expectation, a supplier fact or an internal risk judgement.
The July designations give the UK authorities a direct view of concentrated technology services. Open Banking firms can benefit from the stronger oversight and information flows that follow. Their own standard remains end-to-end: know the service, understand the dependencies, test recovery and retain the evidence.
Footnotes
- Financial Conduct Authority, `Critical Third Parties: Strengthening UK Financial Services`. FCA CTP regime and timeline
- HM Treasury, `UK financial system strengthened with new safeguards for major technology providers`. Government designation announcement
- Bank of England, `Critical Third Parties`. Rules, guidance and oversight framework
- Bank of England, Prudential Regulation Authority and Financial Conduct Authority, `PS16/24 Operational resilience: Critical third parties to the UK financial sector`. Joint final policy and rules package
- Financial Conduct Authority, `Operational resilience`. Firm requirements and scope
- Financial Conduct Authority, `PS26/2 Operational incident and third party reporting`. Final policy and 18 March 2027 effective date
- Financial Conduct Authority, `Reporting material third party arrangements`. Implementation scope and preparation