Skip to content
SaaS & Startups2024

Meridian Bank ran 1.4 million customer accounts on a mainframe core that took nine months to ship a product change. We replaced it wave by wave with an event-sourced ledger on AWS, seven reversible migrations, zero settlement discrepancies, and a regulator sign-off without a single finding.

Client
FinancaPlus
Industry
SaaS & Startups
Timeline
18 months
Team
12 engineers
Year
2024
FinancaPlus — Albanian Saas Fiscalication platform for e-reporting
0settlement discrepancies at cutover
6 h → 14 minnightly close window
4/yr → 30/wkproduction deployments
38%lower run cost than the mainframe
The engagement

How we took FinancaPlus from the problem that hurt to the numbers above.

  1. The challenge

    Meridian Bank operated retail and SME banking for 1.4 million customers on a core built in the early 1990s: COBOL batch settlement on a mainframe, a nightly close that consumed a six-hour window, and product changes that took nine months to reach production. Two previous modernization attempts, both framed as full rewrites, had been abandoned after burning a combined 30 million euros, which made the board understandably allergic to a third.

    The constraints ruled out anything resembling a big bang. The regulator required parallel books during any transition, SEPA payment cutoffs could not slip by a minute, and more than 200 downstream systems consumed the core's overnight batch files, many of them owned by teams that no longer existed. Meanwhile the six remaining mainframe engineers were within four years of retirement, so every month of delay increased the risk that the institution would lose the ability to operate its own ledger.

    The mandate we agreed on was deliberately narrow: migrate the core product by product, prove correctness with money-level reconciliation at every step, and keep a rollback path open until the numbers had earned the right to close it.

  2. Our solution

    We wrapped the mainframe in a strangler-fig architecture centered on a new event-sourced ledger service. The first wave was intentionally low-risk, savings accounts, roughly 8% of balances, and ran in parallel with the mainframe for 90 days. A dedicated reconciliation service compared every balance and every posting daily, with drift alarms tuned to the cent. Only when parallel run produced zero unexplained discrepancies for 30 consecutive days did the wave cut over, and the mainframe remained the fallback book of record for another quarter.

    Change data capture via Debezium streamed DB2 mutations into Kafka, which let us feed the new ledger, the reconciliation service, and the 200-plus downstream consumers from the same event backbone. Instead of forcing every consumer to migrate at once, we generated their legacy batch files from the event stream, bit-compatible with the mainframe output, so downstream teams could move to real-time APIs on their own schedule. Products migrated in seven waves over 14 months: savings, then term deposits, current accounts, cards, SME lending, mortgages, and finally payments orchestration.

    In parallel we rebuilt the delivery machinery, because a modern core on quarterly releases would have wasted the investment. EKS clusters provisioned with Terraform, GitOps deployments through ArgoCD, and a progressive-delivery pipeline took the bank from four releases a year to roughly thirty a week, with every change traceable for the regulator.

  3. Architecture

    The ledger is event-sourced: every posting is an immutable event, balances are projections, and the audit trail is the data model rather than an afterthought. CQRS read models in PostgreSQL serve customer-facing queries at p99 under 50 ms, while Kafka acts as the integration backbone for downstream consumers and the reconciliation plane. Payment flows are coordinated with sagas rather than distributed transactions, and ISO 20022 message handling is isolated in a translation layer so scheme changes never touch the core.

    Everything runs on EKS across three availability zones in eu-central-1, provisioned entirely through Terraform with ArgoCD enforcing declared state. The parallel-run reconciliation service, comparing mainframe and new-core books daily, was treated as a first-class product with its own SLOs, because it was the instrument that made every migration wave reversible.

    Technologies

    KotlinSpring BootPostgreSQLApache KafkaDebeziumKubernetesAWSTerraformArgoCD
“Idealdevs did what two previous vendors could not: they treated the migration as a risk-management problem, not a rewrite. Every wave was reversible, every cent reconciled, and the regulator signed off without a single finding.”

Elena Marsh

Chief Technology Officer, Meridian Bank