The Hidden System Behind Financial AI
Financial institutions are adopting artificial intelligence in credit assessment, payments, fraud detection, compliance, customer service and internal operations. This series examines those institutions as the primary subject—not AI in the abstract—and asks how their relationships with data providers, model developers, cloud platforms, customers and authorities change the meaning of responsible governance. The practical judgment is straightforward to state but difficult to make: can a financial institution use AI to create value while still knowing what its system depends on, who can challenge it, and how it will continue when a model, dataset or provider changes?
The question matters because finance already runs on information. A bank decides whether to extend credit, a payments firm detects suspicious activity, an insurer assesses a claim, and a market participant prices or manages risk by collecting and interpreting data. AI can make those processes faster and broader. It can also make a weakness in the underlying information travel further and become harder to see. When several institutions use the same data, model or infrastructure, the issue is no longer only whether one model is accurate. It is whether the financial system is becoming dependent on common inputs that can fail, change or produce similar decisions at the same time.
Financial institutions are building AI into a data-dependent system
The benefits are not hypothetical. The Financial Stability Board’s 2026 consultation report describes financial institutions using AI for anti-money-laundering and know-your-customer checks, credit risk, portfolio management, fraud detection, cyber security and customer engagement. Traditional machine-learning systems are already established in many of these areas. Generative AI is expanding into document extraction, investigation support and knowledge retrieval, while agentic AI can sequence several tasks with less direct human prompting.
A reported credit-risk example shows why institutions are interested. In the consultation’s case study, a large regional bank used machine learning in small-business lending to identify more than 95% of non-performing SME loans at least three months before the businesses struggled to meet repayments in 2022. The report says that more than 80% of the identified at-risk borrowers were ultimately averted from default. Early warning can help a lender intervene sooner, understand a borrower’s situation and adjust a facility before a problem becomes more severe. It can also improve the lender’s portfolio management.
That example is not proof that AI improves credit outcomes everywhere. The institution is not named, the report does not provide an independent audit or a denominator for the reported percentages, and the result may depend on the bank’s data, process and intervention capacity. Its value is more specific: it shows that the usefulness of a financial AI system depends on a chain. The system needs information that arrives in time, a model that can detect a meaningful pattern, a workflow that lets a person act, and a feedback process that reveals whether the intervention worked.
Data therefore do more than train a model. They shape what the model can learn, how its performance is tested, which biases can be detected and how the system changes over time. In a live financial application, new data also drive inference and may feed monitoring or later refinement. A model can be technically sophisticated and still produce poor results if its information is incomplete, stale or unrepresentative. Conversely, a data source that appears useful for one purpose may be inappropriate for another because its collection, quality or legal basis does not match the decision being made.
The relationships around the data matter as much as the data themselves. A data provider may supply market information, credit-bureau records, fraud indicators or alternative data. A model developer may select and curate training data, build a foundation model or provide a system that the financial institution customises. The financial institution, as deployer, may place that system inside a customer-service tool, a fraud workflow or a credit process. These roles can sit in different organisations, but the resulting decision still reaches a customer, a balance sheet or a critical operation.
Why the model-only view is too small
A conventional view of model risk asks whether a financial institution’s model performs as intended. That question remains necessary, but it is not sufficient when the institution depends on an external data, model or infrastructure provider. The institution may not see the training data, the provider’s processing practices, the changes made to an underlying model or the providers that sit further down the supply chain. Yet it may still be responsible for the decision made in its own environment and for meeting its obligations to customers and supervisors.
This creates two different kinds of exposure. The first is local: a bank’s own data pipeline may contain errors, its staff may use an unapproved tool, or its model may drift as economic conditions change. The second is shared: many banks, insurers or payment providers may rely on the same cloud infrastructure, foundation model, data vendor or deployment platform. A disruption or material change at that common point can affect several institutions even if each one followed its own procurement and model-review process.
Shared dependence can also create similar decisions rather than only simultaneous outages. If institutions receive overlapping data, use common models or rely on the same infrastructure, their assessments may move in the same direction. In calm conditions, that similarity may look like efficiency. Under stress, it can contribute to herding, procyclical behaviour, market pressure or a liquidity squeeze. The BIS analysis identifies this as a potential financial-stability vulnerability, not as a forecast that a particular provider will cause a crisis.
The concentration can exist at several layers. Cloud providers may host the systems. Hardware providers may constrain the computing capacity available to the market. Foundation-model developers may determine the capabilities and limitations of a widely used model. Data providers may influence what institutions can observe. Deployment platforms may connect those components to customer-facing or risk-critical processes. Vertical integration can link several layers together, while geographic concentration can expose the chain to a physical event or a common legal and regulatory change.
The data itself can also become more widely shared. Open-finance arrangements can increase portability and give AI systems access to more granular, customer-authorised financial information. That may improve analysis, but inconsistent standards and incomplete records can make the combined data less reliable. Combining sensitive financial information with external or unstructured sources can widen privacy and security exposure. The BIS also notes the possibility that mergers consolidate information about similar people across payments, health, location, social-media and search domains. More data availability does not automatically mean more trustworthy information.
The result is a visibility problem. A firm may be able to show that it approved a vendor, ran a test and assigned an accountable executive, while still lacking a clear view of how a provider’s training data, model update or infrastructure outage could affect its service—and whether peers are exposed to the same event. Governance that stops at the institution’s boundary can therefore miss the most important coupling in the system.
The question governance must answer
The evidence from the BIS and the FSB points to a broader definition of governance. It is not only a policy saying that a model must be accurate. It is the ability to trace data and responsibility through the system, test how the system behaves under relevant conditions, preserve meaningful human intervention, and understand what happens if an external dependency changes or disappears.
That definition does not require every institution to build everything in-house. A smaller firm may reasonably use a provider’s model or cloud service. The relevant questions are whether the use is material to a critical operation, what sensitive data the system can access, how much autonomy it has, whether the provider offers enough information and assurance, and whether the institution has a workable alternative or fallback. A simpler model may be preferable to a more capable one when it is easier to explain and control. A high-risk use may need stricter testing, closer monitoring and a human decision-maker, while a low-risk internal task may justify lighter controls.
Nor does governance mean that one regulator can solve the problem alone. The BIS describes a policy landscape assembled from data-protection rules, model-risk guidance, operational-resilience expectations, outsourcing requirements, AI frameworks and industry standards. Financial authorities may not have a direct mandate over every privacy question, while data-protection authorities may not see how a data issue affects a critical payment or credit process. The FSB’s proposed practices are meant to support coordination and information sharing, but its report is a consultation, not a binding international standard.
Those limits are part of the subject, not footnotes to it. The BIS paper is an analysis by its authors and says its views do not necessarily represent the views of the BIS or its member institutions. The FSB report, dated 10 June 2026, presents a non-prescriptive and non-exhaustive menu of practices that may evolve with the technology. Neither source supplies a market-wide measure of provider concentration or predicts a particular systemic event. Together, however, they identify a credible pathway: data-dependent financial AI can create firm-level harm, and shared providers or shared inputs can make that harm more common, more correlated or more difficult to contain.
The next question is therefore not whether a model has a clean approval document. It is where data enter the financial AI lifecycle, how they are transformed and handed off, and who remains able to see, challenge and correct the result. Once that chain is visible, the difference between an isolated model problem and a system-risk problem becomes possible to examine rather than merely assert.