One Big Idea

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.

Last week this letter asked whether the bill could be predicted at all. This week it asks something narrower and harder to unpick: whether you could leave.

Most banks stop at the first sentence, because it is the one the supplier list supports. And the list is not wrong — it is answering a different question. A supplier count does not measure concentration. It measures how many invoices you receive.

Here is the shape of it. 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 Insight · Two regulators, one short list

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. Not a warning. A decision, with a date.

Eight months later, in July 2026, the United Kingdom ran its own separate process and designated four, effective 13 July 2026. Three of the four were the same legal entities.

Hold on to the phrase legal entities, because it is doing the work. It is exactly three, and the fourth belongs to the same corporate group under a different legal entity — which is the collapse this letter is about, visible inside the designation mechanics before a bank opens its own register. An analyst estimate is a methodology you cannot inspect. A designation is a decision you can read, taken by a supervisor with access to the registers banks are obliged to maintain.

The volume underneath is measured now too. In their first annual overview of major ICT-related incidents, published 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 letter's argument, with 3,383 observations behind it.

On scale, one figure is in wide circulation and almost always quoted wrongly, including by the first draft of this letter. The top three cloud providers account for about three-quarters of cloud usage among UK financial-services firms. Read the conditions, because they matter more than the number. It comes from firms' own returns to the Bank of England and the Financial Conduct Authority in their 2024 AI survey, relayed in the Financial Stability Board's October 2025 report. 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. And it is the UK, which is not the same thing as the financial sector. Quote it as a reading of one market or do not quote it at all.

The same survey carries a figure closer to the point and almost nobody uses it: between its 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. A level is useful. A level measured twice, on the same population, by the same regulators, is better.

The Insight · A dependency with no contract

The same report carries one line that gets far less attention than any of the numbers, and deserves more: pre-trained models often involve no formal contractual relationship and nevertheless introduce third-party risk. The word often is the report's, and it is worth keeping.

Think about what that does to your 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.

And a control that returns a clean result because it had nothing to grip looks identical, on a dashboard, to a control that passed.

Framework of the Week · The Vendor Concentration Heatmap

Six layers, not a supplier list, ordered the way a request actually travels. This is the author's proposed cut, not a ratified standard — and specifically not the five-layer supply-chain framework the stability literature works from, which is a different instrument for a different purpose.

  • C1 · Model — the foundation-model family that produces the answer, and the version: a deprecation is a forced migration you did not schedule.
  • C2 · Inference and serving — who runs the model, on whose capacity, under whose terms. Rate limits decide whether failover is a plan or a sentence.
  • C3 · Cloud and region — the compute underneath, and where it sits. Name the region, then ask what the second provider runs on.
  • C4 · Data and embeddings — the vector store and the embedding model. The quietest lock-in in the stack.
  • C5 · Tooling and orchestration — the agent framework, the evaluation harness, the observability layer. Rarely inventoried as a dependency at all.
  • C6 · The exit — contractual rights, portability, and whether any of it has ever been executed.

Then the part that makes it diagnostic: score each layer twice. Ask how hard it would be to leave. Then ask, separately, what happens if it stops. Those are different questions with different answers, and the hottest cell in each column is a different layer.

The layer that would take the service down is C3 — the one boards already ask about. The layer that is hardest to leave is C4, which almost nobody puts 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 my reading of the standards landscape there is no portability standard for vector storage to carry that work across — and I will mark that as an assessment rather than a finding, because I did not establish it against a standards body's own text.

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

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

The easy version of this argument is wrong, so here is the careful one.

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 this is the sentence I got wrong first time. Article 33(1)'s pre-use assessment is general. 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 — the closest thing in Vietnamese law to a C6 clause, and 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 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, which is why the pinpoint matters to anyone who looks it up.

Note the vocabulary: Vietnamese law says business continuity, not exit. It does require that plan to be tested, at least annually, and the cloud contingency plan to be tested for readiness to substitute. 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 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. On my reading of the provider duties, a bank that brands an AI application answers as the provider even where the model is licensed from someone else; no clause says own brand in those words, so treat that as interpretation rather than a quoted trigger.

So here is the gap, and it is the argument of the whole issue. 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 instrument sets a quantitative concentration duty, and neither requires an exit from a provider to be tested.

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

