This is the second in a series of articles on data quality in financial services. The first covered why traditional DQ programmes fail and how an AI-enabled DMAIC approach provides a more durable foundation.
Most conversations about data quality in financial services focus on the wrong number
Organisations track the volume of data quality alerts. They monitor the percentage of records that pass validation rules. They report on the number of issues raised and closed each month. These are the metrics that appear in governance dashboards and get presented to steering committees.
None of them capture the actual cost. The actual cost lives somewhere else entirely. It lives in the size of the operations team standing behind the DQ tooling, reviewing exceptions every morning to work out which ones matter. It lives in the client services function that fields calls when a report is wrong, a position is misstated or a corporate action was not applied correctly. It lives in the data analysts spending their afternoons retrospectively tracing the origin of a defect that has already caused a settlement failure or a regulatory break. It lives in the remediation effort that gets applied tactically, record by record, with no structural fix that would prevent the same defect from appearing again tomorrow.
That is the cost most organisations are not measuring. And in my experience working with some of the largest asset servicing, asset management and wealth management institutions in the world, it is considerably larger than the line item that appears in the technology budget.
What the operational cost actually looks like
Let me be specific about where the money goes, because the pattern is consistent across institution types and sizes.
First, there is the cost of running data quality checks at scale. Validation rules multiply over time. What starts as a focused set of controls covering the most critical data elements gradually expands to cover everything, because every team that has ever been burned by a data issue wants a rule to prevent it happening again. The result is a rule estate of thousands of controls, running overnight across millions of records, generating exception queues that nobody has the capacity to work through properly.
Second, there is the operations team that sits behind those checks. In most institutions I have worked with, a meaningful proportion of the operational headcount in data, settlements and reporting functions spends a significant part of its working day on exception management. The task is not remediation. It is triage, reviewing the exceptions the system has flagged to determine which ones represent a genuine business risk and which are false positives generated by rules that were never properly calibrated to business impact. That distinction should never require a human being. It requires a well-designed DQ programme.
Third, there is the client management overhead. When data quality issues surface in client-facing outputs, a client report contains incorrect holdings, a performance figure is wrong, a corporate action entitlement has been miscalculated, someone has to explain it. That conversation takes time, it requires senior involvement, and it creates a trust deficit that takes far longer to recover than it took to create. The operational cost of that conversation rarely appears in any data quality budget.
Fourth, there is retrospective fixing. When a defect is caught after the fact, and in batch-based environments that is almost always when it is caught, the remediation effort is entirely tactical. A record is corrected. The downstream systems that consumed the corrupted record have to be updated. Any outputs that relied on it have to be reprocessed. The same defect will appear again in the next batch cycle, because nothing in the process that created it has changed. Add those four costs together and the true operational burden of poor data quality is not a technology problem. It is a structural one.
Why more tooling does not fix a structural problem
The instinct, understandably, is to buy a better DQ tool. Or to implement a data observability platform. Or to add AI-powered anomaly detection on top of the existing stack. These investments are not wrong. But they are solving the wrong problem first. The reason the exception queue is too large is not that the DQ tool is insufficient. It is that thousands of rules were written without reference to business impact, so they generate alerts of equal severity for issues that have wildly different consequences. A missing field in a deprecated staging table appears alongside a missing ISIN in a settlement instruction. Both are flagged. Neither is prioritised correctly. The reason the operations team spends its time on triage rather than remediation is not that the team lacks the right skills. It is that the programme was never designed with clear ownership of specific data domains by the people who understand what good looks like in business terms. The reason data defects recur is not that the remediation tools are too slow. It is that root cause is never addressed. The fix happens at the record level. The process, the integration or the vendor feed that introduced the defect in the first place continues to introduce it. More technology, applied to a structurally broken approach, scales the approach without fixing it.
The foundation that changes the economics
The organisations that have materially reduced their operational data quality cost share one characteristic, they built the foundation before they built the controls.
That foundation has three components:
Clear data ownership in the business, not the data team
Every critical data domain has a named owner who is accountable for defining what good looks like, validating that the controls reflect business reality, and making decisions when issues are escalated. This is not a data governance committee. It is a specific individual in the operations, risk or finance function who has accountability for a specific domain.
Business-impact led control design
Before any rule is written, the question is: what is the operational consequence if this data element is wrong or missing? A rule that cannot be connected to a specific operational outcome, a failed settlement, a regulatory break, a client reporting error, should not be deployed. This single discipline reduces rule volumes dramatically and eliminates most false positive noise before it is ever generated.
Embedded process controls, not retrospective audits
DQ standards are designed into the processes and systems that create and ingest data, not applied afterwards to the outputs. When a defect cannot be introduced at source because the process prevents it, it does not need to be caught, triaged, reported and remediated downstream. The cost does not accumulate in the first place.
Where AI changes the economics further
With that structural foundation in place, AI becomes genuinely powerful rather than just another layer on a broken architecture. In the DMAIC framework we use at Keyrus (Define, Measure, Analyse, Improve, Control), AI accelerates each stage in ways that directly reduce the operational cost described above.
In the Define and Measure stages, AI profiles data at scale, identifies semantic relationships across systems and automatically generates and prioritises DQ controls based on business impact. What previously required months of manual cataloguing and rule design can be completed in a fraction of the time, and the controls produced are better calibrated to operational risk.
In the Analyse stage, AI reduces root cause identification from days to hours. When a settlement fails or a NAV is wrong, the ability to trace the defect back to its origin across multiple systems and processes, and to identify whether the same pattern is present in upcoming transactions, changes the economics of remediation fundamentally.
In the Improve stage, AI agents handle high-volume, low-risk remediation autonomously. ISIN enrichment, duplicate detection, format standardisation, missing reference data population: these are tasks that currently consume significant operations capacity and can be handled without human intervention where the governance framework defines them as low risk. What remains for human review is the genuinely consequential: NAV adjustments, regulatory submissions, AML and KYC changes. Human judgement is reserved for decisions that require it.
In the Control stage, continuous monitoring agents replace overnight batch cycles. Defects are caught at the point of creation, not after they have propagated through downstream systems. The shift from detective to preventative controls changes the cost model: preventing a defect at source costs a fraction of what it costs to remediate it after it has already caused a failure.
The outcome in practice, at scale, is a material reduction in the operational burden. Manual remediation headcount cost falls. False positive volumes fall. Root cause identification accelerates. The proportion of low-risk corrections handled autonomously rises. The operations team is doing the work that actually requires human expertise, not triaging thousands of alerts to find the handful that matter.
The real strategic shift
Data quality has historically been treated as a cost of doing business in financial services. A necessary overhead. A compliance requirement. Something to be managed rather than solved. This framing is the problem. Organisations that have built the right foundation are starting to see data quality differently: as an operational standard that, when it is properly designed and embedded, reduces costs, improves client outcomes, accelerates regulatory response and enables AI initiatives to deliver their actual potential. Because the fundamental prerequisite for any AI programme to work reliably is data that can be trusted. The firms that have invested in the process, the ownership model and the governance structure first, and used AI to make that foundation more powerful and more scalable, are not just spending less on data remediation. They are operating with a structural advantage that compounds over time. That is what it means to treat data quality as a foundation rather than a fix.
Suyash Singh leads data and AI advisory at Keyrus UK, working with financial services institutions on data quality, AI readiness and operating model design. If this article raised questions relevant to your organisation, the conversation starts with a realistic assessment of where your data quality costs are actually accumulating.