Free executive playbook.

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. The reason the gap survives review is that the supplier list is not wrong — it is answering a different question. A supplier count does not measure concentration. It measures how many invoices you receive. The evidence that this is now measurable rather than arguable arrived in two pieces eight months apart. 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. In July 2026 the United Kingdom designated four critical third parties under its own regime, effective 13 July 2026, and three of the four were the same legal entities the European authorities had already named. Read that precisely, because the precision is the argument: legal entities, not companies — the fourth belongs to the same corporate group under a different legal entity, which is exactly the collapse this framework is about, visible inside the designation mechanics themselves. Two supervisors, separate processes, different criteria, substantially one short list. That 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 with access to the registers of information financial entities are obliged to maintain. The Vendor Concentration Heatmap turns that into something a board can fill in: six layers, scored on two axes, with the trace-downward step that converts a supplier list into a concentration measure. It is the author's proposed cut, not a ratified standard, and not the five-layer supply-chain framework the Financial Stability Board works from.

What's inside

  • The reframe — a supplier count against a layer trace, compared across the four rows that decide whether a board heard the truth: the unit measured (contracts, invoices and vendor names · against dependencies, and where two of them become one) · the typical answer ("Three vendors. We are multi-sourced." · against "Three at the model layer. One underneath.") · what each one misses (that two model providers can be served through the same cloud, in the same region, on the same accelerator family · against nothing structural, though it takes work and the honest answer is often unknown) · and where each one collapses (it cannot collapse, because it never looked down · against the cloud-and-region layer, usually). The case is ordinary rather than exotic: 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 six-layer register — the page you fill in, with what each layer is, why it hides, and an accountable owner. 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 is the version as much as the vendor, because a deprecation is a forced migration you did not schedule) · 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; it does not hide, it simply sits one layer below where the diversification was counted — 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) · C5 · Tooling and orchestration (the agent framework, the evaluation harness, the observability layer — what encodes how everything else is wired, and rarely inventoried as a dependency at all) · C6 · The exit (contractual exit and step-in rights, data and model portability, and whether any of it has ever been executed; it does not hide either — it is simply never tested, so the document and the capability are never compared) · plus the trace-downward step that turns a list into a measure: for every model named at C1, record what it actually runs on at C2 and C3, name the region, then find every place where two or more apparently independent choices at the top resolve to one thing underneath. That convergence is the heat. Everything else on the page is context for it
  • Two axes, not one — because a single ranking merges two questions with different answers. Ask how hard a layer would be to leave. Then ask, separately, what happens if it stops. C1 moderate friction, moderate consequence (usually degradation) · C2 moderate friction, high consequence · C3 high friction, highest consequence · C4 highest friction, moderate consequence · C5 high friction, moderate consequence · C6 is the friction, and determines every other consequence. The finding the two axes produce is the one a single heat column destroys: the layer that would take the service down is C3; the layer that is hardest to leave is C4, and a board that asks one question gets one of those answers — usually C3, because C3 is the one everyone already worries about. Why C4 is hardest is an architecture claim, not a price claim, and the distinction is what lets it survive a challenge: to change the model that turns your documents into vectors you do not change a setting, you re-embed the entire corpus and then 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 — an assessment rather than a sourced finding, and stated as one. C4 is not the most expensive layer in cash terms. It is the one with the highest architectural friction, and the friction compounds with the size of the corpus, which means the cheapest day to deal with it was always earlier than today
  • What Vietnamese law already asks, and the one question it does not. 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: Article 33(3) attaches it to outsourcing the entire system-administration work of such a system, so cloud use on its own does not put a report on the State Bank's desk, while Article 33(1)'s pre-use assessment applies generally. Article 35 of the same circular governs the third-party contract, data ownership and the return of data on termination, which is the nearest thing in Vietnamese law to a C6 clause. Under Circular 13/2018/TT-NHNN, Article 43 governs operational risk arising from outsourcing — applying Article 42's identify-measure-monitor-control duty to it, and requiring the Article 46 business-continuity plan, prepared either by the bank itself or by the vendor. 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. What no Vietnamese instrument requires is that you test actually leaving a provider. And under the AI Law 134/2025/QH15, in force from 1 March 2026 (Article 34), duties split between provider and deployer at Articles 11 to 14. Its eighteen-month transition to 1 September 2027 sits at Article 35(1)(a) and 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 the reading this playbook 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 it as an interpretation rather than a quoted trigger. The gap is the whole point. 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
  • The audit — six questions, one afternoon, each paired with what a failing answer actually looks like, so the output is a list of the layers your institution cannot currently see rather than a score. Which critical functions touch AI (failing: a list of systems, not services a customer would notice stopping) · what runs at all six layers (failing: four layers named and two silently skipped, rather than written unknown) · what each model runs on, in which region (failing: "it's multi-cloud" — name the region, or it is not an answer) · scored on both axes (failing: one heat column, two questions merged into the one everybody already asks) · where independent choices collapse (failing: "we have three vendors", offered as an answer about dependency) · and which exit has been tested, on production (failing: a contract clause, a runbook, a tabletop — none of those is a test) · then the rule that makes the register bite: when two choices collapse, leaders should treat them as a single supplier — in the register, in the contract, and in the recovery plan. There is a model worth borrowing for the last question 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 scoping document is approved by the management body — then validated by the supervisor, which is the half that makes the board's signature consequential. 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

Five pages · free with a member sign-in · PDF.

Three honest limits are carried in the downloadable edition as well as here, because they bound what the heatmap can claim. Where this framework does not hold: providers argue that their multi-availability-zone, multi-region engineering and their security investment far exceed what any single institution could build, and 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. The case is usually supported by the Financial Stability Board's December 2019 report on third-party dependencies in cloud services, which is worth quoting rather than summarising: 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 the board's, and the stronger rendering in circulation — that cloud adoption posed no financial-stability risk — overstates a qualified 2019 position. Note also what the same report asked authorities to discuss further, because the third of its three items is standardisation for interoperability and data portability in cloud environments: the providers' best-cited source put C4 and C6 on the record as unfinished work. Supervisors do not dispute the engineering; their answer is that it is the wrong altitude, because 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 the counter-case intact: multi-sourcing at C1 does not resolve dependency at C2 or C3, and the exit has never been tested. That does not argue about availability engineering at all. On C5: 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 it as a gap in your own visibility rather than a demonstrated incident; the first control is simply putting it in the register. And on the cloud-share figure: three providers accounting for about three-quarters of cloud usage is what UK financial-services firms reported in their own returns to the Bank of England and the Financial Conduct Authority in those regulators' 2024 AI survey, relayed in the Financial Stability Board's October 2025 report. It is a supervisory survey by two financial regulators rather than analyst analysis, and a reading of one market rather than a market-share measurement or a census. It says nothing precise about your estate and nothing at all about Vietnam, and should not go into a board paper as if it did.

What is deliberately not in this playbook. No claim that the EU regime binds a Vietnamese bank, or that it creates personal director liability for an outage — a duty to oversee is neither, even though the European 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. No quantitative concentration threshold, because neither Vietnamese instrument sets one. No single ordering of the six layers, because the evidence did not produce one and an ordering would hide the two-axis finding. No accelerator-supply layer beneath C3 and no people-and-integrator layer, both of which are arguable; six is what the evidence supported. No article number that was not read off the instrument. No institution is named as an example anywhere in it, 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, and the primary sources behind this week's evidence are full of names that were deliberately not imported.

Want the weekly version? Subscribe to The AI Architect Letter · Read the full analysis · Read the latest insights.