In most large banks and capital markets firms, a meeting takes place every month. It is called different things in different organizations: the data reconciliation review, the reporting sign-off, the numbers alignment call. The people in the meeting represent finance, risk, operations, and sometimes compliance. The purpose of the meeting is to resolve the discrepancies between reports that should agree but do not. 

These meetings are a sign of a broken data architecture. And its existence and persistence, year after year, despite significant investment in data platforms and analytics tooling, is the clearest evidence that data distrust in financial services is structural rather than incidental. 

Deloitte’s 2024 Banking and Capital Markets Data and Analytics Market Survey found that more than 90 percent of data users at banks reported that the data they need is often unavailable or takes too long to retrieve, and 81 percent cited data quality as a top challenge. Those figures are not from a survey of underfunded regional institutions. They describe the data reality at organizations that have spent billions on technology modernization. The problem is not investment, but the nature of the problem itself. 

Data distrust in financial services has three interconnected roots: quality failures that make the numbers unreliable, governance failures that make accountability unclear, and architectural failures that make consistency structurally impossible. Each one is addressable in isolation. None of them resolves without addressing all three. This is the dynamic that keeps organizations investing in data and still sitting in that reconciliation meeting. 

What Data Distrust Costs a Financial Institution  

Before examining the causes, it is worth being precise about what data distrust costs because the amount is large and its components are often invisible on any single budget line. 

A 2024 study found that 83 percent of financial institutions lack real-time access to transaction data and analytics due to fragmented systems. That figure translates directly into decisions made on stale or incomplete information, credit exposure assessments that do not reflect current positions, risk reports that lag the trading book by hours or days, and customer analytics that work from records that do not accurately reflect the current state of a relationship. 

The Bank of England’s 2024 survey of AI in UK financial services found that four of the top five perceived current risks were data-related, with data privacy, data quality, and data security ranking as the three most significant. That finding reflects what practitioners know, but boards and regulators are increasingly recognizing: the risks that financial institutions carry are not primarily technological or market risks. They are data risks, and data risks are governance risks. 

The direct financial cost is well-documented as well. Gartner’s research estimates that organizations lose between $9.7 million and $15 million per year due to operational inefficiencies and flawed decision-making attributable to poor data quality. In financial services, where the cost of a regulatory finding or a risk model failure can reach multiples of that figure in a single event, those numbers represent a floor rather than a ceiling. 

Regulatory enforcement has repeatedly reinforced this point. Citibank paid $400 million in civil money penalties to the OCC in 2020 for deficiencies in data governance and internal controls, followed by a further $136 million in 2024 for failing to meet remediation milestones. Deutsche Bank failed the Federal Reserve’s CCAR stress test specifically due to material weaknesses in data capabilities and controls supporting its capital planning process. These are not edge cases. They are the visible consequences of the underlying problem addressed in this article.  

Root cause 1: Data quality failures that accumulate silently 

Data quality in a financial institution is not a static property. It degrades over time as systems evolve, business rules change, source data is modified without downstream notification, and manual processes introduce inconsistencies that no automated check catches. 

The degradation is typically silent. A field that was populated correctly two years ago begins producing nulls after a system migration. A calculation that was accurate under one business rule produces different results after a policy change that was applied in one system but not propagated to another. A customer record that is correct in the CRM differs from the same customer’s record in the risk system because the two systems were updated at different times by different teams using different identifiers. 

None of these failures produces an error message. They produce numbers that are wrong in ways that are not immediately visible, until a reconciliation reveals the discrepancy, an audit surfaces the inconsistency, or a risk model produces an output that contradicts what the trading desk knows to be true. 

According to McKinsey research, financial institutions report that between 6 and 12 percent of their IT budget goes to data architecture alone, and recognize they could lower that cost by approximately 20 percent with better data models. That figure, a fifth of a large technology budget spent managing the consequences of poor data architecture, reflects the scale of the silent tax that data quality failures impose on organizations that have not addressed their root causes. 

The challenge is that data quality cannot be fixed by cleaning existing data. Cleaning a dataset is a point-in-time intervention that does not address the source of the errors. The same processes that produced the dirty data will produce dirty data again. Sustainable data quality requires quality rules applied at the point of ingestion, monitoring that detects drift before it propagates to reports and models, and ownership structures that assign accountability for specific data domains to specific people who have the authority and the incentive to act on quality failures when they occur. 

