Why Data-Flow Analysis Matters in Core Banking and Insurance Systems

Legacy change gets risky when nobody can see where the business data really goes

A policy status changes in one program. A payment field is widened. A customer identifier is mapped into a new interface. The change request looks contained, at least on the surface.

Then the awkward questions start.

Which batch jobs read the same value overnight? Which CICS screens display it? Which DB2 tables, IMS structures, copybooks, reports, files, and downstream applications rely on the current shape of that data? Has a PL/I or Assembler component been sitting quietly in the path for years? Does the documentation describe what actually runs, or what someone thought the system did several releases ago? The list goes on.

This is where core banking and insurance systems punish shallow analysis. The risky part is not always the edit. It is the confidence around the edit.

In a mature legacy estate, data movement is often business logic by another name.

At ITP Software, this is one reason we talk about Panorama as a code comprehension and software intelligence product, not simply as a search tool. Search has its place. But banking and insurance change work usually asks a harder question: how does a business-critical value move through the estate, and what changes when that movement changes?

The Field Is Rarely Just A Field

In a newer application, a field may have a reasonably visible path from the form to the service to the database. Not always, of course. But often enough.

In a long-lived core banking or insurance system, the same assumption can be dangerous.

An account balance, claim amount, policy status, eligibility flag, payment instruction, product code, customer identifier, or risk field may pass through several layers of history. COBOL programs. Shared copybooks. PL/I routines. Assembler utilities. C or Java components. CICS screens. DB2 or IMS storage. JCL-controlled batch. Files exchanged with another system. Reports still used for reconciliation, operations, or regulatory work.

The value may be transformed several times. It may be validated in one place and formatted somewhere else. It may be passed through an intermediate structure with a name that no longer helps much. It may appear in a report that no one wants to break, even if no one remembers exactly who first asked for it.

That sounds untidy because real enterprise software is untidy. Pretending otherwise is how modernization plans get brittle.

What Data-Flow Analysis Adds

A useful data-flow view gives reviewers a way to follow the value, not just find the string.

For a banking or insurance system, that usually means answering questions like these:

• Where does this value originate?
• Where is it validated, transformed, stored, displayed, reported, or passed onward?
• Which programs, copybooks, database structures, files, jobs, screens, and interfaces touch it?
• Where does the path cross COBOL, PL/I, Assembler, C, Java, IBM Z, z/OS, CICS, DB2, IMS, or JCL boundaries?
• Which links are confirmed by code evidence, and which still need human review?

The last question matters. We do not believe analysis tooling should pretend to remove engineering judgment. A good tool gives the reviewer better evidence, clearer paths to inspect, and a more honest view of uncertainty.

Why Documentation Often Falls Short Here

Most large legacy systems have documentation somewhere. Architecture diagrams, interface notes, field descriptions, operational runbooks, old migration plans, maybe a few heroic spreadsheets.

Some of it is useful. Some of it is stale. Some of it describes a system that existed before years of urgent releases, regulatory changes, acquisitions, integrations, and local fixes.

Data-flow analysis does not replace documentation. It helps test documentation against the code estate. If a document says a value moves from one application to another, the analysis can help the reviewer inspect the actual path. If the document is silent, the code may still show a dependency that deserves attention before the next change.

That is particularly useful when the people who wrote the original system are no longer available every time a change has to be assessed.

Where The Risk Shows Up

Data-flow questions become especially practical in a few common situations.

A bank changes a payment or account field and has to understand downstream reporting and reconciliation impact. An insurer adjusts a claims or policy process and has to check batch, online, and document-generation paths. A modernization program replaces part of a COBOL application with a Java component, but the surrounding data still travels through mainframe jobs and files. A discovery team prepares a migration scope and finds that the current documentation does not explain enough about how values cross system boundaries.

None of these scenarios is exotic. They are ordinary enterprise change work. That is exactly why they deserve better evidence than a keyword search and a meeting with the one person who might remember the exception.

How Panorama Fits Without Turning This Into A Sales Pitch

Panorama is built for understanding large legacy and enterprise codebases. In this context, we would use it to investigate code relationships, dependencies, cross-references, data movement, and documentation gaps before the organization commits to a risky change or modernization step.

For example, a reviewer might use Panorama to trace a value from a COBOL copybook through programs, DB2 access, CICS screens, JCL-controlled batch jobs, reports, and connected components. In another estate, the interesting path may cross PL/I, Assembler, C, Java, IMS, files, or generated code. The exact route depends on the system. The important point is that the route should be inspectable.

That does not make the decision automatic. It gives architects, developers, modernization leads, and subject-matter experts a better starting point for the decision.

A Practical Takeaway

Before changing or modernizing a core banking or insurance system, pick one critical value and trace it seriously.

Where does it come from? Where does it change? Where does it live? Where does it leave the system? Which paths are confirmed by code? Which assumptions are still only assumptions?

If those answers are hard to produce, that is not a failure of the people maintaining the system. It is a sign that the estate has outgrown informal knowledge and static documentation.

Data-flow analysis gives the organization a more practical way to look at the system it already depends on. For many banking and insurance teams, that is the real starting point for safer maintenance, better documentation, and more realistic modernization planning.