The Vendor Concentration Heatmap: You Are Not Diversified

Your AI estate has three vendors. It may have one dependency.

Both of those sentences can be true at once, and the gap between them is where the next outage lives.

This is not a theoretical concern a prudent board should keep an eye on. In the space of eight months, two financial regulators ran separate processes, applied different criteria, examined the concentration in their own markets, and arrived at substantially the same short list. That convergence is the most useful piece of evidence a bank board has been handed on this subject, and almost nobody has put it in front of one.

Why this matters now

On 18 November 2025, the European Supervisory Authorities published the list of nineteen technology providers designated as critical ICT third parties to the financial system, under Articles 31(1) and 31(9) of the EU's operational resilience regulation. It includes the three large cloud providers, alongside infrastructure, data and professional-services firms.

In July 2026, the United Kingdom designated four critical third parties under its own regime, effective 13 July 2026. Three of the four were the same legal entities the European authorities had already named.

Hold on to the phrase legal entities, because it is carrying the argument rather than decorating it. It is exactly three, not four, and the fourth is not a miss — it belongs to the same corporate group as a designated entity, under a different legal entity. A looser sentence would have said the same companies and been wrong about the fourth; a sloppier one would have said all four. The regime itself makes the same distinction: it designates entities while assessing the services provided by the group as a whole. The collapse this article is about is visible inside the designation mechanics before a bank even opens its own register.

The volume underneath those designations is measured now too. In their first annual overview of major ICT-related incidents, published on 3 June 2026, the European supervisory authorities recorded 3,383 major incidents reported by financial entities in the EU for 2025 — 0.18 per entity in scope — and named system failures and external events as the main drivers, highlighting the need for robust third-party risk management. That is a supervisor stating this article's argument, with 3,383 observations behind it.

Note what a designation is and what it is not. It is not a market-share estimate. An analyst estimate is a methodology you cannot inspect, produced on a population you usually cannot see. A designation is a decision, with a date, taken by a supervisor who had access to the registers of information financial entities are obliged to maintain. Two such processes converging is about as close to measurement as this subject gets.

Start with the part that is true

Multi-vendor is real at the top of the stack. Most large banks now run more than one foundation model, and multi-cloud is common enough among large financial entities that supervisors treat it as the norm rather than the exception. That characterisation is this article's own, drawn from how supervisors write about the market rather than from a single document that says it, and it is marked as such in the table below.

That architecture was deliberate and sensible, and the boards that asked for it were right to. The problem is not that the diversification is fake. The problem is that it is real at exactly one layer, and the question nobody asked is what it resolves to underneath.

What a supplier count does not measure

A supplier count measures how many invoices you receive. It does not measure concentration.

Consider the common case. Two model providers, chosen carefully, for genuine redundancy. Both served through the same cloud. In the same region. On the same accelerator family. That is one dependency wearing two logos, and the board was told the estate is multi-vendor, which was true at the layer the board could see.

The Financial Stability Board put a sharper version of this in its October 2025 report on AI adoption and vulnerabilities in the financial sector. It describes an AI supply chain of five layers, on a framework it credits to Bank for International Settlements research rather than claiming as its own, and finds concentration in each of the first four in differing degrees: specialised hardware most of all, then computing infrastructure, training data and pre-trained models. The fifth layer, user-facing applications, it expressly describes as exhibiting heterogeneous degrees of concentration depending on the application domain. The graded finding is stronger than a uniform one would be, and it is worth quoting as graded. The six-layer heatmap below is this article's own cut, built for a bank's register rather than for a stability report, and the two should not be confused.

The same report relays a supervisory survey finding on scale, and the conditions on that figure matter more than the number does.

The top three cloud providers account for about three-quarters of cloud usage among UK financial-services firms. That reading comes from firms' own returns to the Bank of England and the Financial Conduct Authority in their 2024 AI survey, which asks firms to name their top three providers of cloud services, models and data. So it is a supervisory survey run by two financial regulators over their own regulated population — not analyst analysis, and not a market-share measurement, and not a census. It is also the UK, which is not the financial sector. Both halves of that have to travel with the figure: a bank that quotes it as a global sector share has overstated its geography, and a bank that dismisses it as an analyst estimate has understated its authority.