Root cause 2: Governance failures that make accountability unclear 

In most financial institutions, every function that generates or consumes significant data has a system of record it trusts and a definition of key metrics it applies. Those definitions were developed locally, over time, to serve local purposes. They are not wrong in isolation. They become wrong the moment they are placed next to a definition developed by another function for different purposes. 

Revenue is the most common example. A capital markets firm’s front office, its finance department, regulatory reporting team, and management information function will often define and calculate revenue differently, following different timing conventions, treatment of certain transaction types, and handling of intragroup positions. Each definition is locally defensible. None of them produces a number that matches the others, and the executive who asks for a firm-wide revenue figure gets a different answer depending on who they ask. 

This is considered a governance failure. No data platform resolves it. No analytics tool bridges it. The only resolution is a governance decision made at the senior leadership level, not delegated to a data engineering team, about which definition is authoritative, who owns it, and what process governs changes to it. 

Gartner’s research predicts that 80 percent of data and analytics governance initiatives will fail by 2027 due to the absence of a genuine or manufactured crisis that forces organizational alignment. The mechanism of failure is consistent: governance programs are designed as technical frameworks and handed to organizations as policies without the organizational change required to make them effective. Data stewardship roles are created without authority. Business glossaries are built without the business owners who are accountable for maintaining them. Data quality dashboards are built without anyone empowered to act on what they show. 

The governance model that works in financial services is not the one that produces the most comprehensive documentation. It is the one that places accountability for data quality outcomes with people whose performance is evaluated against those outcomes, not just the CDO function, but the business units whose decisions depend on the data and whose regulatory obligations require it to be reliable. 

At Paragon Shift, governance design in financial services starts with a different question than most programs ask. Rather than “what governance framework should we implement,” the starting question is “which five decisions does senior leadership make every month that depend on data they cannot currently trust, and who is accountable for each of them?” That framing produces a governance program anchored in specific business outcomes rather than a technically complete but organizationally ignored one. 

Root cause 3: Architectural failures that make consistency structurally impossible 

The third root cause is the most deeply embedded and the most expensive to address. Financial institutions, in most cases, run data architectures that were not designed for the analytical and regulatory demands they are now required to meet. 

A large bank might operate dozens of core systems, multiple generations of core banking platforms, trading systems, risk engines, CRM platforms, general ledger systems, and regulatory reporting tools, each with its own data model, its own identifier conventions, and its own approach to representing shared entities like customers, instruments, and positions. These systems were not designed to integrate. They were designed to perform specific operational functions, and they do that well. When the organization asks them to produce a consistent, unified view of a customer’s total relationship, a firm-wide risk position, or an end-to-end transaction audit trail, they cannot do it without significant transformation work applied to every query. 

A patchwork of legacy core infrastructure, fragmented customer records, isolated product systems, and inconsistent data definitions across business lines all work together to deteriorate model performance and generate outputs that regulators and business users cannot rely on. This is not a description of an underfunded institution. It is the operational reality of most large financial institutions, and it is why the reconciliation meeting exists. 

The architectural answer is a governed data platform that consolidates and standardizes data from disparate source systems, applies consistent transformation logic, and exposes a single, well-understood, trusted analytical layer. The implementation challenges are real: the source systems cannot be turned off, the data model complexity is significant, and the business logic embedded in legacy transformation code is often undocumented. But the architecture is not the hard part. Deloitte’s 2026 Banking and Capital Markets Outlook explicitly identifies fragmented data as one of the defining challenges banks must address as they attempt to scale AI and remain competitive. The institutions that will close that gap are the ones that treat the data architecture investment as a strategic necessity. 

Why the Three Causes Compound Each Other 

The reason data distrust persists despite sustained investment is that quality, governance, and architecture are not independent problems. They are mutually reinforcing. 

A well-designed architecture that surfaces data without governance produces clean pipelines feeding inconsistently defined metrics. A governance framework built on a fragmented architecture produces agreed-upon definitions that cannot be consistently populated because the source systems do not share the necessary data. A data quality program applied to ungoverned data cleans records according to rules that different functions would define differently, producing data that is internally consistent but not organizationally authoritative. 

