Key takeaways

• Poor data quality shows up as mispriced loans, misallocated capital, and compliance findings in banking, and as extended lead times, wasted material, and idle capital in manufacturing.
• A useful measurement approach starts with business impact (financial, operational, reputational, regulatory) and only then moves to technical dimensions such as accuracy, completeness, timeliness, uniqueness, and validity.
• A remediation programme ranked by revenue, compliance, and customer impact directs engineering effort toward the data that matters most to the business.
• Under the AI Act, training data for high-risk systems must be relevant, complete, unbiased, statistically sound, and transparently sourced, giving compliance teams a concrete checklist to work against.

A rounding difference in a currency conversion has a negligible effect on a single transaction. Multiply it across a legacy core banking system processing millions of trades a year, and it becomes a material loss position an auditor can trace straight back to a pipeline with an unresolved ownership question. Data quality failures follow that pattern: small errors that compound into financial, operational, and regulatory exposure long before anyone names them a data problem.

Data quality deserves attention from the moment data is generated. Properly validated forms inside source systems catch errors before they enter a pipeline. Raw data extracts arrive in varying states of readiness, which leaves a data engineer to prepare them for the dashboards that executives read. A data engineer can build technical validation rules into that pipeline. The harder judgment, about which quality level a specific dataset needs, belongs to the domain expert who understands the business the data serves.

The Financial Cost of Poor Data Quality in Banking and Manufacturing

In banking, data quality problems reach the balance sheet directly. Duplicated, incomplete, or delayed data feeding an investment or risk model can push a financial institution toward the wrong call, and that call shows up in the profit line. Inaccurate credit risk profiling is a clear example: a bank misprices loans or misallocates capital because the model behind the decision worked from faulty assumptions. The resulting credit scores compress the real default risk signal, and the bank ends up carrying losses the model did not anticipate alongside a compliance finding.

The rounding example from the introduction plays out constantly in practice. A bank running inconsistent rounding logic across different legacy systems sees only a negligible discrepancy in any single foreign exchange conversion or daily interest accrual. At the scale a bank operates, those small errors compound into material financial losses and audit failures, because the discrepancies between systems become difficult to trace back to a source. Verifying compliance during an audit is already a demanding task; inconsistent data stretches out that process, and every extra week of audit preparation carries its own cost and its own risk of producing findings a regulator will flag.

Customer trust erodes through the same mechanism. A banking app that shows one account balance on the mobile dashboard and a different figure on the official monthly statement gives a customer a concrete reason to move to a competitor. Documents and notifications sent to the wrong address because of a stale record cause the same kind of quiet churn, one customer at a time.

Manufacturing carries a parallel set of costs, anchored in physical operations, with regulatory exposure playing a smaller role. Incorrect inventory data disrupts material purchasing and production planning in both directions. A critical component discovered missing mid-assembly extends lead times and strains the customer relationship attached to that order. Overbuying to compensate ties up capital in raw materials that sit unused on a shelf. Manufacturing against outdated specifications, or pulling the wrong raw material because a record pointed to it, produces waste and a direct financial loss on that production run. Underneath both failure modes sits the same structural issue: when a single source of truth is absent, gathering the right information before a decision takes time, and that time comes out of employees who could be doing something more valuable.

Which Data Quality Dimensions Matter Most, and Where

Data quality covers several distinct dimensions, and the one that matters most depends entirely on what the data does. Completeness carries the highest stakes in healthcare: a missing diagnosis, medication, or allergy record has a direct impact on a patient’s health and, in the worst case, their life. Accuracy takes priority in finance, where the correctness of transaction amounts, tax values, and invoice totals determines whether financial reporting holds up under compliance review.

Timeliness matters most where decisions expire quickly. On a stock exchange, data that is perfectly accurate loses its operational utility the moment it arrives past the decision window. Consistency, meanwhile, is the dimension executive reporting depends on: a leadership team making a high-level decision needs the same number to look the same wherever it appears in the organization, whether that is a board deck, a regulatory filing, or an internal dashboard. Mapping a dataset to the dimension it needs most, and treating each of the five dimensions with a priority appropriate to that use case, is what turns a data quality programme into something a business can act on.

How to Measure Data Quality Across Financial and Operational Impact

Measuring data quality works best when the business impact comes first and the technical detail follows. Four categories capture that impact: financial losses that hit revenue or margin directly, operational costs from employees’ wasted time, reputational damage from lost customer trust, and regulatory exposure from failing to meet a legal requirement. Ranking a dataset against these four categories tells a team where a quality problem costs money before anyone opens a data profiling tool.

Once the business case is defined, six technical dimensions give the measurement its structure. Accuracy asks whether the data comes from a reliable source and reflects reality correctly. Completeness checks whether every required field is present. Consistency confirms the same data is properly synchronized across every system that holds it. Timeliness measures whether data is available and current when a decision needs it. Uniqueness rules out duplicate records. Validity checks that data follows the format, rules, or constraints defined for it. Each dimension produces a metric a team can track over time, which is what turns 'our data quality is improving’ from an opinion into a number on a dashboard.

