Data Lineage 101: Understanding Its Meaning and Importance

Boston, MA - March 4, 2026 - Zengines, an AI technology company specializing in data migration and mainframe and AS400 data lineage, today announced it has been selected to demo live at FinovateSpring 2026, taking place May 5–7 in San Diego, California.

Finovate is one of the most prestigious fintech event series, drawing over 1,200 senior-level executives from banks, credit unions, and financial institutions - including nine of the top 10 U.S. banks. Demo slots are awarded through a competitive application and selection process, with only the most innovative and market-ready fintech companies earning a spot on stage.

Zengines will use its seven-minute live demo - Finovate's signature format - to showcase its Data Lineage product: an AI-powered research and visualization tool purpose-built for large financial institutions managing the complexity of “black box” systems.

What sets Zengines apart? Traditional lineage tools show you the map - at the surface level. Zengines gives you the map and the context behind it - built exclusively for the decades-old COBOL, RPG, and PL/1 systems no one fully understands anymore.

Conventional tools produce technically accurate data flow diagrams. They cannot tell you why a calculation exists, what business rule drives it, or what it means for your regulatory obligations. That context is buried in the code itself - and Zengines is built to surface it.

Two things define the Zengines platform:

1. Contextual lineage - Beyond data flow, Zengines captures the intent embedded in legacy code: calculation logic, branching conditions, field-level relationships, and business rules across thousands of modules. Raw lineage becomes actionable intelligence.

2. Legacy-codebase focus - Zengines specifically targets COBOL, RPG, and PL/1: the systems where the stakes are highest. Decades of accumulated business logic. Subject matter experts retiring faster than institutions can document what they know. No individual holds the full picture - and that risk is growing.

Together, these enable three outcomes financial institutions are struggling to achieve today:

• Regulatory compliance - Generate audit-ready lineage evidence for CDE, BCBS-239, and ORSA quickly and accurately
• Safe modernization - Reverse-engineer the "why, where, and how" of legacy code before migrating or replacing systems
• Live system confidence - Know your mainframe well enough to manage it: supporting teams, answering questions, and making changes with certainty

"Being selected to demo at Finovate is a meaningful validation of what we've built," said Caitlyn Truong, CEO and Co-Founder of Zengines. "The financial institutions in that room are dealing with exactly the challenges our lineage tool was designed to solve - regulatory mandates, modernization programs, and the 'black box' problem of legacy systems that no one can fully see into. We're excited to show them that contextual lineage is what actually moves the needle."

“Finovate demos are about showing, not telling, and Zengines’ contextual data lineage is something that I’m sure our audience is going to really appreciate seeing at FinovateSpring this May,” said Greg Palmer, VP and Host of Finovate. "The FI’s in our audience are wrestling with legacy infrastructure that's been accumulating complexity for decades. Zengines' ability to understand what's inside those systems before trying to modernize them or meet regulatory requirements is exactly the kind of solution that is likely to resonate with them.”

The Zengines Data Lineage tool is currently deployed at several Fortune 100 financial institutions across codebases spanning hundreds of thousands of source modules and tens of millions lines of code, where teams use it at enterprise scale  to accelerate analysis that previously took months down to minutes.

FinovateSpring 2026 will feature RegTech, AI, data optimization, and risk management among its key themes - making it an ideal stage for Zengines to connect with the financial institutions and consulting partners navigating solutions to support these exact priorities.

About Zengines

Zengines is an AI technology company helping financial institutions trace, map, change, and move their data to manage legacy systems, modernize, and meet regulatory compliance requirements. Our Mainframe Data Lineage solution goes beyond traditional lineage tools by delivering contextual intelligence - not just where data flows, but the business logic, calculation rules, and institutional knowledge embedded in decades of legacy code. Our Data Migration platform accelerates data conversion programs using AI, reducing time and risk across core conversions, system implementations, and new client onboarding. Zengines serves financial services firms and their technology and service provider partners - where the cost of getting data wrong is highest.

Learn more at zengines.ai

For Chief Risk Officers and Chief Actuaries at European insurers, Solvency II compliance has always demanded rigorous governance over how capital requirements get calculated. But as the framework evolves — with Directive 2025/2 now in force and Member States transposing amendments by January 2027 — the bar for data transparency is rising. And for carriers still running actuarial calculations, policy administration, or claims processing on legacy mainframe or AS/400s, meeting that bar gets harder every year.

Solvency II isn't just about holding enough capital. It's about proving you understand why your models produce the numbers they do — where the inputs originate, how they flow through your systems, and what business logic transforms them along the way. For insurers whose critical calculations still run on legacy languages like COBOL or RPG, that proof is becoming increasingly difficult to produce.

What Solvency II Actually Requires of Your Data

