Banking

The ledger
never stops, so
neither do we.

Core banking, payments, and settlement run on the mainframe and they cannot pause. We modernize them one slice at a time — zero-downtime cutover, transaction parity proven in shadow before a slice posts live.

Zero-downtime cutover Transaction parity in shadow Regulated & air-gapped supported
Typical legacy estate
COBOL
Core banking
On the mainframe
COBOL
Payments
Real-time and batch
Batch / DB2
Settlement
Schedule-bound runs
Cutover Strangler facade
The estate

The stacks banking runs on.

Core banking, payments processing, and batch settlement commonly run as COBOL on the mainframe, with mainframe DB2 holding the system of record. These platforms were built for exactly the kind of throughput and durability banking demands, which is why they have lasted — and why a wholesale replacement is so risky. They carry posting rules, reconciliation logic, and settlement timing that the rest of the bank, and often the wider market, depends on. Modernization here does not mean swapping one packaged core for another. The posting engine, the payment rails, the reconciliation and settlement logic move slice by slice onto a modern language and an event-driven data platform that can hold a ledger's consistency and ordering guarantees — deployable in the bank's own regulated or air-gapped environment, under its own supervision and risk controls, rather than a vendor's hosting model.

The pressure

What makes banking unforgiving.

Uptime, scrutiny, correctness, timing — banking has to hold all four at once, with no tolerance for a bad cutover.

01
Uptime is non-negotiable
Core banking and payments run around the clock. A maintenance window long enough for a big-bang cutover does not exist — the ledger has to keep transacting through the entire migration.
02
Regulatory scrutiny
Banking systems sit under continuous supervision. Changes have to be explainable, traceable, and reversible. A modernization that cannot show its work creates regulatory exposure, not just technical risk.
03
Transaction correctness
A payment posted twice, a settlement that does not reconcile, a balance off by a cent — in banking these are not bugs, they are incidents. The new system has to match the old one transaction for transaction.
04
Batch and settlement timing
Batch settlement runs to a schedule the whole market depends on. Modernized components have to meet the same windows, not just produce the same numbers eventually.
Why no big-bang

Zero-downtime cutover, transaction by transaction.

A big-bang core replacement asks a bank to switch its ledger on a single night and hope every posting, every reconciliation, every settlement window still works. Slice-by-slice removes that bet entirely.

Strangler facade
A facade sits in front of the legacy core and shifts traffic gradually, one slice at a time. Legacy and modern run side by side, so the ledger keeps transacting and the cutover carries no downtime.
Shadow traffic for parity
Each slice runs against the legacy under shadow traffic until it matches transaction for transaction — output, data integrity, and timing. It posts live only when it passes the parity gate.
Rollback at every stage
If a slice diverges, traffic rolls back to the legacy instantly. A divergence becomes a ticket, never a settlement incident — there is no point at which the bank is exposed to an unproven slice.
The core never goes dark. Legacy and modern run side by side until each slice has proven itself transaction for transaction.
— The strangler facade in banking
The target

Built for ten more years.

The modern target fits the bank, not a vendor's preference. Ledger and posting services run on a modern language and an event-driven data platform tuned for high-throughput transaction and settlement loads, with end-to-end observability so every posting and reconciliation can be traced. The result is modular and testable, horizontally scalable for peak payment and settlement volume, and built on a talent-friendly stack engineers actually want to work in. It runs wherever supervision and risk policy require — public, private, hybrid, or fully air-gapped — so the modern core lives inside the bank's own regulatory perimeter.

Where the advice stops
Slice-by-slice depends on being able to isolate a behavior and prove it in production. A real-time payment or settlement core whose postings cannot be cleanly mirrored — where shadow traffic can't reproduce the timing of a batch settlement window or the exact sequencing the ledger and regulatory reporting depend on — is a harder fit, and we name it during Discovery, not after kickoff. Telling a bank where the method does not apply is part of the method. Read the full approach →