Legacy core banking systems integration

When a decades-old core starts blocking change, the tempting conclusion is that the core must go. We argue for the opposite order: change everything around it first. A full rewrite concentrates the bank's entire risk into a single multi-year programme – every account, balance and regulatory obligation in motion at once – and pays back only at the very end. A boundary takes risk in small, recoverable doses and returns value with every adapter that goes live.

Practically, the boundary is a thin layer of adapters and orchestration placed in front of the core. Behind it, the core carries on doing the job it has proven at for decades. In front of it, channels, products and partners integrate against contracts the bank controls. The two sides stop sharing fate: a vendor change freeze no longer stalls the roadmap, and a redesigned mobile journey no longer waits for a core release.

That boundary is the whole subject of this page: the adapters, middleware, data migration and synchronisation that keep the core serving customers while everything around it modernises. It is deliberately narrower than a full modernisation programme – a contained scope a bank can approve, fund and verify.

For the channel and product layer this boundary carries, see digital banking solutions.

The difficulty is rarely the core's documented API – it is everything around it. Decades of operation accumulate undocumented behaviour: batch jobs with implicit ordering, file exchanges that downstream systems quietly depend on, fields repurposed several times over, and validation rules that exist only in production. An integration that respects the manual but not the reality fails at its first month-end. In practice, four things bite most often:

• Batch windows that collide with real-time expectations
• Data quality drift accumulated over decades of workarounds
• Vendor change freezes that dictate the delivery calendar
• Undocumented consumers that break the day an interface changes

The deeper constraint is that boundary errors are financial errors. A mistranslated amount or a missed synchronisation is not a bug ticket – it is a customer seeing the wrong balance, and possibly a regulator seeing it too. So we treat the core as a system to be observed and characterised before it is changed, and the first adapter ships carrying its own reconciliation and telemetry – at this boundary, the cheapest incident is the one a bank detects before its customers do.

The adapter layer is an anti-corruption boundary: core data models stay on the core side, and everything in front speaks clean, versioned contracts. We decide deliberately what the layer translates, what it orchestrates across multiple core calls, and what it refuses to expose – because every core concept that leaks through becomes a dependency the bank pays for on every future change.

Synchronisation is the decision with the longest consequences. Event streams or change data capture suit customer-facing state that must be fresh; scheduled batch remains the correct answer for settlement-aligned data; and for every entity we fix a single source of truth for the transition period, so dual-write ambiguity never arises. Reconciliation runs as first-class production software that proves the layer is honest, rather than a spreadsheet someone checks when something looks wrong.

Middleware choices follow the bank's estate, not fashion: message brokers and orchestration where flows are long-lived and must survive restarts, plain synchronous APIs where they are not. Built this way, the layer outlives the first project – the next channel, partner or product plugs into the same contracts instead of starting another bridge from scratch.

We also package this boundary work as a reusable engagement shape – see the integration layer.

Cutover is a sequence of small moves that can each be undone, never a single weekend event. We shift one journey or customer segment at a time, keep the old route open behind it, and agree in advance what must be true before the next move – and what triggers a step back. A customer should never notice which system answered them; the only visible change is that new things start shipping faster.

Data moves under the same discipline. Mappings and cleansing rules are fixed before the first record leaves the old system, and every migration stage emits reconciliation reports your own teams can audit. The two paths then run side by side on real transactions, compared at the checkpoints that matter – balances, postings, month-end – and the old one is retired only when the numbers agree.

Risk committees and regulators see the same artefacts the engineers work from: migration runbooks, reconciliation evidence, rollback rehearsal results. Prepared as part of delivery rather than reconstructed after it, that material is what turns a cautious steering committee into an approving one – and it is the difference between a migration that stalls at sign-off and one that ships.

We ran this kind of migration for a bank with over 1.5 million users – read the migration in production.

Every engagement starts with a fixed-scope core boundary audit that produces the interface inventory, the synchronisation design, the migration sequence and a costed delivery plan. That plan is yours either way – you can hand it to any vendor. From there the engagement continues into phased delivery, each phase putting a concrete slice of the boundary – an adapter, a synchronisation flow, a migration stage – into production.

Pricing follows the drivers the audit makes explicit: how many interfaces and batch dependencies the boundary must respect, the state of the data, how long dual-run and reconciliation must hold, and the compliance evidence your regulator expects. We quote per phase against those drivers. No fixed figure survives contact with an unaudited core, so we do not invent one up front – we make the cost model transparent instead.

The run phase belongs to the boundary itself. Core patches and vendor releases can change behaviour the contracts depend on, so reconciliation stays on as routine work, monitoring sits at the seams where mismatches first surface, and the regression suite re-runs when either side changes. Your engineers run the layer after handover; we stay involved only as long as you want.