COBOL LMS Modernisation Narrative
A business-first, ISO 20022-led modernisation model for extracting the proven COBOL legacy capabilities into a MACH architecture on AWS.
The case for a new pay line
"Move & Improve": keep the bank running, preserve proven capability, and improve where value is created.
"Lift, Evolve, Shift" is the delivery method underneath. It explains how the programme executes without forcing a risky big-bang replacement.
Compounding the value of your software assets. Delivery of working software on your technology vision for business value — the reason you funded a project.
Lift the working logic.
Evolve the business model into a canonical language.
Shift the runtime, channels, and interoperability.
The key architectural principle
Liquidity positions, limit rules, sweep logic, posting sequences, settlement controls, batch orchestration, reconciliation behaviour.
Business capabilities, business process, decision logic, state transitions, controls, exceptions, and regulatory intent.
How the software enables the business.
Channels, APIs, microservice boundaries, runtime platform, UX, orchestration, elasticity, cloud operating model.
The proven behaviour embedded in the LMS that has already survived real production complexity and business edge cases.
The key architectural principle
The modernisation question
The modernisation problem is not "how do we rewrite COBOL?"
It is "how do we extract and industrialise the business capabilities and business process already proven in COBOL?"
The technology question
The technology problem is not "how do we run this in AWS?"
It is "what is the technology platform that best delivers this now, and in the future?"
ISO 20022 reframed
Layer 1
Describes the "what" — the business process, activities, actors, and transactions. Independent of technology or message format. How the business operates.
Layer 2
Describes the "how" — the structure, content, and relationships of data required for each business transaction. We refer to this as "business data"; data required for a business process.
Layer 3
The physical syntax and XML implementation details used to exchange data — an API, message, database, file. Layer 2 has many physical implementations.
The sharp architectural point
If every service, platform, and workflow is forced to speak physical ISO 20022 XML internally, the bank hard-wires protocol detail into its business architecture. That creates coupling, brittleness, and unnecessary complexity.
The correct design is to keep the canonical model focused on Layer 1: Business Concepts and Layer 2: Message Concepts, while pushing Layer 3: physical ISO 20022 XML into a payment hub or gateway. The complexity of the ISO 20022 XML message is only mandated for inter-bank transactions.
Business services speak business language and logical message contracts.
The gateway handles XML schemas, validations, transformations, enrichment, and transport mappings.
Semantics are owned by the bank. Syntax is delegated to the interoperability layer.
The extraction pattern
AI-enhanced tools map modules, copybooks, jobs, data flows, decision points, and exception paths.
Business capabilities and business process are separated from their COBOL implementation details.
The extracted business process refines the existing business process catalogue with your context.
Capabilities become MACH-aligned services using Layer 1 and Layer 2 canonical models.
The COBOL system is therefore not a legacy obstacle. It is the source material for the bank's business capability model, business process catalogue, and regression truth set. (In rip & replace projects this provides the golden standard for acceptance of code.)
The canonical model focus
It defines the business process in banking terms, not in COBOL paragraphs, product vendor terms, or XML fields.
It becomes the source for Layer 2 message concepts and canonical service contracts across platforms.
COBOL, AWS microservices, and payment gateways can all change without rewriting the business semantics. Business capabilities are independent of the underlying technology.
Examples of catalogue entries
Intraday liquidity position calculation · Cross-border funding decision · Nostro balance monitoring · Sweep initiation · Limit breach escalation · Exception repair · Settlement release · Funding optimisation
Result
The bank owns a business architecture that survives platform changes and prevents vendor products from becoming the de facto business model.
Move & Improve translated into delivery
Keep the working LMS logic as the source of truth while exposing it through controlled interfaces.
Primary focus:
Layer 1 extraction from COBOL.
Refine the existing business process catalogue and define Layer 2 message concepts for the new MACH landscape.
Primary focus:
Layer 1 + Layer 2 stabilisation.
Move execution to microservices, APIs, and headless — and enable interoperability between legacy and AWS.
Primary focus:
Layer 3 at the edge only.
Target-state stack
Business layer
Business capabilities and business process catalogue and business data catalogue derived from the working COBOL LMS.
Canonical layer
Layer 1 Business Concepts + Layer 2 Message (Data) Concepts; the bank-owned semantic model for services, events, and orchestration.
Analyzer tool and AI-assisted business process extraction.
AWS MACH services, capabilities, APIs, event flows, and orchestration.
ISO 20022 gateway handling logical message to physical message and external rail mappings.
Legacy coexistence
IBM z/OS customer accounts and payment engines remain interoperable while migration proceeds capability by capability.
Recommended message architecture
Lift the working business logic. Refine our business process catalogue and canonical model.
Shift runtime, channels, and interoperability into a MACH architecture on AWS.
The winning story is not that the bank becomes "native AWS and native ISO 20022."
The winning story is that the bank owns its business capabilities, with technology independence and an architecture that can support whatever the bank chooses to innovate next.