The same survey carries a figure that is closer to this article's thesis and gets almost no circulation. Between the 2022 and 2024 rounds, the share of named providers accounted for by the top three model providers rose from eighteen percent to forty-four percent. That is a concentration reading on the model layer — C1 below — measured twice, on the same population, by the same regulators. A level is useful. A level measured twice is better.

And the report contains a finding that gets far less attention than any of the numbers. Pre-trained models often involve no formal contractual relationship and nevertheless introduce third-party risk. The word often is the report's and is kept here. Think about what that does to a bank's controls. A third-party risk framework begins by asking for the contract. At the model layer there may not be one. The framework does not fail loudly — it finds nothing, reports nothing, and the dependency stays invisible. A control that returns a clean result because it had nothing to grip looks identical, on a dashboard, to a control that passed.

The Vendor Concentration Heatmap

So count layers, not suppliers. Six of them, ordered the way a request actually travels.

C1 · Model

Which foundation-model family actually produces the answer, and whether two vendors means two independent models or two wrappers over one.

The dependency here is not only the vendor but the version: a deprecation is a forced migration you did not schedule. And per the finding above, this is the layer where contract-based controls may have nothing to grip.

C2 · Inference and serving

Who runs the model, on whose capacity, under whose terms — a first-party interface, a cloud provider's hosted version, or self-hosted.

This is where "we have a second provider" most often stops being true, because rate limits and capacity commitments decide whether failover is a plan or a sentence.

C3 · Cloud and region

The compute underneath, and where it physically sits.

This layer does not hide. It simply sits one layer below where the diversification was counted. It is where multi-vendor at C1 collapses, and it carries the highest consequence if it stops. Name the region, not just the provider — then ask what the second provider runs on.

C4 · Data and embeddings

The vector store and the embedding model your retrieval depends on. The quietest lock-in in the stack, and the one least often on an agenda.

To change the model that turns your documents into vectors, you do not change a setting. You re-embed the entire corpus. Then you re-validate every retrieval result that depended on the old one. On this author's reading of the standards landscape there is no portability standard for vector storage to carry that work across, which is an assessment rather than a sourced finding and is marked as one below. The underlying concern is not this article's invention, though: back in December 2019 the Financial Stability Board itself listed interoperability and data portability in cloud environments among the things authorities might usefully discuss further — the source is quoted in full in the counter-case section, because it is the same document the providers' argument rests on.

Be precise about the claim, because precision is what lets it survive a challenge. C4 is not the most expensive layer in cash terms. It is the layer with the highest architectural friction — the hardest to unpick. And the friction compounds with the size of the corpus, which means the cheapest day to deal with it was always earlier than today.

C5 · Tooling and orchestration

The agent framework, the evaluation harness, the observability layer — the components that encode how everything else is wired together, and which are rarely inventoried as dependencies at all.

An honest caveat, stated here rather than in a footnote. This layer is real and under-evidenced. The specific failure it predicts — a guardrail or safety-filter change altering system behaviour without notice — has no documented case in the public record that this research could find. Treat C5 as a gap in your own visibility rather than as a demonstrated incident. The first control is simply putting it in the register.

C6 · The exit

Contractual exit and step-in rights, data and model portability, and whether any of it has ever been executed.

This layer does not hide either. It is simply never tested, so the document and the capability are never compared. The United Kingdom's competition authority concluded a cloud services market investigation with a final decision on 31 July 2025 and found that switching and multi-cloud adoption are limited by technical and commercial barriers. Both words matter: this is not purely an engineering problem, and procurement alone cannot solve it.

Score it twice, not once

Here is where a single ranking misleads you. Ask how hard a layer would be to leave. Then ask, separately, what happens if it stops. Those are different questions with different answers, and the hottest cells sit in different rows.