At its core, Solvency II's data governance requirements are deceptively simple. Article 82 of the Directive requires that data used for calculating technical provisions must be accurate, complete, and appropriate.

The Delegated Regulation (Articles 19-21 and 262-264) adds specificity around governance, internal controls, and modeling standards. EIOPA's guidelines go further, recommending that insurers implement structured data quality frameworks with regular monitoring, documented traceability, and clear management rules.

In practice, this means insurers need to demonstrate:

• Data traceability: A clear, auditable path from source data through every transformation to the final regulatory output — whether that's a Solvency Capital Requirement calculation, a technical provision, or a Quantitative Reporting Template submission.
• Calculation transparency: How does a policy record become a reserve estimate? What actuarial assumptions apply, and where do they come from?
• Data quality governance: Structured frameworks with defined roles, KPIs, and continuous monitoring — not just point-in-time checks during reporting season.
• Impact analysis capability: If an input changes, what downstream calculations and reports are affected?

For modern cloud-based platforms with well-documented APIs and metadata catalogs, these requirements are manageable. But for the legacy mainframe or AS/400 systems that still process the majority of core insurance transactions at many European carriers, this level of transparency requires genuine investigation.

The Legacy System Problem That Keeps Getting Worse

Many large European insurers run core business logic on mainframe or AS/400 systems that have been evolving for 30, 40, even 50+ years. Policy administration, claims processing, actuarial calculations, reinsurance — the systems that generate the numbers feeding Solvency II models were often written in COBOL by engineers who retired decades ago.

The documentation hasn't kept pace. In many cases, it was never comprehensive to begin with. Business rules were encoded directly into procedural code, updated incrementally over the years, and rarely re-documented after changes. The result is millions of lines of code that effectively are the documentation — if you can read them.

This creates a compounding problem for Solvency II compliance:

When supervisors or internal audit ask how a specific reserve calculation works, or where a risk factor in your internal model originates, the answer too often requires someone to trace it through the code manually. That trace depends on a shrinking pool of specialists who understand legacy COBOL systems — specialists who are increasingly close to retirement across the European insurance industry.

Every year the knowledge gap widens. And every year, the regulatory expectations for data transparency increase.

The Regulatory Pressure Is Intensifying

The Solvency II framework isn't standing still. The amending Directive published in January 2025 introduces significant updates that amplify data governance demands:

• Enhanced ORSA requirements now mandate analysis of macroeconomic scenarios and systemic risk conditions — requiring even more data inputs with clear provenance.
• Expanded reporting obligations split the Solvency and Financial Condition Report into separate sections for policyholders and market professionals, each requiring precise, auditable data.
• New audit requirements mandate that the balance sheet disclosed in the SFCR be subject to external audit — increasing scrutiny on the data chain underlying reported figures.
• Climate risk integration requires insurers to assess and report on climate-related financial risks, adding new data dimensions that must be traceable through existing systems.

National supervisors across Europe — from the ACPR in France to BaFin in Germany to the PRA in the UK — are tightening their expectations in parallel. The ACPR, for instance, has been specifically increasing its focus on the quality of data used by Solvency II functions, requiring actuarial, risk management, and internal audit teams to demonstrate traceability and solid evidence.

And the consequences of falling short are becoming tangible. Pillar 2 capital add-ons, supervisory intervention, and in severe cases, questions about the suitability of responsible executives — these aren't theoretical outcomes. They're tools that European supervisors have demonstrated willingness to use.

The Supervisory Fire Drill

Every CRO at a European insurer knows the scenario: a supervisor asks a pointed question about how a specific technical provision was calculated, or requests that you trace a data element from source through to its appearance in a QRT submission. Your team scrambles. The mainframe or AS/400 specialists — already stretched thin — get pulled from other work. Days or weeks pass before the answer materializes.

These examinations are becoming more frequent and more granular. Supervisors aren't just asking for high-level descriptions of data flows. They want attribute-level traceability. They want to see the actual business logic that transforms raw policy data into the numbers in your regulatory reports.

For carriers whose critical processing runs through legacy mainframe or AS/400s, these requests expose a fundamental vulnerability: institutional knowledge that exists only in people's heads, supported by code that only a handful of specialists can interpret.

The question isn't whether your supervisor will ask. It's whether you'll be able to answer confidently when they do.

Extracting Lineage from Legacy Systems

The good news: you don't have to replace your entire core system to solve the transparency problem. AI-powered tools can now parse legacy codebases and extract the data lineage that's been locked inside for decades.

This means:

