The Forensic Engineering Path to Modernisation

 
AI is changing legacy modernisation through its ability to systematically decompose complex systems.

In financial services, legacy estates encode years of accumulated behaviour: product rules, operational controls, reporting logic, and compensating workarounds introduced through continuous change. Understanding these systems has traditionally depended on manual code analysis, incomplete documentation, and a small number of subject matter experts, (SMEs).

That approach does not scale. More importantly, it introduces risk to modernization programmes as the system may never be  fully understood.

AI not only improves the economics of discovery, but enables the reconstruction of a system — when applied with discipline. Used without structure, it generates plausible interpretations. Used correctly, it enables a forensic approach to system understanding.

From Discovery to Forensic Engineering

Traditional discovery is constrained by two gaps: explicit knowledge is incomplete, and tacit knowledge is scarce.

A forensic engineering approach addresses both by extracting understanding directly from the estate itself, combining static analysis, controlled AI interrogation, and AI-extracted context intelligence confirmed with SMEs to reconstruct how a system actually behaves, not just how it was documented

The objective is not to generate documentation. It is to establish an evidence-based model of how the system actually behaves.

Start with Structure, Not Semantics

Before applying AI, the system must be grounded in structure.

Static analysis establishes a view of how the estate is assembled: what exists, how components connect, and where execution flows.

This extends beyond application code. It surfaces batch processes, reporting pipelines, reconciliation routines, integrations, and operational workflows that often sit outside core systems but materially influence behaviour.

This step serves two purposes:

• First, it defines the boundaries of analysis, ensuring AI operates within real execution paths rather than across an unbounded codebase.
• Second, it creates traceability. Every observation can be linked back to concrete system artefacts and execution behaviour.

Without this foundation, semantic analysis becomes educated guesswork. With it, the codebase becomes a navigable model.

Interrogate Behaviour, Not Just Code

Once structure is established, AI can be applied to behaviour.

This is not open-ended prompting. It is controlled interrogation using bounded queries, execution context, and domain-specific reasoning to extract meaning from the system in layers:

• What capabilities does the system support?
• How are they executed through customer and operational journeys?
• What events trigger behaviour?
• How are decisions and rules applied?
• How are risk, state, and control managed?
• Where do regulatory obligations attach to execution paths, and how are they currently satisfied?

This layered approach matters because behaviour in legacy systems is rarely implemented in a single place. It is fragmented across services, databases, batch jobs, integrations, and operational processes.

AI enables these fragments to be connected, reconstructing how behaviour is implemented across the estate.

However, not all behaviour resides within the system itself.

In financial services, critical parts of execution often sit outside the platform: manual interventions, spreadsheet-based reconciliations, approval workflows, and operational workarounds introduced over time. These are typically invisible to both static and semantic analysis.

• Manual reconciliation processes — spreadsheet-based workflows that resolve breaks between systems and are often the only thing preventing downstream reporting errors.
• Approval and exception workflows — manual overrides, four-eyes checks, and escalation paths that represent regulatory controls, not optional process steps.
• Operational compensations — workarounds introduced after system failures or regulatory changes that never made it back into the codebase, but have since become standard operating procedure.
• Interbank and counterparty dependencies — settlement instructions, SWIFT messaging flows, and cut-off time rules that govern real transaction behavior but may not be modelled in the system.

This is where consulting and domain expertise remain essential.

Recommended reading: Scaling Enterprise AI Through Risk-Driven Governance

AI establishes the system-defined behaviour. Consulting-led analysis extends this into operational reality, capturing the human and process layers that complete the end-to-end flow.

An affordability assessment in lending, for example, may span APIs, credit models, databases, and scheduled processes, while also relying on manual overrides and exception handling outside the platform. AI can reconstruct the system logic. Practitioners identify where that logic is supplemented, bypassed, or corrected in practice and validate those findings with SMEs.

Reposition SMEs as a Control Layer

In this model, SMEs are no longer required to explain how the system works from first principles.

Instead, they validate and refine an evidence-based model that has already been assembled.

Workshops become more focused. Journeys, rules, dependencies, and ambiguities have already been identified. The discussion centres on validation rather than discovery.

The role of the SME shifts towards judgement:

• Confirming extracted behaviour
• Identifying edge cases
• Distinguishing necessary controls from operational workarounds
• Resolving ambiguity where system behaviour and operational reality diverge

This reduces dependency on scarce knowledge while improving the quality of outcomes. SMEs become a control function rather than a discovery bottleneck.

From Decomposition to Planning

The output of this process is not a delivery specification. It is a modernisation blueprint.

The estate is decomposed into functional domains and analysed through the lens of transformation. Behaviour is reconstructed, dependencies are exposed, service boundaries become visible, and migration complexity can be assessed with greater confidence.

The result is a clearer understanding of:

Driving Better Outcomes

Modernisation is not constrained by a lack of technology. It is often constrained by a lack of understanding.

A forensic engineering approach addresses this by combining:

• Structural grounding through static analysis
• Behavioural extraction through controlled AI interrogation
• Domain expertise and targeted SME validation
• Translation into an evidence-based modernisation blueprint

The objective is not to automate modernisation. It is to reduce uncertainty.

In understanding legacy systems more quickly and more systematically, organisations can make better decisions about architecture, investment, sequencing, and risk before committing to transformation.

With contribution from David Backhouse and Gaurav Gupta, GlobalLogic

Contact us to scope a forensic assessment of one domain in your estate. In 2–3 weeks, you’ll have a complete architectural picture and a modernisation blueprint grounded in how your system actually behaves, before any programme commitment.

You might also like:

• Become the Catalyst: How Financial Services Leaders Can Ignite Enterprise-Wide Transformation
• Operational Intelligence Turns Into Business Value for a Multi-Brand Retail Bank
• Building the Future of Financial Services: Data, AI & Cloud-Native Transformation