Risk Note · The strongest objection, stated properly

The strongest objection to this letter is not that the evidence is thin. It is that concentration might be good for you.

Providers argue that their multi-availability-zone, multi-region engineering and their security investment far exceed what any single institution could build. At the level of one bank's own resilience, that is probably correct.

The case is usually supported by the Financial Stability Board's December 2019 report on third-party dependencies in cloud services, and I want to quote that one rather than summarise it, 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 financial institutions' use of cloud services. Both hedges are its own. Cloud adoption posed no financial-stability risk is not what it says, and rendering it that way is the same move this issue has already complained about twice.

Then read what the same report asked authorities to discuss further. Three things: the adequacy of standards and supervisory practices for outsourcing, the ability of authorities to coordinate and share information about the cloud services banks use, and standardisation for interoperability and data portability in cloud environments. That third item is C4 and C6, named by a supervisor, in 2019, inside the document the counter-case rests on. It does not prove there is no portability standard today — that is still my assessment, not a finding — but the concern was on the record as unfinished work before most banks had a model in production.

Supervisors mostly answer that it is the wrong altitude, since resilience at one institution is not stability across a system. But that is a systemic argument, and a single board cannot act on one.

So the claim narrows, deliberately, to the version that survives: multi-sourcing at the model layer does not resolve dependency at the cloud layer, and the exit has never been tested. That does not argue about availability engineering at all.

Three more honest limits. C5 is real and under-evidenced — the failure it predicts, a guardrail change altering behaviour without notice, has no documented public case this research could find. Treat it as a gap in your visibility, not an incident waiting to happen. The cloud-share figure is a UK survey, so it says nothing precise about your estate and nothing at all about Vietnam. And none of the European regime is a compliance duty for a Vietnamese bank: it applies to EU financial entities, and a duty to oversee is not personal liability for an outage — though it is worth knowing that the regime does let a member State reach members of a management body personally, where national law so provides and where they are responsible for a breach of the regulation. Both halves of that are true, and a board paper that drops either one misleads.

There is a model worth borrowing for the exit test rather than waiting to have it imposed. Under the EU's threat-led penetration testing regime, identified entities test at least every three years, on live production systems, reaching into systems outsourced to third parties — and the scoping document is approved by the management body, then validated by the supervisor. That second validation is the half that makes the board's signature consequential. A bank outside that regime can adopt the same shape voluntarily.

Take one critical function that touches AI. Name the dependency at all six layers. Where you do not know, write unknown — the honest blank is a finding, and most banks find theirs at C5.

Then trace downward. For every model you named, record what it actually runs on at the inference and cloud layers, and name the region. That single step is what turns a supplier list into a concentration measure. Then find the collapse: 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.

The full deep-dive — the two designations with their article numbers, every figure with the population it was measured on, all six layers scored on both axes, what Vietnamese law asks article by article, and the counter-case at full strength — is in The Vendor Concentration Heatmap: You Are Not Diversified.

The five-page playbook in the Frameworks library turns it into a worksheet for your own estate — the six-layer register with accountable owners, the two scoring axes, and the six-question audit with what a failing answer looks like. Free with a member sign-in.

Last week, on whether the bill can be predicted: The AI Unit-Economics Ledger — it owns cost. A switching cost that is a price is there; a switching cost that is a lock-in is here. And on whether the answer is right rather than whether you can leave: The Grounded-Knowledge Architecture.

Reply and tell me what your last AI dependency review recorded at the cloud-and-region layer. Not which providers are on the contract — what the second provider actually runs on, and in which region. In most banks that cell is blank, and the blank is the finding. I read every response. Forward this to someone who has just been told the estate is multi-vendor.

Was this forwarded to you? Subscribe to The AI Architect Letter — free, every Saturday.

No institution is named as an example anywhere in this issue, and no bank, vendor, platform or model is named or endorsed — editorial policy, because naming a bank in a piece about its vendor dependency implies a client relationship we do not claim. This is independent thought leadership, not affiliated with any current or past employer, and not a substitute for your own legal, compliance and operational-resilience review.

Minh Tran · AI Business Architect · LinkedIn · Workshops & advisory: aibusinessarchitect.ai