• Automated tracing of how data flows through COBOL and RPG modules, job schedulers, and database operations — across thousands of programs, without needing to know where to look.
• Calculation logic extraction that reveals the actual mathematical expressions and business rules governing how risk data gets transformed — not just that Field A maps to Field B, but what happens during that transformation.
• Visual mapping of branching conditions and downstream dependencies, so compliance teams can answer supervisor questions in hours instead of weeks.
• Preserved institutional knowledge that doesn't walk out the door when your legacy specialists retire — because the logic is documented in a searchable, auditable format.

The goal isn't to decommission your legacy systems overnight. It's to shine a light into the black box — so you can demonstrate the governance and control that Solvency II demands over systems that still run your most critical functions.

From Compliance Burden to Strategic Advantage

The European insurers who navigate Solvency II most smoothly aren't necessarily the ones with the newest technology. They're the ones who can clearly articulate how their risk management processes work — including the parts that run on infrastructure built before many of today's actuaries were born.

That clarity doesn't require a multi-year transformation program. It requires the ability to extract and document what your systems already do, in a format that satisfies both internal governance requirements and supervisory scrutiny.

For CROs, Chief Actuaries, and compliance leaders managing legacy technology estates, that capability is rapidly moving from nice-to-have to essential — especially as the 2027 transposition deadline for the amended Solvency II Directive approaches.

The carriers that invest in legacy system transparency now won't just be better prepared for their next supervisory review. They'll have a foundation for every modernization decision that follows — because you can't confidently change what you don't fully understand.

Zengines helps European insurers extract data lineage and calculation logic from legacy mainframe or AS/400 systems. Our AI-powered platform parses COBOL and RPG code and related infrastructure to deliver the transparency that Solvency II demands — without requiring a rip-and-replace modernization.

Every data migration has a moment of truth — when stakeholders ask, "Is everything actually correct in the new system?" Most teams don’t have the tools they need to answer that question.

Data migrations consume enormous time and budget. But for many organizations, the hardest part isn't moving the data — it's proving it arrived correctly. Post-migration reconciliation is the phase where confidence is either built or broken, where regulatory obligations are met or missed, and where the difference between a successful go-live and a costly rollback becomes clear.

For enterprises in financial services — and the consulting firms guiding them through modernization — reconciliation isn't optional. The goal of any modernization, vendor change, or M&A integration is value realization — and reconciliation is the bookend that proves the change worked, giving stakeholders and regulators the confidence to move forward.

The Reconciliation Gap

Most migration programs follow a familiar arc: assess the source data, map it to the target schema, transform it to meet the new system's requirements, load it, and validate. On paper, it's linear. In practice, the validation step is where many programs stall.

Here's why. Reconciliation requires you to answer a deceptively simple question: Does the data in the new system accurately represent what existed in the old one — and does it behave the same way?

That question has layers. At the surface level, it's a record count exercise — did all 2.3 million accounts make it across? But beneath that, reconciliation means confirming that values transformed correctly, that business logic was preserved, that calculated fields produce the same results, and that no data was silently dropped or corrupted in transit.

For organizations subject to regulatory frameworks like BCBS 239, CDD, or CIP, reconciliation also means demonstrating an auditable trail. Regulators don't just want to know that data moved — they want evidence that you understood what moved, why it changed, and that you can trace any value back to its origin.

Why Reconciliation Is So Difficult

Three factors make post-migration reconciliation consistently harder than teams anticipate.

• The source system is often a black box. When you're migrating off a legacy mainframe or a decades-old custom application, the business logic embedded in that system may not be documented anywhere. Interest calculations, fee structures, conditional processing rules — these live in COBOL modules, job schedulers, and tribal knowledge. You can't reconcile output values if you don't understand how they were originally computed.
• Transformation introduces ambiguity. Data rarely moves one-to-one. Fields get split, concatenated, reformatted, and coerced into new data types. A state abbreviation becomes a full state name. A combined name field becomes separate first and last name columns. Each transformation is a potential point of divergence, and without a systematic way to trace what happened, discrepancies become investigative puzzles rather than straightforward fixes.
• Scale makes manual verification impossible. A financial institution migrating off a mainframe might be dealing with tens of thousands of data elements spread across thousands of modules. Spot-checking a handful of records doesn't provide the coverage that stakeholders and regulators require. But exhaustive manual comparison across millions of records, hundreds of fields, and complex calculated values simply doesn't scale.

A Better Approach: Build Reconciliation Into the Migration, Not After It

The most effective migration programs don't treat reconciliation as a phase that happens at the end. They build verifiability into every step — so that by the time data lands in the new system, the evidence trail already exists.

This requires two complementary capabilities: intelligent migration tooling that tracks every mapping and transformation decision, and deep lineage analysis that surfaces the logic embedded in legacy systems so you actually know what "correct" looks like.

Getting the Data There — With Full Traceability

