Skip to main content

ยท Architecture

The Case for Decoupled Architectures in Legacy Banking

How we architect resilient microservices to modernize aging platforms in the financial sector.

The core banking system is usually the oldest thing in the building, the most reliable, and the least willing to change. Every proposal to replace it competes with the fact that it works. Decoupling is the argument for leaving it alone and changing everything around it.

What decoupling means here

Rather than modifying the core, you put an interface layer in front of it. New products, channels and interfaces talk to that layer. The core keeps doing what it does, and it stops being the thing every project has to negotiate with.

The value is speed of change. A new customer-facing feature that needed a core release cycle can ship on its own schedule, and a failure in it cannot take the ledger with it.

The layer is where the difficulty moves to

Decoupling does not remove complexity, it relocates it. Three things decide whether that trade was worth taking.

  • Translation. The core’s data model was designed for a different era and different assumptions. Deciding where that model is translated into a modern one, and keeping that translation in one place, is the central design problem.
  • Consistency. The core is the record of truth. Anything cached or duplicated outside it is a copy that can be stale, and the system has to be explicit about which screens can tolerate that and which cannot.
  • Failure. The core will be unavailable sometimes, often in a scheduled window. The layer has to degrade in a way that is honest to the customer rather than showing a blank balance.

Audit is a design input, not a feature

In financial systems the ability to prove what happened is not something added later. Every value change needs to be answerable: what it was, what it became, who caused it, when, and through which channel. Retrofitting that into a system that never recorded it is close to impossible.

This is the argument for event-driven designs in this sector that has nothing to do with fashion. If state changes are recorded as events, the audit trail is a property of the architecture rather than a table somebody has to remember to write to.

Strangler, not big bang

The pattern that works is incremental. One capability at a time moves to the new layer, running alongside the old path until it is trusted, with the ability to route back. The core shrinks in importance gradually rather than being replaced on a date.

It is slower and much less satisfying to present. It is also the version that does not put the ledger at risk on a single weekend.

A boundary worth stating

We build to the requirements a compliance team sets and we expect them to review what we build. We hold no financial compliance certification, and any supplier who implies otherwise is worth questioning closely. Our fintech page says the same thing.

More reading

Tell us what you are building.

No sales sequence. One person reads this and replies. Rather give more detail?