AI · Systems

Model Risk Has Become an Infrastructure Problem

Holding the expected number of failures fixed, shared dependency on one provider moves the probability that a twentieth of a system fails at once from effectively zero to about two per cent. The mean is unchanged by construction; only the tail moves.

Issue date
Last revised
Simultaneous-failure probability against shared provider dependencySimulated probability that at least 5 or at least 15 per cent of a 400-firm system fails in the same period, plotted against the share of firms depending on a common provider from zero to one hundred per cent. Solid lines show the shared-dependency system and rise steeply with the share; dashed lines show an independent system with the same expected number of failures and stay close to zero throughout.Scenario: what shared dependency does to a tail200,000 periods per point, seed 202510010.0%0.5%1.0%1.5%2.0%PROBABILITY IN A GIVEN PERIOD0%20%40%60%80%100%SHARE OF FIRMS DEPENDING ON THE COMMON PROVIDERabove a 15% share, one provider event alonebreaches both thresholds, so the solid lines coincide5% of firms fail together, shared dependency5% of firms fail, same mean, independent15% of firms fail together, shared dependency15% of firms fail, same mean, independentThe expected number of failures is the same on every line. Only the tail moves.Firm-level controls do not aggregate to system-level safety under shared dependency.
Simultaneous-failure probability against shared provider dependencySimulated probability that at least 5 or at least 15 per cent of a 400-firm system fails in the same period, plotted against the share of firms depending on a common provider from zero to one hundred per cent. Solid lines show the shared-dependency system and rise steeply with the share; dashed lines show an independent system with the same expected number of failures and stay close to zero throughout.Scenario: shared dependency0.0%0.5%1.0%1.5%2.0%PROBABILITY IN A GIVEN PERIOD0%20%40%60%80%100%SHARE OF FIRMS DEPENDING ON THE COMMON PROVIDER5% together, shared5% together, independent15% together, shared15% together, independentExpected failures are the same on every line.Only the tail moves.
Figure 1 · The same average, a different tail There is no public dataset of which firms depend on which model, data and cloud providers, so this figure does not draw one. It asks the question that can be answered: given shared dependency, what happens to the tail? The expected number of failures is held identical across every pair of lines by construction, so the gap between solid and dashed is entirely the effect of correlation. This is a scenario with stated parameters, not an estimate of any real system's exposure. Source: Simulated. No market or vendor data is used in this figure. Notes: 400 firms; independent per-firm failure probability 0.004 per period; common provider failure probability 0.02 per period, drawn once per period and applied to every dependent firm; 200,000 simulated periods per point; NumPy PCG64 seeded with 20251001. The independent benchmark is a binomial draw calibrated to the same mean failure rate as the shared-dependency system at that share, so the two differ only in correlation. Parameters are assumptions chosen to be legible, not estimates.

Take four hundred firms, each with a well-run model-risk function, each failing independently about four times in a thousand periods. Now let half of them depend on one common provider that fails twice in a hundred periods. Hold the expected number of failures fixed. Under those assumptions, the probability that at least five per cent of the system fails in the same period is 2.0 per cent with the shared dependency, and did not occur once in 200,000 simulated periods without it.

That is the whole argument, and Figure 1 is its arithmetic. The mean is identical along every pair of lines by construction. Only the tail moves.

Section 01Four vulnerabilities, one theme

In November 2024 the Financial Stability Board identified four AI-related vulnerabilities with potential financial-stability implications: third-party dependencies and provider concentration, market correlations arising from common models, cyber and fraud exposure, and issues of model quality and explainability. None of the four is about whether a model is clever. Each is about what happens when many firms quietly come to depend on the same components.

Conventional model-risk management begins and ends inside the institution: specify the model, challenge its assumptions, validate its data, control its use. That discipline estimates whether a model is fit for a firm's purpose. It is silent on whether the same error can arrive at many firms at once, because it never leaves the firm.

Section 02What shared dependency does to a tail

There is no public dataset of which financial firms depend on which model, data and cloud providers. Drawing a network diagram out of invented firms would look empirical and be nothing of the kind, so Figure 1 does not attempt it. It asks the question that can be answered from assumptions alone: given shared dependency, what happens to the distribution of simultaneous failures?

The construction matters more than the numbers. For each level of shared dependency, the simulation computes the expected failure rate and then draws a comparison system with that same expected rate and no correlation at all. The two systems have identical means by design. Everything separating the solid lines from the dashed ones is correlation.

The result has a threshold quality that is worth noticing. Once the common-provider share passes roughly the failure threshold being measured, a single provider event alone breaches it, and the probability of a simultaneous failure stops depending much on how many more firms join. Adding the four hundredth dependent firm changes little; the damage was done somewhere near the twentieth.