The mapping and transformation phase of any migration is where most reconciliation problems originate. When a business analyst maps a source field to a target field, applies a transformation rule, and moves on, that decision needs to be recorded — not buried in a spreadsheet that gets versioned twelve times.

AI-powered migration tooling can accelerate this phase significantly. Rather than manually comparing schemas side by side, pattern recognition algorithms can predict field mappings based on metadata, data types, and sample values, then surface confidence scores so analysts can prioritize validation effort where it matters most. Transformation rules — whether written manually or generated through natural language prompts — are applied consistently and logged systematically.

The result is that when a stakeholder later asks, "Why does this field look different in the new system?" — the answer is traceable. You can point to the specific mapping decision, the transformation rule that was applied, and the sample data that validated the match. That traceability is foundational to reconciliation.

Understanding What "Right" Actually Means — Legacy System Lineage

Reconciliation gets exponentially harder when the source system is a mainframe running COBOL code that was last documented in the 1990s. When the new system produces a different calculation result than the old one, someone has to determine whether that's a migration error or simply a difference in business logic between the two platforms.

This is where mainframe data lineage becomes critical. By parsing COBOL modules, job control language, SQL, and associated files, lineage analysis can surface the calculation logic, branching conditions, data paths, and field-level relationships that define how the legacy system actually works — not how anyone thinks it works.

Consider a practical example: after migrating to a modern cloud platform, a reconciliation check reveals that an interest accrual calculation in the new system produces a different result than the legacy mainframe. Without lineage, the investigation could take weeks. An analyst would need to manually trace the variable through potentially thousands of lines of COBOL code, across multiple modules, identifying every branch condition and upstream dependency.

With lineage analysis, that same analyst can search for the variable, see its complete data path, understand the calculation logic and conditional branches that affect it, and determine whether the discrepancy stems from a migration error or a legitimate difference in how the two systems compute the value. What took weeks now takes hours — and the finding is documented, not locked in someone's head.

Bringing Both Sides Together

The real power of combining intelligent migration with legacy lineage is that reconciliation becomes a structured, evidence-based process rather than an ad hoc investigation.

When you can trace a value from its origin in a COBOL module, through the transformation rules applied during migration, to its final state in the target system — you have end-to-end data provenance. For regulated financial institutions, that provenance is exactly what auditors and compliance teams need. For consulting firms delivering these programs, it's the difference between a defensible methodology and a best-effort exercise.

What This Means for Consulting Firms

For Tier 1 consulting firms and systems integrators delivering modernization programs, post-migration reconciliation is often where project timelines stretch and client confidence erodes. The migration itself may go seem to go smoothly, but then weeks of reconciliation cycles — investigating discrepancies, tracing values back through legacy systems, re-running transformation logic — consume budget and test relationships.

Tooling that accelerates both sides of this equation changes the engagement model. Migration mapping and transformation that would have taken a team months can be completed by a smaller team in weeks. Lineage analysis that would have required dedicated mainframe SMEs for months of manual code review becomes an interactive research exercise. And the reconciliation evidence is built into the process, not assembled after the fact.

This translates directly to engagement economics: faster delivery, reduced SME dependency, lower risk of costly rework, and a more compelling value proposition when scoping modernization programs.

Practical Steps for Stronger Reconciliation

Whether you're leading a migration internally or advising a client through one, these principles will strengthen your reconciliation outcomes.

• Start with lineage, not mapping. Before you map a single field, understand the business logic in the source system. What calculations are performed? What conditional branches exist? What upstream dependencies feed the values you're migrating? This upfront investment pays for itself many times over during reconciliation.
• Track every transformation decision. Every mapping, every transformation rule, every data coercion should be logged and traceable. When discrepancies surface during reconciliation — and they will — you need to be able to reconstruct exactly what happened to any given value.
• Profile data before and after. Automated data profiling at both the source and target gives you aggregate-level validation — record counts, completeness rates, value distributions, data type consistency — before you ever get to record-level comparison. This is your first line of defense and often catches systemic issues early.
• Don't treat reconciliation as pass/fail. Not every discrepancy is an error. Some reflect intentional business logic differences between old and new systems. The goal isn't zero discrepancies — it's understanding and documenting every discrepancy so stakeholders can make informed decisions about go-live readiness.
• Build for repeatability. If your organization does migrations frequently — onboarding new clients, integrating acquisitions, switching vendors — your reconciliation approach should be systematized. What you learn from one migration should make the next one faster and more reliable.

The goal of any modernization program isn't the migration itself — it's the value that comes after. Faster operations, better insights, reduced risk, regulatory confidence. Reconciliation is the bookend that earns trust in the change and clears the path to that value.

Zengines combines AI-powered data migration with mainframe data lineage to give enterprises and consulting firms full traceability from source to target — so you can prove the migration worked and move forward with confidence.