The only approach that resolves data distrust in financial services is one that addresses all three simultaneously, in the right sequence. Governance decisions- who owns which data, what the authoritative definitions are, and how changes are managed must precede architecture design, because governance requirements shape what the architecture must deliver. Architecture decisions- which platform, which integration pattern, which transformation model must precede data quality programs, because data quality rules applied without a stable architectural foundation will not survive the next system change. 

The sequence is governance first, architecture second, quality program third. Most organizations invert it, building the platform before agreeing on governance and running quality programs on data whose authoritative definitions are still disputed. That sequence produces a technically capable infrastructure that the organization cannot use with confidence. 

At Paragon Shift, when we engage with CDOs and CIOs in banking and capital markets on data trust programs, the assessment phase always maps the current state across all three dimensions before any remediation is designed. The most common finding is that organizations have made significant progress on one or two dimensions while leaving the third unaddressed, and it is the unaddressed dimension that explains why the reconciliation meeting is still on the calendar. 

What the Path Forward Requires

A data trust program is a structured, multi-phase initiative through which a financial institution resolves the quality, governance, and architectural conditions that make its data unreliable. It is not a single technology deployment or a one-time remediation exercise. It is a multi-year commitment that spans people, process, and platform, and it does not have a delivery date so much as a maturity trajectory. The organizations that have made meaningful progress share a set of structural decisions that distinguish their programs from those that produced platforms but not outcomes. 

They defined success in business terms before technical terms. The measure of a successful data trust program is not the number of data quality rules in production or the number of datasets in the catalog. It is whether the CDO can open a risk report with confidence that the number reflects what actually happened in the source system, whether the CRO can defend a capital calculation to a regulator without a two-week discovery exercise, and whether the AI models being deployed in credit and fraud are training on data that has been validated, governed, and traced to its source. 

They established data ownership at the business level and made it non-delegable. Every critical data element has a named business owner, a person with line accountability who is evaluated against the quality and reliability of the data in their domain. That ownership does not sit with the CDO’s team. It sits with the functions that produce and consume the data. 

They treated data architecture as an enabler of governance, not a replacement for it. The platform was designed to enforce governance decisions that were made before the build, not to generate governance as a byproduct of technology deployment. 

Key Takeaways

1. Deloitte’s 2024 Banking and Capital Markets survey found that more than 90 percent of data users at banks reported that the data they need is often unavailable or takes too long to retrieve, and 81 percent cited data quality as a top challenge. These figures reflect structural conditions rather than resolvable individual failures. 

2. Data distrust has three interconnected root causes: quality failures that accumulate silently, governance failures that leave accountability unclear, and architectural failures that make consistency structurally impossible. Addressing one without the others produces partial improvement at best.

3. The correct sequence is governance first, architecture second, quality program third. Most organizations invert this sequence, which explains why significant technology investment does not produce lasting data trust.

4. The Bank of England’s 2024 survey of AI in UK financial services found that four of the top five perceived current risks for financial institutions were data-related. Data risk is not a subset of technology risk. It is a primary operational and regulatory risk that requires board-level visibility.

5. Data quality cannot be fixed by cleaning existing data. It requires quality rules applied at the point of ingestion, monitoring that detects drift before it reaches reports and models, and ownership structures that create accountability for specific data domains.

6. Gartner predicts that 80 percent of data and analytics governance initiatives will fail by 2027 for want of organizational alignment. Governance programs designed as technical frameworks and handed to organizations as policies consistently fail to produce durable data trust.

Conclusion

The reconciliation meeting will not disappear because a new platform is deployed or a new data quality tool is licensed. It will disappear when the organization has made the governance decisions that resolve the definitional disputes, built the architecture to enforce those decisions consistently, and established the quality program to monitor and maintain the results over time. Those three things, done in the right sequence, are what data trust in a financial institution requires. 

The organizations that have closed the gap between data investment and data confidence are not the ones that spent the most. They are the ones who started with the hardest conversation, the one about who owns what, who is accountable when the numbers are wrong, and what authority means in this institution, and built from there. 

Why financial institutions struggle to trust their own data