The layer that would take the service down is C3. The layer that is hardest to leave is C4. A board that only asks one question gets one of those answers, and it is usually the wrong one for planning purposes, because C3 is the one everyone already worries about.

The exit, and the question that settles it

C6 is binary, not scored. You either have tested leaving, or you have a document.

There is a model for doing this properly, and it is worth borrowing rather than waiting to have it imposed. Under the EU's threat-led penetration testing regime, identified entities test at least every three years; the testing runs on live production systems; it reaches into systems outsourced to third-party providers; and — the provision that matters most for a board — the scoping document is approved by the management body.

That last provision is worth locating accurately, because it is not where a summary would put it. The three-year cycle, the live-production requirement and the reach into outsourced systems are in Articles 26 and 27 of the regulation. The management-body approval is in the regulatory technical standard on threat-led penetration testing, adopted as a delegated regulation — a different instrument class from an implementing standard, which the regime distinguishes. The same regime then has the competent authority validate that scope, which is the half that makes the board's signature consequential: a board signs a scope that a supervisor will read.

A bank outside that regime can adopt the same shape voluntarily. The board signs the scope. The test runs on the real thing. And it does not stop at the edge of what you operate yourself.

What Vietnamese law already asks, and the one question it does not

Here the article has to be careful, because the easy version of this argument is wrong.

The EU regime does not bind a Vietnamese commercial bank. It applies to EU financial entities. A Vietnamese bank is in scope only through an EU entity with financial-entity status, or contractually through EU counterparties. Anyone telling a Vietnamese board that European rules make its directors personally liable for an outage is overstating, and the correction is worth getting exactly right rather than merely getting. The regime extends administrative penalties, applied by a supervisor, through national transposition, with no ceiling set at EU level — and it does let a member State reach members of the management body personally, where national law so provides and where they are responsible for a breach of the regulation. A duty to oversee is not personal liability for an outage. Those two sentences are both true, and dropping either one produces a misleading board paper.

What does bind is closer to home, and more useful.

Under Circular 09/2020/TT-NHNN, in force since 1 January 2021, cloud is not prohibited — systems at level three and above may go to cloud where the safety requirements are met — and the institution must complete a risk assessment before use. The filing duty is narrower than it is usually described, and the distinction is load-bearing. Article 33(1)'s pre-use assessment is general to third-party services for level-3-and-above systems and systems processing customers' personal data. Article 33(3) adds the duty to send that assessment to the State Bank only where the institution outsources the entire system-administration work of such a system. Cloud use on its own does not put a report on the regulator's desk. Article 35 of the same circular governs the third-party contract, data ownership and the return of data on termination, which is the closest thing in Vietnamese law to a C6 clause and is worth reading before the next renewal.

Under Circular 13/2018/TT-NHNN, Article 43 governs operational risk arising from outsourcing. It works by reference: it applies Article 42's identify-measure-monitor-control duty to outsourcing-arising risk, and it requires the Article 46 business-continuity plan, prepared either by the bank itself or by the vendor. Article 42 standing alone is the general operational-risk article and does not mention outsourcing at all, which is why the pinpoint matters to a reader who looks it up.

Note the vocabulary: Vietnamese law says business continuity, not exit. And it does require that plan to be tested, at least annually, with the cloud contingency plan tested for readiness to substitute for the activities running on it. What no Vietnamese instrument requires is that you test actually leaving a provider. A tested failover inside a provider is precisely not a tested exit from one, and conflating the two is how a bank concludes it has already done this work.

And under the AI Law 134/2025/QH15, in force from 1 March 2026 under Article 34, duties split between provider and deployer at Articles 11 to 14. The eighteen-month transition to 1 September 2027 is Article 35(1)(a), and it reaches only finance-sector systems already in operation before 1 March 2026 — a runway for what is already running, not a sector-wide holiday for what you build next. This is the fourth time this series has had to say it, so it is worth saying flatly: the condition is the first clause of the provision, not a gloss on it.

