When Data Quality Becomes Financial Risk
For financial institutions, a poor AI outcome is rarely explained by the model alone. The diagnostic question is how a data weakness—an incomplete record, an unrepresentative sample, a changed data feed or an exposed sensitive field—travels through the lifecycle into a credit decision, an underwriting assessment, a fraud alert or a disrupted service. This chapter separates symptoms from causes so the reader can judge whether a system is failing because of its source data, its statistical performance, its privacy and security conditions, or a combination of them.
The distinction matters because “the data” is not one thing. Financial institutions combine records from legacy core systems, digital channels, customer platforms, public sources and external vendors. The resulting information may be rich but fragmented. A model may then transform it again, and an operational process may generate new data that influence later decisions. A reliable diagnosis must follow those transformations rather than treating an unexpected output as a self-explanatory property of an algorithm.
When quality defects become decisions
The first symptom is often an output that looks wrong: a credit assessment that misses a borrower’s changed circumstances, an insurance model that performs unevenly across groups, or a fraud system that produces too many alerts or overlooks a new pattern. Those symptoms have several possible causes. The underlying records may be inaccurate or incomplete. The data may be accurate for one purpose but irrelevant to another. The training population may not represent the customers and conditions encountered in production. The model may have learned the training data too closely, or the world may have changed after deployment.
The BIS identifies accuracy, completeness and representativeness as central dimensions of data quality, alongside consistency, timeliness and relevance. Each dimension answers a different question. Accuracy asks whether a record describes what it claims to describe. Completeness asks whether important information is missing. Consistency asks whether the same concept is recorded in compatible ways across systems. Timeliness asks whether the information is still current when a decision is made. Representativeness asks whether the data cover the people, situations and outcomes to which the system will be applied.
These distinctions are easy to lose inside a large financial institution. A core banking system may organise information in rigid, batch-based structures while a mobile application produces event-based records with every interaction. An insurer may keep policy, claims and customer information in systems that do not integrate cleanly. Different teams may use the same word for different fields, or different words for the same field. When those records are joined, a technically successful data transfer can still produce an incoherent analytical input.
A model’s score does not repair that incoherence. The BIS draws a useful line between data-protection accuracy and statistical accuracy. The former concerns whether personal data are correct and complete for their purpose. The latter concerns how often a model predicts an outcome correctly against labelled test data. A model can achieve a respectable statistical result while relying on personal records that are outdated or incomplete. It can also receive accurate records and still make poor predictions because the chosen variables do not capture the relevant relationship or because the test conditions do not resemble the live environment.
This is why a quality diagnosis needs a transmission path. Suppose a small-business credit system uses historical repayment data. If the data omit a group of borrowers, the model may learn a pattern that works for the observed population but performs poorly for the missing group. If an institution then approves or rejects applications on that basis, those decisions change who receives credit and which outcomes enter the next period’s records. The resulting data can reinforce the original pattern. The problem is not simply that a model contains “bias”; it is that a selection condition became a decision rule and then fed back into the evidence used for future decisions.
The same path appears in fraud monitoring, with a different tempo. A system trained on yesterday’s transactions can be accurate against yesterday’s patterns while becoming less useful as behaviour changes. A new payment channel, a changed customer habit or a new fraud technique can create data drift—the relationship between inputs and outcomes shifts after training. If the institution monitors only whether the system is still running, it may miss the fact that the system is still operating but no longer fit for its purpose.
Generative AI introduces additional uncertainty because its training information can be large, heterogeneous and difficult to inspect. Quality problems may arise from inaccurate material, missing context, unlabelled data or excessive model-generated content entering a later training process. The system may produce a plausible answer that is not supported by the available evidence. In a financial workflow, plausibility is not the same as reliability: a polished narrative about a borrower or an investigation can still contain an error that changes a decision.
The FSB describes related risks as overfitting, underfitting, inability to handle outliers and degradation over time. Overfitting occurs when a model performs well on its training data but poorly on new data. Underfitting occurs when it fails to capture the complexity that matters even in the training set. Both are failures of the relationship between data, model and intended use. A complex model can make those failures harder to assess if reviewers cannot see which assumptions produced the result.
Quality, privacy and security are separate risk families, but they meet on the same data path. A dataset can be representative yet unlawful to use, legally usable yet vulnerable to unauthorised access, or securely stored yet too incomplete to support a safe decision. The path below shows how a problem can enter before model use, emerge during operation or force a decision to restrict or retire the system.
The diagram is not a claim that every financial AI use follows these exact states. It is a diagnostic model. It highlights what must be preserved: the source and purpose of the data, the preparation applied to them, the evidence that they were fit for use, the changes observed after deployment and the reason for any restriction, remediation or retirement.
A useful verification process therefore compares more than one number. It can test new or previously unseen data, compare performance across relevant groups and conditions, examine outliers, repeat pre-deployment tests and check for drift. It can also compare an AI result with a different model, a different data source or a human assessment. Such comparisons do not prove that one answer is correct, but they can distinguish a broad environmental change from a defect in one feed or one model. When the underlying dataset is inaccessible, the institution’s ability to perform that diagnosis is itself reduced; provider opacity becomes a contributing condition rather than a separate administrative inconvenience.
Privacy and security constrain the same lifecycle
Privacy failure begins before a model generates an output. The BIS notes that personal data remain subject to data-protection requirements even when they are publicly accessible. An institution or developer must identify a lawful basis for collecting and processing them, and must consider the purpose for which they were gathered. The fact that information can be found on the internet does not by itself establish that it may be collected, combined with other data and used to make a financial decision.
Purpose limitation, data minimisation and retention limitation create a direct tension with the instinct to gather as much training data as possible. An institution should collect and use what is necessary for a specified purpose, rather than treat future usefulness as a sufficient justification. A single foundation model may support several applications, but that does not mean information collected for one application automatically becomes suitable for all of them. The organisation must distinguish developing a model, building an application on top of it and operating that application with live customer information.
Individual rights make the visibility problem more concrete. People may have rights to receive information, access their data, correct inaccuracies, object to processing or challenge certain automated decisions. Large language models complicate those rights because they may memorise or reproduce portions of their training material, while a deployer may not know what the model retained or may lack access to the original training set. Correcting a customer record in the bank’s system does not necessarily show how to remove an influence from a third-party model that used the record during training.
Privacy-enhancing techniques can reduce some risks, but they change the system in other ways. Anonymisation removes identifiers, pseudonymisation substitutes codes, differential privacy adds statistical protection and homomorphic encryption allows computation on encrypted data. These techniques differ technically and are not interchangeable. They may reduce the usefulness or accuracy of information, add complexity and cost, or leave residual re-identification risks. The relevant question is not whether a dataset has been labelled “anonymised,” but what information remains recoverable, what purpose the transformed data serve and what controls govern access and reuse.
Security concerns the confidentiality, integrity and availability of data. Confidentiality limits access to authorised people and systems. Integrity protects information from improper alteration or destruction. Availability ensures that authorised users can obtain it when needed. In a financial institution, failure in any one of these dimensions can affect more than a model. A breach can expose customer or proprietary information; corrupted training data can change future outputs; and an unavailable data service can interrupt a payment, monitoring or risk process.
AI adds new ways for those failures to occur. The BIS identifies poisoning, in which harmful material is introduced into training data, and indirect prompt injection, in which hidden content attempts to influence a system’s behaviour or disclosure. It also discusses model-inversion risks, where information about people might be extracted from a model, and exposure caused by external hosting or storage. The FSB broadens the picture to include deepfakes, AI-assisted phishing and other attacks that can increase the scale or speed of financial crime. These are risk scenarios, not proof that every deployment contains every vulnerability; their relevance depends on the system’s data, connectivity, autonomy and materiality.
Agentic AI makes the consequence of a data error more immediate. An agent may use an API, query a database or interact with another system while pursuing a goal. If it misunderstands an instruction, fails to recognise sensitive information or acts on manipulated data, the result may be an unauthorised action rather than an inaccurate paragraph. A control that is adequate for a read-only internal assistant may be inadequate for an agent that can alter records or initiate a transaction. The distinction is operational: the more systems and authority connected to the agent, the more important it becomes to constrain access, log actions and preserve a credible way for a person to intervene.
Alternative and synthetic data illustrate why no single remedy resolves these constraints. Alternative data can fill gaps left by conventional financial records, and synthetic data can help with training or testing when real information is scarce or sensitive. They may improve privacy or reduce some sources of bias. But the BIS also cites research warning that indiscriminate use of model-generated material can create defects and weaken a model’s ability to predict low-probability events. Synthetic data inherit assumptions from the process that produced them; they do not automatically preserve rare cases, legal permissions or real-world relationships. A data source should therefore be judged by its purpose, provenance, representativeness, security and failure behaviour—not by whether it is internal, external, real or synthetic.
This diagnosis also clarifies why the two principal sources should not be read as if they were one measurement. The BIS paper, published in March 2026, synthesises cross-sector data-protection and financial supervisory approaches across selected jurisdictions. The FSB report, dated 10 June 2026, is a consultation proposing non-prescriptive sound practices for responsible AI adoption. Their overlap on quality, privacy and security indicates a convergence of concerns, not a shared statistical estimate of risk. Neither document measures how frequently a particular failure occurs, and neither establishes that a specific control will eliminate it.
The practical conclusion is more restrained and more useful. Before asking whether a financial AI system is accurate, an institution needs to ask what its data mean, what has been lost or transformed, who can inspect the path, and what changes after deployment. It must be able to tell a stale feed from a biased sample, a privacy violation from a performance error, and a security incident from ordinary model uncertainty. That is the beginning of accountability.
But a well-diagnosed problem inside one institution can still be part of a larger exposure. The same data vendor, model provider or cloud platform may sit behind many financial services at once. The next question is how an apparently ordinary third-party dependency can spread similar behaviour or disruption across the institutions that share it.