The Bank of England has made AI supplier concentration your problem

A bank that runs its fraud checks, its customer chat and its code review on the same model provider as its 10 biggest rivals has a problem it did not have three years ago. The Bank of England has now put it in writing. In the minutes of its Artificial Intelligence Consortium meeting of 3 June, published on 5 August, the Bank recorded a member workshop’s finding that “concentration arises from underlying characteristics of AI provision, particularly at the model and compute levels, with limited alternatives”. Raconteur surfaced that line on 3 September. It puts AI supply on the same footing as cloud: a dependency regulators can name, count and supervise.

The consortium is co-chaired by Sarah Breeden, the Bank’s deputy governor for financial stability, and David Geale of the Financial Conduct Authority (FCA). Its concentration workshop said the finding matters most where AI supports the services whose failure could threaten a firm or the wider system. Members reported relying more on software-as-a-service than on in-house hosting, and the minutes say SaaS “may increase third-party dependency and reduce substitutability”. The workshop asked for a shared understanding of firms’ relationships with third-party AI providers. That is regulator language for a register.

The Bank has already shown what it does with a dependency it can name. On 10 July, HM Treasury designated the European and UK entities of Amazon Web Services, Google Cloud, Microsoft and Oracle as the first critical third parties to the UK financial sector, and the Bank, the Prudential Regulation Authority (PRA) and the FCA began overseeing them on 13 July. The Bank’s release gives the logic: because many firms rely on the same services, one disruption could hit multiple firms or markets at once. Breeden said in the release: “As critical third parties become increasingly embedded in the operations of financial institutions, they can introduce new forms of systemic risk.”

Here is my argument. Model and compute providers are not designated critical third parties, and may never be. That does not matter to a managed service provider or systems integrator selling into a bank, an insurer or a building society. Regulated firms do not absorb a new supervisory concern by writing a policy. They push it down the supply chain as a questionnaire, as EU firms have done under the Digital Operational Resilience Act (DORA) and UK firms under the critical third parties rules in force since 1 January 2025. The next one you receive will ask about AI, in the language of the Bank’s minutes: which models, which compute and what happens when they stop.

The adoption numbers make it certain

The Cambridge Centre for Alternative Finance’s 2026 Global AI in Financial Services Report, published on 28 April and based on 628 respondent organizations across 151 jurisdictions, found that 81% of financial services firms are adopting AI at some level and 40% report advanced adoption. Only 14% see AI as transformational. The same report found that 63% of industry respondents build internal workflows on external foundation models. Most firms are using AI, most of those are using someone else’s model and few have a board-level view of what it is for. That is a client whose AI dependencies arrived inside managed services, one contract at a time, and have never been mapped as a set.

An MSP that has switched on an AI assistant inside a client’s service desk, a summarizer inside its backup tooling or a copilot inside a security operations center has created exactly the dependency the consortium describes, one step removed from the bank’s own risk team.

What the questionnaire will ask

The template already exists. The PRA’s policy statement on critical third parties, PS16/24, requires a designated provider to map the resources behind its services, oversee its own supply chain, plan for the termination of a service, test its ability to keep running through severe but plausible disruption, notify incidents in phases and file an annual self-assessment whose summary goes to customer firms. A bank that has learned those words from its cloud providers will use them on everyone else. Have six things ready.

• A model and provider inventory. Every AI feature in every service you deliver, with the model, the version, where it is hosted, whether you buy it direct or through a distributor or marketplace, and which client business services it touches.
• A fourth-party map. The AI inside your remote monitoring, ticketing and security tools comes from your vendors’ providers. The client will not accept ‘ask the vendor’ as an answer.
• An exit plan for each dependency. Not a paragraph saying you would switch, but the steps, the time, the data that moves and the cost.
• Substitutability evidence. The consortium’s workshop found alternatives are limited. Show that yours are not: a second model you have tested against the same workload, with the results.
• Incident terms. What you tell the client, and how quickly, when a model provider degrades, retires a version or withdraws a capability.
• A named owner. The minutes say governance and operational oversight matter as much as engineering. A question about who is accountable for AI risk should get a name, not a committee.

Concentration is also your commercial risk

There is a second reason. The consortium’s finding describes your own supply position. If your AI features sit on one model provider and one cloud, you carry the same limited alternatives as the banks, with less bargaining power and no regulator to speak up for you. Substitutability is not a compliance artifact. It is the difference between a price rise you can walk away from and one you have to pass on.

The Bank has written it into its minutes: the AI supply chain is now a financial stability matter. Regulated clients will hand the question to their suppliers. The providers that answer with an inventory, an exit plan and a tested alternative will keep their financial services contracts. The rest will find that ‘we use the best model’ was never a resilience statement.