AI vendor concentration is a financial-stability risk
The FSB's AI warning is about shared providers, not one bad model. Map common model, cloud, hardware and data dependencies—and prove another path can carry the service.
Andrew Bailey's August 28 letter did not warn that one bank might choose a bad model. It warned that a cyber shock could travel across institutions and borders through common technology providers, shared infrastructure and concentrated third parties.
That changes the architecture review. Vendor count is not the measure. The measure is how many critical services terminate in the same underlying model, cloud, hardware or data path—and whether another path can actually carry the load.
The category predates the warning
Bailey wrote the letter as chair of the Financial Stability Board, to G20 finance ministers and central-bank governors. That attribution matters. This was not a Bank of England note about one institution's technology policy; it was a warning about disruption spreading through a connected financial system.
The August letter calls frontier AI's effect on cyber risk the immediate concern. It says greater speed, scale and changed attack economics could undermine confidence system-wide, especially where many firms depend on highly concentrated providers. The response it asks for is equally systemic: prepare for simultaneous disruption across firms or shared technology dependencies, and strengthen recovery—including restoration of critical systems and data from bare metal.
Vendor concentration was not invented in August. The FSB's 2024 AI report had already named third-party dependencies and service-provider concentration as one of four AI-related vulnerabilities with systemic potential. The 2026 move is escalation: an established category now sits inside the chair's immediate frontier-AI cyber warning to the G20.
That is a stronger claim than “regulators noticed vendors”. It is also narrower than a new rule. The letter creates no firm-level threshold, diversification mandate or questionnaire.
Two contracts can still be one dependency
A model register can show two suppliers and still hide one failure path.
The alternative model may run in the same cloud region. Two application vendors may call the same pretrained model. Separate clouds may depend on the same accelerated-computing supply, identity service or data source. A fallback endpoint may share the gateway and state store that the primary endpoint needs to recover.
The archive's earlier open-model serving note made the firm-level version of this point: weights do not guarantee a portable serving path. The financial-stability version changes the unit of analysis. It asks which common dependency can interrupt multiple critical services or institutions at once.
Counting contracts answers procurement. Aggregating common dependencies answers blast radius.
Count the topology, not the contracts
The FSB's 2025 monitoring report is unusually practical here. Its indicators cover critical services, direct and nth-party providers, closely connected suppliers, switching time and cost, alternative providers, vertical integration and recovery plans.
Turn those categories into one dependency record for every critical AI-enabled service:
- Name the business service and the maximum tolerable interruption.
- Trace the direct and nth-party path across model, cloud, hardware and data.
- Aggregate every service that converges on the same or closely connected provider.
- Record switch time, switching cost, spare capacity and capability lost on the second path.
- Attach the latest failover and recovery evidence—not a link to an untested runbook.
Do not stop at the vendor your team pays. The FSB gives the useful example: a firm can have indirect chip-supplier exposure through its cloud provider. The dependency exists even when there is no direct contract to count.
A fallback is evidence, not inventory
Pick the critical service with the largest aggregated blast radius. In staging, remove its primary AI-provider path and replay a retained workload through the alternative. Measure time to acceptable service, manual work introduced, capacity available and controls lost. A second vendor counts as diversification only if the switch removes the common failure dependency and the remaining path carries the required load.
This is not an argument for reflexively buying two of everything. The 2024 report notes that synergies with one provider can improve risk-management efficiency and overall resilience. Extra providers add integration, monitoring and recovery surfaces of their own. The decision should follow criticality and substitutability, not a round vendor-count target.
For this historical repair, I read the full chair's letter and the relevant FSB monitoring reports. I did not inspect a bank's architecture or run the failover drill above. The dependency record and test are my operating recommendation, not an FSB requirement or a measured deployment result.
If your second path ends at the same support column, you have two contracts and one failure domain.