On the reading this article takes of the provider duties, a bank that puts its own brand on an AI application answers as a provider, even where the core model is licensed from someone else. No clause says own brand in those words, so read that as an interpretation of Articles 11, 12 and 14 rather than a quoted trigger. That is the Vietnamese liability hook, and it does not need European law to work.

So here is the gap, and it is the argument of this whole piece. The bank already runs a risk assessment before it goes live, and files it where the whole system is in someone else's hands. That assessment asks whether the provider is competent. It does not ask what the provider sits on, or whether anyone has ever tried to leave. Neither Vietnamese instrument sets a quantitative concentration duty, and neither requires an exit from a provider to be tested — however often the continuity plan inside one is.

This is not a compliance failure. It is a question the paperwork does not reach.

Where this argument does not hold

Stated at full strength, because an argument that has not been tested against its strongest opposition is an assertion.

The case for concentration is real. Providers argue that their multi-availability-zone, multi-region engineering and their security investment far exceed what a single institution could build. At the level of one bank's own resilience, that is probably correct. Concentrating on a large provider very likely raises availability rather than lowering it.

That case is usually supported by the Financial Stability Board's own December 2019 report on third-party dependencies in cloud services, and that report is worth quoting precisely rather than summarising, because the summary in circulation is stronger than the text. The board concluded that there do not appear to be immediate financial-stability risks stemming from the use of cloud services by financial institutions. Read the two hedges: do not appear to be, and immediate. That is a qualified reading of the position as at December 2019, not a clean bill of health, and anyone who renders it as cloud adoption posed no financial-stability risk has done to this source exactly what the cloud-share figure above had done to it — quoted a real finding outside the conditions it was measured under.

And the counter-case's best source argues this article's own case in its next breath. Having reached that conclusion, the same report said there may be merit in further discussion among authorities to assess three things: the adequacy of regulatory standards and supervisory practices for outsourcing arrangements, the ability of authorities to coordinate, cooperate and share information about the cloud services financial institutions use, and — the third one — the current standardisation efforts to ensure interoperability and data portability in cloud environments.

That third item is C4 and C6, named by a supervisor, in 2019, inside the document the providers' argument rests on. It does not establish that no portability standard exists today; that remains this article's assessment and is marked as one. What it does establish is that the concern is not a vendor-sceptic's invention. It was on the record, as unfinished work, before most banks had a model in production at all.

Supervisors do not actually dispute the engineering. Their answer is that it is the wrong altitude: resilience at one institution is not stability across a system, and shared dependency creates a blast radius that a distributed estate does not have. But that is a systemic argument, and a systemic argument is not something a single board can act on.

So the claim here must narrow, and it does. This article does not argue that concentration is less resilient. It argues something smaller and harder to dismiss:

Multi-sourcing at the model layer does not resolve dependency at the cloud layer, and the exit has never been tested.

That survives the counter-case intact, because it does not argue about availability engineering at all. It argues about what you can still do when the decision is no longer yours.

A heatmap you can fill in this week

1. List the critical functions that touch AI. Functions, not systems — the unit that matters is a service a customer would notice stopping.
2. Name the dependency at all six layers, for each function. Where you do not know, write unknown. The honest blank is a finding, and most banks find theirs at C5.
3. Trace downward. For every model named, record what it actually runs on at the inference and cloud layers, and name the region. This is the step that turns a supplier list into a concentration measure.
4. Score the two axes — friction to leave, consequence if it stops.
5. Find the collapse. Identify every place where two or more apparently independent choices at the top resolve to one thing underneath. That convergence is the heat. When two choices collapse, leaders should treat them as a single supplier — in the register, in the contract, and in the recovery plan.
6. Pick one exit and test it. One function, one layer, on production, with the board approving the scope. The purpose is not to leave. It is to find out what the plan did not say.

Risks and caveats

