Mainframe Data Lineage: The Bridge Between Managing Today and Modernizing Tomorrow
Mainframes aren't going anywhere overnight. Despite the industry's push toward cloud migration and modernization, the reality is that many financial institutions still rely on mainframe systems to process millions of daily transactions, calculate interest accruals, manage account records, and run core business operations. And they will for years to come.
Modernization is the eventual reality for every organization still running on mainframe. But "eventual" is doing a lot of heavy lifting in that sentence. For many financial institutions, a full modernization effort is on the roadmap but years away — dependent on budget cycles, vendor timelines, regulatory considerations, and a hundred other competing priorities. In the meantime, these systems still need to be maintained — and that's where things get increasingly risky.
The hidden cost of "just making a change"
When a business requirement changes — say, a new regulation requires a different calculation methodology, or a product team needs to update how accrued interest is computed — someone has to go into the mainframe and update the code. Sounds straightforward enough. Except it's not.
Mainframe COBOL codebases are often decades old. They've been written, rewritten, and patched by generations of engineers, many of whom have long since left the organization. A single mainframe environment can contain tens of thousands of COBOL modules, each with hundreds or thousands of lines of code. Variables branch across modules. Tables are read and updated in ways that aren't always documented. Conditional logic sends data down different paths depending on record types, dates, or account classifications that may have made perfect sense in 1998 but aren't intuitive to anyone working today.
Before a mainframe engineer can write a single new line of code, they need to answer a deceptively simple question: What will this change affect?
And answering that question — tracing a variable backward through modules, understanding which tables get updated, identifying upstream and downstream dependencies — can take weeks or even months of manual investigation. One engineer we've worked with estimated that investigating the impact of a change takes substantially longer than actually making the change.
Why mainframe management feels like navigating a black box
The term "black box" gets used a lot in mainframe conversations, and for good reason. The challenge isn't that the code doesn't work — it usually works remarkably well. The challenge is that nobody fully understands how and why it works the way it does.
Consider what a typical investigation looks like without modern tooling. An engineer receives a request from the business: "We need to update how we calculate X." To comply, that engineer has to:
- Determine a relevant starting point for researching “X”, which may be a business term or a system term. This starting point, for example, could be a system variable in a frequently accessed COBOL module
- Open the relevant COBOL module (which might be thousands of lines long)
- Find and trace the variable in question through the code
- Identify every table and field it touches
- Follow it across modules when it gets called or referenced elsewhere, keeping track of pathways where the variable may take on a new name
- Map out conditional branching logic that might treat the variable differently based on account type, date ranges, or other factors
- Determine which downstream processes depend on the output
- Document all of this before they can even begin to assess whether the change is safe to make
Now multiply that by the reality that a single environment might have 50,000 to 500,000 to 5,000,000 modules. It's not hard to see why organizations describe their mainframe as a black box — and why changes feel so high-stakes.
The real risk: unintended consequences
The fear isn't hypothetical. When an engineer updates a module without fully understanding the dependencies, the consequences can ripple across systems. A calculation that looked isolated might feed into downstream reporting. A field that seemed unused might actually be read by another module under specific conditions. A change to one branch of conditional logic might alter outputs for an account type that wasn't part of the original requirement.
These kinds of unintended consequences don't always surface immediately. Sometimes they show up in reconciliation discrepancies weeks later. Sometimes a client calls and says, "My statement looks different this month." By that point, the investigation to find the root cause is just as painful as the original change — if not more so.
This is why many mainframe teams default to a conservative posture. They move slowly, pad timelines, and layer in extensive manual review. Not because they aren't skilled, but because the risk of getting it wrong is too high and the tools available to them haven't evolved with the complexity of the systems they manage.
A better approach: data lineage for mainframe management
This is where mainframe data lineage changes the equation. Rather than manually tracing code paths and building dependency maps from scratch every time a change is requested, data lineage technology can parse COBOL modules at scale and generate a comprehensive, searchable view of how data flows through the system.
With data lineage in place, that same engineer who used to spend months investigating a change can now:
- Search for a specific variable, table, or field and immediately see every module that reads, writes, or updates it
- Trace the data path forward and backward to understand exactly where a value originates and where it ends up
- View calculation logic to understand the mathematical expressions and business rules embedded in the code
- Identify conditional branching to see where and why data gets treated differently based on record types or other criteria
- Understand cross-module dependencies to assess the full blast radius of a proposed change before making it
Instead of navigating thousands of lines of raw COBOL to answer a single question, the engineer gets a curated, structured view of exactly the information they need. The investigation that used to take months can happen in minutes.
Not just for modernization day — for every day between now and then
Much of the conversation around mainframe data lineage focuses on migration and modernization. And yes, lineage is critical for those efforts — but the value starts long before modernization kicks off.
Every time a business requirement changes, every time a regulation is updated, every time an engineer needs to write or modify code — they're navigating the same black box. Data lineage doesn't just prepare you for the future. It makes your mainframe safer and more manageable right now, during the months or years between today and the day you're ready to modernize.
For mainframe teams, it means less time investigating and more time executing. For risk and compliance leaders, it means greater confidence that changes won't introduce unintended consequences. For the business, it means faster turnaround on change requests without increasing operational risk.
And when modernization day does arrive, you'll be ready
Here's the other advantage of investing in data lineage now: when your organization is ready to modernize, you won't be starting from scratch.
Modernization isn't just about moving everything from the old system to the new one. It requires making deliberate decisions about what to bring forward and what to leave behind. Which business rules are still relevant? Which calculations need to be replicated exactly, and which should be redesigned? Which data paths reflect current requirements, and which are artifacts of decisions made decades ago?
Without lineage, those questions send teams back into the same manual investigation cycle — except now they're doing it across tens of thousands of modules under the pressure of a migration timeline. With lineage already in place, your team walks into modernization with a comprehensive understanding of how the current system works, what it does, and why.
And the value doesn't stop at cutover. Post-migration, lineage gives you a baseline for reconciliation. When the new system produces a different output than the old one — and it will — lineage helps you trace back to the original logic and understand why the results differ. Was it an intentional change? A missed business rule? A calculation that was carried over incorrectly? Instead of guessing, your team can pinpoint the source of the discrepancy and resolve it with confidence.
The mainframe isn't the problem. The lack of visibility is.
Organizations that rely on mainframes aren't behind — they're running proven, reliable infrastructure that processes critical transactions every day. The challenge has never been the mainframe itself. It's that the tools and processes for understanding what's inside it haven't kept pace with the complexity of the systems or the speed at which the business needs to evolve.
Data lineage closes that gap. Whether modernization is two years away or five, understanding what's inside the black box isn't something you can afford to wait on. Your teams need that visibility today to manage changes safely — and they'll need it even more when the time comes to move forward.
Zengines' Mainframe Data Lineage solution parses COBOL code at scale to give your team searchable, visual access to the data paths, calculation logic, dependencies, and business rules embedded in your mainframe.
You may also like
In this episode of the Finovate Podcast, host Greg Palmer sits down with Caitlyn Truong, CEO and Co-founder of Zengines, fresh off the company's Best of Show win at FinovateSpring 2026.
Caitlyn traces her path from hardware and software engineering in telecom to financial services consulting, where she and her co-founders kept running into the same gap: critical business logic locked inside legacy core applications written in COBOL, RPG, and PL/1. With 92 of the top 100 banks running COBOL mainframe cores and over half of credit unions and regional banks operating on RPG cores, that black box isn't an edge case — it's the industry norm.
Key points from their discussion
- Beyond pathway tracking: Traditional lineage tools show where data travels. Zengines Contextual Data Lineage ingests entire legacy codebases to reveal not just what happens to data, but why and how — the calculations, conditions, and business rules embedded in the code itself.
- Answers in seconds, not months: Business analysts, data analysts, compliance teams, and technical staff get self-service answers to questions that previously required waiting on scarce subject matter experts.
- Three use cases driving urgency: Meeting regulatory compliance requirements, de-risking modernization and transformation programs, and making legacy data AI-ready with the trust and traceability regulated institutions need.
- The Finovate experience: Caitlyn shares how the Sherlock Holmes-themed demo brought "shining a light into the black box" to life on stage — and her advice for first-time demoers on using seven minutes to plant hooks that turn into real booth conversations.
Listen to the full episode
Watch the demo replay
There is a rule that has been on the books for over a decade, and almost nobody outside of risk and compliance teams has ever heard of it: BCBS 239. It is not a catchy name. But the idea behind it is one of the more sensible things to come out of the post-2008 regulatory response: banks should be able to explain where their risk numbers come from.
Not approximate. Not eventually. Be able to trace a number back to its source, on demand, and show the path it took to get there.
That standard came into force for the world’s largest banks in January 2016. Almost ten years later, only a handful of the 31 global systemically important banks (G-SIBs) have reported full compliance. The ECB’s RDARR Guide, published in May 2024, named data lineage as one of seven priority areas still holding institutions back, and said it expects remediation work to continue through 2027.
I want to make the case that this isn’t a story about banks dragging their feet, or regulators failing to enforce something. It’s a story about a rule that was right, running into a technical wall that was real.
The wall was real
If you’ve spent time around a bank’s core systems, you already know what the wall looks like. Decades of COBOL or RPG, written and rewritten by people who retired years ago, running calculations that nobody currently on staff can fully explain. Ask a team to trace how a specific risk figure was derived, and the honest answer is often: we’d need a few months, and a few of our most senior mainframe engineers — who are also the people we can least afford to pull onto this.
That’s not a compliance excuse. It’s a real description of how these systems work. Logic gets buried inside modules that branch into other modules, which branch into more, written in a language most engineering schools stopped teaching in the 1990s.
So banks have been stuck between a standard they understand and largely agree with, and infrastructure that makes meeting it genuinely hard. Regulators have been patient about this — I think correctly — because the alternative, demanding visibility into systems that were close to a black box, wasn’t realistic.
What’s changed
I run a company called Zengines. We built technology specifically to deal with this wall: parsing legacy code at scale, tracing how data moves through mainframes and AS/400 applications, and surfacing the business logic that’s been buried inside them for decades — with the context needed to make it usable.
At one Fortune 100 financial institution, we’re currently working through hundreds of thousands of COBOL modules, some of them tens of thousands of lines deep, netting out to tens of millions of lines of code. Questions that used to take a mainframe specialist months to answer — tracing a variable by hand through branch after branch — can now be answered in seconds. An analyst can ask the system directly where a number came from, instead of opening a ticket and waiting. That same self-service access lets teams build their own understanding, and answer questions from regulators and transformation programs directly.
I’m not suggesting this solves everything BCBS 239 asks for. Governance, and the behavioral discipline of actually using data management tools once you have them — those still take sustained organizational effort, and always will.
But the specific claim that legacy mainframes are too opaque to document fully? That claim is no longer true, at least not in the way it used to be.
Why this matters beyond one regulation
I’d guess most people reading this don’t work in regulatory compliance.
If you’re a CDO, a CIO, or a risk leader at a bank with a mainframe at its core, BCBS 239 is probably one item on a long list. But the underlying question — can we actually explain how our own systems work? — isn’t a regulatory question. It’s a basic operational one. It’s the same question that determines whether you can trust the data going into a new AI initiative, whether you can defend a number in front of your own board, and whether the next system migration breaks something nobody saw coming.
Lineage has quietly become a prerequisite for almost everything banks are now trying to do with their data. Most executives don’t ask for it directly, because they don’t think to ask — they ask for the AI use case, or the modernization roadmap, or the faster reporting cycle, and lineage turns out to be the thing standing between them and any of it.
Where I land
I don’t think this is a story that needs villains. The standard was right. The barrier was real. What’s changed is narrower, and more hopeful: the wall that made the standard so hard to meet has a way through it now.
If you’re a regulator, I’d offer this as something worth knowing: the technical excuse has less weight than it used to. If you’re an executive at a bank still living with this problem, I’d offer something more direct — this is more solvable, and more quickly, than you’ve been told.
Either way, the goal was never the regulation itself. It was being able to look at your own systems and actually understand them. That’s now a lot closer than it’s been in years.
Sincerely,
Caitlyn Truong
CEO, Zengines
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 – it’s already shaped for consumption, already lightly documented, already trusted by some peer team. So they build a new report off it. Or they create a derivative data set for their own use case. Or both.
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.
Subscribe to our Insights
.png)
Build your AI-ready data foundation.