Building a Data Quality Remediation Programme That Prioritizes Business Impact

A remediation programme built around business impact fixes the data that drives value for the organization, directing engineering effort toward errors that carry business consequence, ahead of errors that affect only technical completeness. The starting point is defining how each dataset feeds a business process, then scoring each quality issue against four criteria. Financial impact covers direct losses, regulatory fines, and missed revenue opportunities. Operational efficiency covers the hours staff spend manually gathering or correcting data that arrives outside the required quality level. Customer experience covers incorrect billing, shipping delays, and personalization that misfires because the underlying record is wrong. Regulatory and compliance impact covers the risk of non-compliance, audit failures, and data privacy violations tied to that dataset.

Scoring every candidate fix against these four criteria gives a data team a defensible order of work. A CFO or a compliance lead can follow that order immediately, because it speaks in the same currency their own priorities do.

What the AI Act Requires From Training Data

The AI Act raises the bar specifically for high-risk AI systems, defined as systems whose use can significantly affect a person’s health, safety, or fundamental rights. That category includes public and financial services, healthcare, education, employment, the justice system, democratic processes, migration and border control, and critical infrastructure, which puts most of the AI systems a bank or an insurer might train squarely inside its scope.

For those systems, the regulation sets specific expectations for the data used in training, validation, and testing. The dataset needs to be relevant and representative of the group of people the system will affect once deployed. It needs to be as complete and error-free as realistically achievable, while still protecting the privacy of the people behind the records. It needs to be unbiased, free from the prejudices and distortions that often sit inside historical data and can translate directly into discriminatory outcomes. It needs to be statistically sound, reflecting the real geographical, contextual, or behavioral environment the system will operate in. And it needs to be transparent, with a documented, well-understood original purpose for why the personal data behind it was collected in the first place. Full detail sits in Regulation (EU) 2024/1689.

Who Owns Data Quality: The Accountability Model

Data quality needs a single accountable owner, and that role sits with the Business Data Owner. This person defines what quality means for the business, sets the metrics the organization tracks, and translates those business requirements into logical rules an engineering team can implement. When a data error surfaces, the Business Data Owner decides whether it is critical enough to fix immediately or whether it belongs further down the priority queue.

Delivering on that responsibility takes three specialist roles working across different points in the data lifecycle. Software Engineers work at the source, redesigning the applications and forms that generate data in the first place and reducing the likelihood of a bad record entering the system. Data Engineers take over from there, building and maintaining the pipelines that clean, transform, and deliver datasets at the quality level the Business Data Owner has defined. Business Intelligence Developers sit closest to the business, turning agreed metrics into the reports and dashboards executives read and act on. The Business Data Owner is the thread connecting all three, from quality standard to business decision.

FAQ

What is the financial impact of poor data quality in banking?

Poor data quality in banking shows up as mispriced loans and misallocated capital when credit risk models run on incomplete or duplicated data. It also extends audit preparation time, raises the risk of a regulatory finding, and erodes customer trust when figures shown in different channels fail to match. Small errors such as inconsistent rounding logic compound across millions of transactions into material losses.

How does poor data quality affect manufacturing operations?

Poor data quality disrupts material purchasing and production planning. A critical component discovered missing during assembly extends lead times, or the team overbuys to compensate and ties up capital in unused inventory. Manufacturing against outdated specifications wastes raw material and creates direct financial losses on that production run.

Which data quality dimension matters most for my organization?

The dimension that matters most depends on what the data supports. Completeness is critical in healthcare, where a missing record affects patient safety. Accuracy is critical in finance, where transaction and invoice figures feed compliance reporting. Timeliness matters most where decisions expire quickly, such as stock trading, and consistency matters most for executive reporting drawn from multiple systems.

How should a company measure data quality?

A sound measurement approach starts with business impact: financial losses, operational cost from wasted staff time, reputational damage, and regulatory exposure. From there, six technical dimensions give the measurement structure: accuracy, completeness, consistency, timeliness, uniqueness, and validity. Tracking these as metrics over time turns data quality from an impression into a number a business can act on.

What does the AI Act require from data used to train high-risk AI systems?

The AI Act requires training, validation, and testing data for high-risk systems to be relevant and representative of the people the system affects, as complete and error-free as realistically achievable while protecting privacy, unbiased, statistically sound, and transparent about the original purpose of data collection. High-risk systems include those used in financial services, healthcare, and critical infrastructure.

Who is responsible for data quality inside an organization?

The Business Data Owner holds overall responsibility for data quality: defining business requirements, setting metrics, and deciding which errors demand urgent fixes. Delivering on that responsibility involves Business Intelligence Developers, who build the reports, Software Engineers, who redesign source applications and forms, and Data Engineers, who build and maintain the pipelines that produce clean datasets.