The cloud-share figure is a UK survey, not your figure. Three providers accounting for about three-quarters of cloud usage is what UK firms reported to their own regulators in 2024. It says nothing precise about your own estate, and nothing at all about Vietnam. Do not put it in a board paper as if it did.

C5 is under-evidenced, as stated above. Present it as a visibility gap, not as an incident waiting to happen.

One claim here is an assessment rather than a finding. The absence of a portability standard for vector storage is a negative statement about a standards landscape, and this article did not establish it against a standards body's own text. It is the author's reading, and the practical point survives either way: the re-embedding and re-validation work does not transfer, whatever any future standard says.

The six layers are not the only possible cut. An accelerator-supply layer beneath C3, and a people-and-integrator layer, are both arguable. Six is what the evidence supported, and the five-layer supply-chain framework in the stability literature is a different instrument for a different purpose.

No single ordering of the six layers is offered, because the evidence did not produce one and a single ordering would hide the two-axis finding.

This is a template and a trajectory, not a duty. Anyone who tells you otherwise about the EU regime and a Vietnamese bank has not read the scope provisions.

Key takeaways

• A supplier count is not a concentration measure. It measures how many invoices you receive.
• Two regulators independently designated substantially the same providers critical, in November 2025 and July 2026, and three of the four UK designations were the same legal entities as EU ones. Use that in place of market-share estimates.
• Multi-vendor is the normal condition of a concentrated market, not an escape from one.
• The cloud-concentration figure is a UK supervisory survey of firms' own returns, from 2024 — authoritative on its population and silent about yours. On the model layer, the same survey's top-three share rose from eighteen to forty-four percent between its 2022 and 2024 rounds.
• A pre-trained model often carries third-party risk with no formal contract, so a framework that starts with the contract finds nothing and reports nothing.
• Score each layer twice. C3 carries the highest consequence; C4 carries the highest friction. They are not the same layer.
• C4 is about architecture, not price. Changing an embedding model means re-embedding and re-validating the whole corpus.
• The exit is binary. Tested, or a document.
• For a Vietnamese bank, the binding duty is the AI Law's provider-versus-deployer split at Articles 11 to 14, not European law. The pre-use risk assessment you already run does not ask the concentration question, and the filing duty attaches only where the whole system's administration is outsourced.

Figures in this article, and where each one comes from

Every figure in this article is attributed to the body that published it, with its measurement scope stated. No institution is named as an example anywhere in this piece, by editorial policy: naming a bank in an article about its vendor dependency implies a client relationship we do not claim.

Deliberately absent. This article carries no named cloud provider, no named designated entity, no named model, no named bank, and no quantitative concentration threshold. Every primary source behind it is full of names — the European designation list names nineteen legal entities, the stability report names chip, cloud and model firms in its footnotes, the UK designation names four — and none was imported. There is also no statutory-instrument number for the UK designation and no paragraph number for the technical standard's management-body provision. Each was available to this piece in summary form; each was excluded because the source itself was not read. A figure that cannot carry its conditions does not appear — and where a source has since been read, as the December 2019 report was, it is quoted with its own hedges rather than with the stronger version in circulation.

Where this sits next to the rest of the series: The Grounded-Knowledge Architecture owns whether the answer is right, where this piece owns whether you can leave. The Build-Buy-Partner Grid owns the sourcing decision and the systemic-risk argument. The AI Unit-Economics Ledger owns cost — a switching cost that is a price is there; a switching cost that is a lock-in is here. And AI-Ready Business Architecture, the 5-Layer Data-Readiness Map, owns the data layers themselves, which is what C4 leans on.

No customer, employee or institution-level data of any kind appears in this article; no bank, vendor, platform or model is named or endorsed; and the six-layer heatmap is the author's proposed decomposition rather than a ratified standard. This is independent thought leadership, not affiliated with any current or past employer, prepared in line with Vietnam's AI Law 134/2025 and the personal-data regime, and not a substitute for your own legal, compliance, operational-resilience and data-protection review.