Alongside the supervisory work, authorities continued to codify expectations for third-party risk management, often as one element of broader cyber, operational resilience or sectoral frameworks rather than as standalone outsourcing rules. Key milestones were the European Banking Authority’s final guidelines on non-ICT third-party risk, the US agencies’ proposed replacement of their third-party risk management guidance, and CPMI-IOSCO’s consultations on financial market infrastructures’ reliance on service providers and on a cyber resilience toolkit.

Across initiatives, particular attention was placed on four areas, the last three of which mirror the practical challenges observed in supervisory reviews:

Authorities are broadening the range of arrangements within scope while reserving the more demanding requirements for those that support critical or important functions or otherwise carry material risk. The aim is to direct oversight effort to where the risk actually lies rather than to apply uniform, process-driven controls to every relationship, a concern the US agencies cite explicitly in proposing to replace their 2023 guidance; the EBA guidelines extend coverage from outsourcing to all non-ICT third-party arrangements on the same basis.

Contracts are treated as the main instrument through which firms secure the ability to oversee a provider throughout the relationship, not only at onboarding. Initiatives converge on a core set of terms: access to the information needed to monitor performance, prompt notification of incidents, advance notice of or consent to changes in subcontracting, and support for an orderly exit, including the transfer of data. The Dutch AFM extends this to recovery commitments aligned with the firm’s own recovery objectives.

Expectations for due diligence and risk assessment now reach beyond the direct provider to its own suppliers and to the dependencies that several relationships have in common, such as shared infrastructure, concentration on a few providers and single points of failure, which may not be apparent when relationships are assessed one by one. Some authorities, including those in Ukraine, Moldova and Mozambique, also sought more direct supervisory visibility of, or control over, firms’ technology and outsourcing arrangements, through reporting on software jurisdiction, cloud use and server locations, prior notification or approval of ICT outsourcing, and requirements on data location.

Authorities acknowledge that firms, particularly smaller ones, may be unable to obtain from large or dominant providers the contractual terms their frameworks presuppose. Responses take two forms: recognising the limits of what firms can achieve alone and pointing to collective approaches, such as negotiating as a group or through consortia, as a source of leverage, as the proposed US guidance does; and bringing providers’ own transparency and contract practices into supervisory scrutiny, as the US agencies’ statement on core providers does. CPMI-IOSCO lists the same imbalance among the challenges facing financial market infrastructures.

Third-party dependencies are also a central concern in authorities’ policy work on AI. Guidance issued or consulted on between June and October, by the Financial Stability Board (FSB), the UK’s Mills Review, the Monetary Authority of Singapore (MAS) in final guidelines, the Bermuda Monetary Authority (BMA) in a consultation and South Korea’s Financial Services Commission (FSC) in updated voluntary guidelines, applies the established disciplines of third-party risk management to the particular features of AI services: AI embedded in products not sold as AI, models that providers change after deployment, limited transparency over how models were built, data passed to providers, and concentration on a small group of upstream providers.

AI can reach an institution through features embedded in existing vendor products or through a supplier’s use of AI in delivering a service, often without being labelled as such.

Guidance expects institutions to identify such AI systematically and to link it to their existing third-party oversight rather than build a separate regime. MAS and the BMA set the same three expectations by different routes. On scope, MAS expects identification to cover AI incorporated in services from material providers, including software-as-a-service products with AI features that are not sold as AI, while the BMA focuses on embedded features whose new or materially changed capabilities alter a service’s risk profile. On AI that escapes identification, MAS points to staff rules on permitted use and technical controls such as network monitoring and data loss prevention, the BMA to existing information security, training and acceptable-use arrangements. On records, neither requires a separate register: MAS expects consistent vendor identifiers linking the AI inventory to third-party registers, and the BMA allows existing inventories to be used provided they record an AI system’s third-party dependencies.

Providers can update underlying models or add AI to existing services after an institution has approved them, often with limited notice and without the option to roll back.

Guidance responds in two steps: contracts should secure advance notice of, or a say over, AI being introduced or changed, and such changes should then trigger the institution’s own reassessment and approval. MAS specifies the clauses, notification or the institution’s prior agreement, calibrated to risk, and asks institutions to consider whether they will in practice receive and be able to act on such notifications. The BMA leaves the mechanism to the institution: contracts should address material model or feature changes where proportionate and reasonably achievable, and in material use cases a change of model, provider or configuration passes through the institution’s change management, which determines whether further testing, approval, monitoring or fallback arrangements are needed.

Providers often do not disclose model details, weights or training data, which limits how far institutions can assess externally supplied AI compared with models built in-house.

Neither MAS nor the BMA requires full technical transparency. Both expect institutions to establish whether the information and assurance available suffice for the intended use, to compensate for gaps through their own testing and controls, and to restrict or forgo use where residual risk remains outside appetite. The BMA states explicitly that institutions are not expected to obtain proprietary model information that is not reasonably available or contractually supported, and lists compensating controls from usage restrictions and additional testing to staged deployment and confining the system to lower-risk uses. MAS is more demanding on assurance: institutions should test third-party AI against their own use cases and data, document the basis on which they found it suitable, rely on independent certifications or assessments rather than providers’ self-attestations, and evaluate complex services such as third-party AI agents in more detail.

