At industry conferences this year, I’ve spent dozens of hours inside conversations with CEOs, CDOs, CIOs and operating executives across financial services. When I ask what’s keeping them up at night when it comes to their data, the answer is remarkably consistent: data access. They want data more accessible, faster, in more usable form, in more places, with fewer gatekeepers.
What's notable is what they don't ask for. Not trustworthiness. Not audit-ability. Not the ability to defend a number to a regulator without calling three people first. Access is the ceiling of the conversation, and honestly, that makes sense. In large financial enterprises built on decades of legacy applications, murky integrations, and pipelines that nobody fully documented, just getting the data somewhere useful is still a meaningful achievement.
The problem is that "getting the data" is already more complicated than most leaders realize. The moment data leaves its source system, decisions are being made about it. Decisions that quietly change what it means. And if you don't know those decisions were made, you don't know what you're actually looking at.
That's where lineage comes in, and why it matters even before you get to the outcomes leaders should be asking for.
Below, I’ll walk through (1) what “access” really delivers, (2) the abstraction layer hidden inside every extraction, (3) the compounding problem of “data derivatives”, (4) a concrete example – encoding and precision – where this gets expensive, and (5) what business leaders should be asking for instead.
What “Data Access” Really Delivers
When a business team asks for access to data, they almost always receive something that has already been processed for their consumption. Someone – usually a data engineer or database administrator – sat down with the source system and made a series of decisions:
- Which tables matter for this use case
- Which fields to expose
- How to filter, aggregate, or join the records
- Which technical artifacts to strip out (temp tables, system metrics, audit fields that don’t translate to business meaning)
These decisions are reasonable. Business consumers don’t want raw operational data; they want something readable without extraneous noise. But every one of those decisions encodes logic and judgment that doesn’t travel with the data. The output looks complete – and to the business user, it looks like the source of truth – but it is already an abstraction.
The Extraction Event Is a Translation Event
I find it useful to think of an extraction as a translation. Someone translated the operational reality of a data storage system into a business-readable view. Like any translation, choices were made: what to keep, what to drop, how to render concepts that don’t map cleanly across contexts. And like any translation, those choices can quietly change the meaning.
When a business leader looks at the extracted view, the assumption is usually that the data was “moved and shifted” – that is, copied with fidelity. That assumption is possible. In my experience, it is also highly doubtful. Logic gets applied at the moment of extraction, and unless someone deliberately captured and shared that logic, it is invisible by the time the data reaches a dashboard.
Abstractions of Abstractions: How Data Derivatives Compound the Problem
Here is where it gets harder.
Once an extracted data set exists, other people start using it. And why wouldn't they? There is already a data access path. The alternative - forging a new data access path - is the full corporate yellow tape headache: hunting for a charge code, filling out a technical work request that Business can’t quite decipher, watching that ticket age in a queue, and depending on legacy data SMEs who left the company in 2019. The extracted data set skips all of that. Already shaped for consumption, already lightly documented, already trusted by some peer team who vouched for it in a meeting six months ago. So the next team builds a report off it. Or creates a derivative data set for their own use case. Or both. What they don't realize is that the easy path and the right path may not be the same one.
They use it because it’s available and easier than starting from scratch.
That derivative is now an abstraction of an abstraction. The further you move from the originating system, the more layers of unrecorded judgment sit between the business decision and the operational event the data was supposed to describe. By the third or fourth hop, the question “where did this number come from?” can be genuinely difficult to answer – even for the team that produced the report.
A Concrete Example: How Encoding and Precision Quietly Rewrite Your Data
Let me make this concrete with an example I keep encountering.
When data is moved between systems, engineers make practical choices about how to package it. One of those choices is how to handle numeric precision. A value originally stored at six decimal places in the source might be packaged at four, or two, depending on what the receiving system supports – or simply what the engineer is most familiar with.
In some industries, that’s fine. In financial services, insurance, and healthcare, it is often not fine. A decimal place in an interest rate, a reserve calculation, or a pricing model can represent material variance. Once precision has been silently reduced, the data is no longer the real data – it is an approximation that looks identical to a casual reviewer. The business consumer assumes they’re working with the underlying record; in reality, they’re working with a rounded version of it that was reshaped during packaging.
This is exactly the kind of change that lineage is built to surface. Without lineage, you can’t tell that anything happened. With lineage, the precision change is documented, traceable, and reviewable.
Why Regulated Industries Can’t Afford to Skip Data Lineage
Regulatory frameworks have been ahead of business intuition on this point. BCBS-239 requires banks to demonstrate the accuracy, completeness, and timeliness of their risk data – which is impossible to defend without lineage. ORSA and Solvency II require insurers to substantiate the data flowing into solvency and capital calculations. None of these frameworks ask whether you have access to the data. They ask whether you can prove what the data is and how it got there.
For institutions operating under these regimes, lineage isn’t a nice-to-have analytics enhancement. It is the substrate that makes the rest of the data conversation defensible.
What Business Leaders Should Be Asking For Instead
If “give me access to the data” is the wrong ask on its own, what’s the right one? In my view, business leaders should be asking three questions every time a new data set lands on their desk:
- Where did this data originate, and what happened to it between then and now? Not a verbal summary – a documented path that is understandable in Business terms.
- What decisions were made during extraction or packaging that could have changed the meaning of the values I’m looking at? Especially around encoding, precision, filtering, and aggregation.
- If a regulator or auditor asked me to defend this number tomorrow, do I have the evidence trail to do it? If the answer is “we’d have to go find the engineer who built this,” the answer is no.
These questions don’t replace the access conversation – they extend it. Access is the entry point. Lineage is what makes access trustworthy.
A Final Thought
The reason business teams don’t ask for lineage isn’t that lineage doesn’t matter. It’s that the absence of lineage rarely announces itself. The data looks fine. The dashboard renders. The report mostly ties out. The risk lives in the assumptions you didn’t know you were making about what the data went through to get to you.
If your business teams are only asking for access, you have a gap – and in legacy environments where decades of undocumented logic sit between the source and the report, that gap is widest. The fix is to start asking for lineage too.
See Contextual Data Lineage in Action
Zengines Contextual Data Lineage is built for the environments where the lineage gap is widest – large financial enterprises with critical business logic locked inside COBOL, RPG, PL/1, and AS/400 code. We extract that embedded logic, make the data path visible, and give your teams the evidence trail they need to defend their numbers to auditors, regulators, and themselves.
If you’re working through a BCBS-239, ORSA, or Solvency II mandate, a planned mainframe migration, or a growing trust gap between your business teams and the data they consume, we’d like to hear about it.