A model-dependency network A network diagram. At the centre is a shared-infrastructure hub, the data vendors, pre-trained models, and cloud platforms that many firms rely on, ringed by a faint dashed shockwave and marked with a burst. Four firm nodes at the corners, each with its own risk engine and trading desk, connect to that hub by gold edges whose arrowheads point outward to the firms, showing a shock at the centre reaching every dependent firm at once regardless of how well each governs its own models. A regulator node below connects to the hub by a dashed cyan monitoring link. A model-dependency network one shared layer beneath many firms a shock here reaches every firm at once Shared infrastructure data vendors · models · cloud Firm A risk engine · desk Firm B risk engine · desk Firm C risk engine · desk Firm D risk engine · desk Regulator system-wide monitoring Schematic. Shared-node risk needs vendor controls, resilience, substitutability, and system-level monitoring, beyond firm-level validation.
Figure 2 · A model-dependency network One shared layer of data, models, and cloud beneath many independent-looking firms A critical failure can sit outside the firm. Common providers and data can correlate operational outages or model errors across institutions that otherwise maintain separate governance and trading books.
each firm fails in a period if either
    (a) an independent failure occurs,  probability r
    (b) it depends on the common provider AND the provider fails,
        probability q, drawn ONCE per period for all dependent firms

parameters (assumptions, not estimates):
    N = 400 firms      r = 0.004      q = 0.02
    share s of firms dependent, from 0 to 1
    200,000 periods per point, NumPy PCG64 seeded 20251001

benchmark: a binomial system calibrated to the SAME mean failure rate,
           with no shared dependency. Mean identical, correlation zero.

result at s = 0.5:
    P(at least 5% fail together)   shared      0.0200
                                   independent 0.0000  (0 of 200,000 periods)

Validation estimates local fitness. Dependency mapping asks whether the same error can arrive at many firms together. The two controls answer different questions, and a firm can pass the first perfectly while contributing to the failure of the second.

Section 03Correlation is the exposure

The correlation channel cannot be observed from one institution's inventory. The FSB notes that common models and data may increase correlation in trading, lending and pricing, with possible amplification through liquidity strain, and that reliance on specialised hardware, cloud services and pre-trained models has increased third-party dependency in a market with a small number of significant providers.

Supervision has been moving from the firm to the network in response. The FSB followed its 2024 assessment with a monitoring framework in October 2025, aimed at tracking adoption and provider concentration across the sector rather than assessing individual models. That is the right unit of analysis for the mechanism in Figure 1, because the quantity that moves the tail, the share of firms sharing a dependency, is not visible from inside any of them.

Validation answers whether your model is wrong. It cannot answer whether everyone is wrong together.

The resulting risk inventory has two layers. The first is familiar: model purpose, assumptions, validation, limits, monitoring. The second maps dependencies, substitution time, data lineage, provider concentration and failure propagation. A firm can complete the first layer immaculately and still be one of four hundred holding the same single point of failure, and nothing in the first layer would tell it so.

What Figure 1 does not do is estimate any of this for a real market. The failure probabilities are stated assumptions chosen to be legible; the dependency share is the axis rather than a measurement; and the conclusion is conditional throughout. Whether the financial sector is at ten per cent shared dependency or eighty is exactly the question the FSB's monitoring work exists to answer, and it is not answered here.

  • Figure 1 is a scenario, not an estimate. Every parameter is an assumption stated in the notes, and no real adoption rate, failure rate or provider share is measured anywhere in this article.
  • The model treats provider failure as a single binary event per period. Real outages are partial, of varying duration, and correlated with the conditions under which they matter most, all of which would make the tail worse rather than better.
  • Firms are treated as identical and exchangeable. In practice the largest firms are both more likely to run bespoke infrastructure and more consequential when they fail, and the model captures neither.
  • The independence benchmark is calibrated to the same mean by construction. That is what isolates correlation, and it also means the comparison says nothing about whether the overall failure rate is realistic.
  • Shared infrastructure brings genuine benefits in cost, capability and, often, reliability. This article measures one consequence of concentration and does not weigh it against those benefits.

This research is analysis and commentary for general information. It is not investment advice, an offer, or a solicitation, and it contains no price forecasts. Figure 1 is simulated under declared parameters; descriptions of official work summarise the publications cited.

References & notes

  1. Financial Stability Board (14 November 2024). The Financial Stability Implications of Artificial Intelligence. fsb.org. Primary source for the four vulnerability channels and for the description of third-party dependency and provider concentration.
  2. Financial Stability Board (10 October 2025). Monitoring Adoption of Artificial Intelligence and Related Vulnerabilities in the Financial Sector. fsb.org. The follow-up monitoring framework referred to in Section 03.
  3. The simulation, its parameters, its seed and the derived table are reproduced by the script in research/2025-10/ in the journal's repository. No market or vendor data is used in Figure 1.

Return to the front page