What Happens When Your Data Lies to Your CFO
Every CFO trusts their numbers. That's the problem.
Not because CFOs are gullible; it is because the systems feeding them numbers are quietly decaying, and nobody owns the decay. A data quality issue in a trading book doesn't show up as a data problem. It shows up as a P&L variance. A stale reference rate in a loan portfolio doesn't flag itself as "bad data." It registers as an unexpected margin compression. By the time the numbers look wrong, the data has been wrong for weeks.
This isn't a technology story. It's a governance story, and in Tier 2 banks, it's a balance-sheet story.
Why It Matters
Regulators have been clear: BCBS 239 made data quality a risk management concern, not an IT concern. OCC examiners regularly cite data integrity deficiencies in MRAs and MRIAs. The FDIC's own guidance on risk management expects banks to demonstrate that management information is "accurate, complete, and timely."
But here's the gap: most banks treat data quality as a back-office concern. Something the data team handles. Something that lives in ETL logs and reconciliation reports. Not something that sits on the risk committee agenda.
That separation is expensive. When data quality degrades, the costs don't show up in the data team's budget. They show up in restated earnings, regulatory findings, and market confidence erosion.
The Wrong Approach
Most organizations respond to data quality problems by building more quality checks. More reconciliation. More exception reports. More dashboards showing how many records failed validation this month.
This is governance theater. You're measuring the problem, not fixing it. And you're measuring it in the wrong place, at the end of the pipeline, after the damage is done.
The other common mistake is treating data quality as a project. "We'll do a big data quality initiative this year." Data quality is not a project. It's an ongoing condition. Projects end. Conditions either improve or deteriorate.
The Right Approach
Data quality becomes a balance-sheet risk when nobody with P&L authority owns it. The fix isn't more checks. It's clearer ownership.
First, identify your critical data elements: the data that feeds financial reporting, risk calculations, and regulatory submissions. Not all data is created equal. The 5% that flows into your call report matters more than the 95% that doesn't.
Second, assign ownership at the business level. Not to the data team. To the person whose numbers are wrong when the data is wrong. That's the line-of-business head. They need to feel the pain of bad data before they'll fund the prevention.
Third, make data quality visible at the top. Put it on the risk committee's dashboard. Not as a "data health score," as nobody knows what that means, but as exposure: "This is the P&L impact of the data quality issues we found this month."
When the CFO sees that $2.3M variance traces back to a stale feeding rate that nobody was responsible for refreshing, ownership appears overnight.
The CoComply Perspective
CoComply's approach starts from a different premise: data quality isn't a check; it's a certification. You don't just validate that data passed a rule. You certify that the person who owns the data vouches for its accuracy, the process that produced it is documented, and the evidence is traceable.
That's not a dashboard. That's institutional memory. And it means when someone leaves, the certification survives because it lives in the system, not in their head.
Certification turns data quality from a metric into accountability. And accountability is what turns a data quality program from theater into infrastructure.
The Test
Ask your CFO: "If the person who maintains your critical reference data left tomorrow, would you know within a week which numbers to stop trusting?" If the answer is no, you have a balance-sheet risk masquerading as a data problem. Fix the ownership. Then fix the data.