About the client
The client is a bank with more than $150 billion in assets. Its transaction lifecycle runs across nine systems on IBM iSeries, written in RPG: Trades, Cash, Accounting, Corporate Actions, Reconciliation, Settlement, FX, Transitions, and Tax Reclaim. Together, they hold 2.9 million lines of legacy code.
The challenge
Every report a bank issues, from the narrative to the charts to the data underneath, is shaped by business rules: how a fee is calculated, which balances roll into liquidity reporting, why a transaction was rejected.
Many of those rules were created decades ago, and the context behind them now lives in code. In legacy applications written in COBOL, PL/1 and RPG, that code was built to execute the business logic, not to explain it. And no one wants to manually dig through programs or a stack of Business Requirements Documents (if these even exist) to learn why a report says what it says.
Business rules are what make data defensible
Data and risk leaders have to answer four questions about the data behind their reports: what each data element is, where it comes from, how it was produced, and whether its quality can be attested. The first two describe the data. The last two depend on business rules: the logic that produces each value, and the checks that help ensure it can be trusted.
They are what an auditor, a model risk team, or an AI agent ultimately needs to understand. Without them, data can be located but not defended.
On a modern data platform, that logic typically sits in SQL and pipeline code a data team can read. On a legacy transaction core, it is written in languages like RPG and COBOL, layered by decades of changes, and familiar only to a shrinking group of specialists.
That is where hard questions stall. How is this value calculated? What changes downstream if this logic changes? Can we show our work to auditors for how we arrived at this result? When the answer is spread over half a dozen systems or hidden inside tens of thousands of individual programs, tracking down the people who can piece together the picture becomes nearly impossible.
The solution: Contextual Data Lineage
The bank used Zengines Contextual Data Lineage to read the code itself and surface the business rules inside it, with the context needed to trust them.
From 2.9 million lines to 131,000+ rules
Lines of code are what a developer sees: file handling, loops, error routines, screen logic. Most of it is plumbing. Inside it sit the decisions the business depends on: how fees and accruals are calculated, how corporate actions adjust positions, which balances feed liquidity and regulatory reporting, why a transaction was rejected, and whether a tax reclaim is eligible.
Zengines separated those decisions from the plumbing and expressed each one as a rule, in language a data or risk professional can read. Each rule arrives with its business context (each data element translated into business terms, with its operational implications), its source code, its lineage across systems, and the data quality checks that apply to it.
One rule, nine systems
A bank's transaction lifecycle doesn't live in one place. At this bank, it runs across all nine systems.
Follow a single fee. It is calculated when a trade is booked, converted to the client's currency, posted to the ledger, and checked in reconciliation before it ever appears in a report. When an auditor, a regulator, or a client asks why that fee is what it is, the answer runs through every one of those steps.
With the rules surfaced and connected, that answer is in one place, with its source at every step, instead of a cross-team investigation.
Built for scrutiny
Asking an LLM tool to summarize legacy code is fast, and for exploration it may be useful. But a regulated institution carries risks a generated and generalized summary cannot answer for.
| Risk | With an LLM-generated summary of the code | With Zengines |
|---|---|---|
| Reproducibility | Ask twice, get two answers. What you told an examiner may not be what you get next time. | Same code, same rules, every run |
| Consistency | Different teams and prompts produce different versions of the same logic | One set of rules, shared by every team |
| Explainability | Describes what the code seems to do, without showing where | Every rule linked to the code that defines it and the data it affects |
| Completeness | No way to know what was missed | The full codebase in scope |
| Currency | Goes stale silently when the code changes | Regenerates as the system changes |
| Accountability | An output nobody owns | Validated by the business |
The results
- A curated CDE catalog in minutes, not months. Whether a data element is critical depends on how it is used: what it feeds, who consumes it, and what rides on its accuracy. The rules and lineage answered those questions with evidence from the code. Analysts validated the output and curated a critical data element catalog in which every element carries its business rules, lineage, and source. That work previously took months of manual gathering.
- Data quality on every critical element. Each CDE was assessed against applicable quality dimensions and the bank's own policies, drawing on metadata- and lineage-based intelligence.
- Data an AI agent can act on. The trusted catalog was fed into a compliance AI agent, giving it traceable, explainable data instead of data still waiting to be checked.
For data and risk leaders, 131,000+ contextual rules put the logic behind their data, and the answers that come with it, within reach. Each rule explains how a value was produced, where it flows, what depends on it, and whether it can be trusted. Before, every one of those questions meant finding the right program, finding someone who can read it, and hoping the explanation was complete. Now data and risk teams can find the answers themselves, with the definitive source attached.
Turning decades of logic into an asset
These rules have run the bank reliably for decades. They encode hard-won expertise in how its products, clients, and transactions should be handled, and much of what sets the bank apart from its competitors. They have evolved with new business needs, new regulations, and new analytics. By surfacing them in plain language and tracing each one to its source, the bank turned that expertise into an asset its data, risk, and AI teams can use every day.
Every institution is being asked to explain its data, and now to make it ready for AI. For institutions running on legacy systems, much of that explanation is already written in the code. It just needs to be read.
Learn more about Zengines
Zengines makes financial services data trusted and explainable, through the Turnkey Data Migration Platform and Contextual Data Lineage.
See the rules behind your own reports. If your institution runs on COBOL, RPG, or PL/1, many of your rules are already sitting in the code, waiting to be surfaced.