Due diligence also reaches the components on which external AI services are built, which the BMA defines to include models, datasets, software libraries, plugins, APIs, agent frameworks, update channels and cloud and hardware infrastructure. MAS expects key third-party and open-source models, datasets and dependencies to undergo supply chain risk assessment, covering model provenance, training data integrity and known vulnerabilities. The FSC focuses on tampering: institutions should verify before use that external and open-source models have not been maliciously manipulated, adopt models only from trustworthy providers after confirming their origin and development history, and check externally sourced training data for deliberate manipulation or poisoning.

Data that institutions pass to external AI services, including prompts, internal documents and customer information, may be retained, reused to train provider models or processed in other jurisdictions.

Guidance brings this information within institutions’ data governance and expects contracts to limit how providers use, store and transfer it. The FSB’s proposed sound practices cover prompts, documents and other context provided to third-party tools, as well as tools that access institutional data to generate outputs, and call for contractual provisions on data access, quality and security, including the jurisdictions in which data will be processed. The FSC turns this into checks to be made before a cloud-based or commercial generative AI service is used: whether data may be transferred abroad, and whether the terms or contract prevent the provider from reusing it to improve its models, including through training. Its illustrative contracts require domestic storage and prohibit both training on input data and onward provision to third parties.

Many AI services rely on the same small group of foundation model, cloud and hardware providers, so institutions may share exposure to a common upstream provider even when they contract with different vendors.

Guidance extends concentration assessments beyond direct suppliers to the models and infrastructure on which those suppliers depend, and expects continuity and exit arrangements for material AI uses to be workable in practice. The BMA would have institutions assess concentration across common providers, cloud, hardware, foundation models, data providers and agent platforms, and weigh the feasibility and cost of fallback options, from manual processing and alternative providers to restricted functionality and rollback, when AI systems are selected, contracted for or materially changed. The FSB expects institutions to document their exposures to AI providers and the AI supply chain in AI inventories and third-party registers, to seek assurances on how providers manage their own supply chain risks and, for high-materiality, high-risk uses, to maintain exit strategies such as alternative providers or manual continuation, supported by data access and portability; it also points to joint scenario tests and sector exercises with AI providers.

Beyond the individual firm, the Mills Review, an independent review commissioned by the FCA Board, describes risks from shared models and infrastructure as ecosystem-level risks that firm-level controls alone cannot fully address. It points to collective monitoring of concentration among upstream model, cloud and distribution providers and recommends that the FCA and other authorities consider a coordinated framework for responding to AI incidents that spread through shared dependencies.

Supervision of financial institutions’ third-party risk management is set to remain a critical priority throughout 2027, with several activities and deadlines already set. The European Central Bank (ECB) has asked significant institutions to submit action plans on AI-enabled cyber threats by 31 October 2026. These should include verifying that their third-party risk management is fit for purpose, given the role of ICT providers in critical supply chains. In its own direct supervision, the European Securities and Markets Authority (ESMA) will focus in 2027 on how credit rating agencies address third-party concentration risk and outsourcing practices, and on how benchmark administrators manage outsourcing arrangements and third-party dependencies. ESMA has also launched a common supervisory action, carried out by national authorities on a sample of crypto-asset service providers, assessing the digital operational resilience of their custody services, including dependencies on third-party providers. The exercise runs until mid-2027, with a final report due in the second half of the year. In Australia, APRA will continue to review the implementation of its operational risk standard in 2026–27, with thematic reviews of operational and technology risk management at general insurers and specialist payment providers. It will also increase its focus on how regulated entities manage risks from material service providers, including by formalising its data collection on these providers to strengthen its oversight of common dependencies.

Direct oversight of critical providers is also deepening. Following the initial designation of 19 critical ICT third-party providers in November 2025 under DORA, the European Supervisory Authorities will continue their direct examination of critical ICT providers throughout 2027, with a planned focus on cybersecurity and frontier AI models. Beyond supervision, they will also support the European Commission in preparing a potential legislative proposal under the DORA review, including advice on the criteria for designating critical providers and the powers of the lead overseer. Complementing this, the EBA will complete its thematic analysis of the provision by third parties of AI systems to the EU banking and payment sector, with a thematic report expected in mid-2027 providing insights into dependencies, including regarding advanced AI models. In the UK, the designation of Amazon Web Services, Google Cloud, Microsoft and Oracle as critical third parties in July marked the start of direct oversight of their services to the financial sector by the Bank of England, the Prudential Regulation Authority and the Financial Conduct Authority. In the US, the federal banking agencies, in a joint statement on community banks’ engagement with core service providers, stressed that they will consider providers’ transparency, contractual practices and technological capabilities when determining the nature, extent and frequency of their examinations of core providers, and indicated that they may take enforcement action against core providers, including potentially treating them as institution-affiliated parties.