How a Large Bank Validated Its Mainframe-to-Microservices Fraud Detection Architecture in One Month
Reverse-engineering undocumented COBOL systems and delivering a working POC under banking-grade security constraints
How a Large Bank Validated Its Mainframe-to-Microservices Fraud Detection Architecture in One Month
Reverse-engineering undocumented COBOL systems and delivering a working POC under banking-grade security constraints
Outcomes at a Glance
End-to-end fraud detection POC delivered on time
Full working POC within one effective month of development
Complete solution architecture designed and validated
Presented to bank's technical and business panel; well-received by both
Undocumented legacy COBOL systems reverse-engineered
Architecture designed with limited technical documentation available
Banking-grade security and access constraints navigated
Strict policies, limited tooling access, and onboarding delays managed without delivery impact
About the Client
The Situation
The bank was running its fraud detection pipeline on IBM mainframes, with application logic written in COBOL and FICO Falcon handling real-time transaction scoring. The system had been built and extended over many years. It worked, but its architecture made it difficult to scale individual components, integrate with modern systems, or make targeted changes without risk to the broader pipeline.
The bank wanted to understand whether a microservices-based replacement was viable before committing to a full migration. Edstem was engaged to produce two deliverables: a complete solution architecture for the proposed replacement, and a working proof of concept demonstrating the end-to-end flow.
The Impact
Mainframe-based fraud detection carries a specific set of constraints. COBOL systems built over decades accumulate logic across thousands of lines of code, often with limited documentation. Skills to maintain and extend them grow scarcer over time. And because fraud detection sits directly in the transaction path, any change to the architecture carries direct financial and operational risk if it fails.
The bank needed confidence before committing capital and engineering effort to a full migration. The question the POC had to answer was not whether microservices could work in theory, but whether the architecture could handle the real data structures, integrate with the existing Falcon scoring infrastructure, and hold up under the bank's transaction volumes.
The Resolution
The engagement was scoped for three months. In practice, access delays and the bank's onboarding process for external parties compressed the effective development window to one month. Strict security policies added further constraints on tooling and environment setup. The working time was real: one month to reverse-engineer an undocumented legacy system, design an architecture, and build a working POC.
Edstem designed a Java Spring Boot microservices architecture to replace the mainframe pipeline. Two patterns were developed and presented to the bank's technical and business panel: a Choreography pattern, where services communicated via message queues without central coordination, and an Orchestrator pattern, where a central orchestrator managed the workflow with services communicating via REST. Both were well-received. The bank selected the Orchestrator pattern on the basis of the project timeline and the requirement for synchronous behaviour.
The POC demonstrated a complete end-to-end flow: reading fixed-length messages from the existing input queues, parsing and transforming them to Falcon's data structure, enriching transaction data, calling the Falcon scoring server via REST within its 300 TPS throughput limit, handling scoring server failures through a Postgres-backed retry store, and writing the final decision output (Approve, Decline, or Quarantine) as a fixed-length message to the output queue.
Both deliverables, the solution architecture and the working POC, were completed on time and well-received by the client.
Working on a mainframe modernisation or fraud detection system?
Edstem has experience building in regulated banking environments where the architecture has to be right before the first line of production code is written.
MORE CASE STUDIES
