Modernisation is inevitable. The mistakes you can make along the way are predictable when you understand how core banking architecture decisions relate to your business.

After years working in banking, a handful of things stand out as what the industry consistently gets wrong. For example, here is a familiar story we’ve seen play out:

A bank spends months selecting the right core banking platform. They negotiate contracts, run vendor demos, align internal stakeholders, and build business cases. Then, once the transformation programme kicks-off, they discover the real problem wasn’t the platform at all.

The main lesson to learn from this common pitfall is that it was never about which core banking vendor to pick. Decision makers were not fully aligned and informed on the business impacts of modernising your core banking system. 

This article covers four important decisions on core banking architecture. It will help you navigate the decisions that define the trajectory of modernisation initiatives that need to happen before you even pick the platform. 

Where should complexity live?

Your last product launch took eighteen months. Your competitor’s took six weeks. Every release is a weekend event. Every change request is a quarterly negotiation. If that sounds familiar, there is something going on with your architecture strategy. Specifically, it’s a problem about where complexity is allowed to live.

Forget adjusting your roadmap. The real discussion is whether you concentrate complexity in one place or distribute it deliberately across a system.

The monolithic core model puts almost everything inside the platform: product logic, pricing, limits, workflow, customer data. One system holds the truth for all of it. The modular model separates concerns while the core handles transactions. Everything else lives in domain-owned services around it.

Both models are defensible and both have a cost 

Monolithic offers something reliable and predictable, but that safety comes at a price: a big core is coherent, well-integrated, and usually well-supported, yet every capability change runs through the same release cycle, so the system ends up owning your roadmap. 

Modular gives you agility, but it requires architectural discipline. Composable systems can move fast and change cheaply. But they demand integration maturity, clear domain ownership, and the engineering culture to sustain it. Without that, you get distributed complexity that is harder to debug and harder to govern.

The difference also lies in what added headcount buys you between modular and monolithic. Add engineers to a reconciliation problem and each one can own a service, a boundary, a slice of the mess. But add engineers to a monolith’s release queue and they’re all waiting on the same deploy window. The monolith has one shared release pipeline. Everyone’s changes get bundled into the same deploy, tested together, and pushed out on the same schedule. Doesn’t matter if you have 5 engineers or 50 on it, they’re all funneled through that one queue.

Choosing a monolithic core doesn’t eliminate complexity. It only defers it. When the platform can’t accommodate a product change, that complexity surfaces anyway, as customisation debt, integration workarounds, or release bottlenecks.

That’s why this is an architectural strategy decision with long-term organisational consequences, not a technology debate. Where your complexity lives determines how fast you can move, how much you depend on a vendor, and what your organisation needs to be capable of. Get that decision locked down before you select a platform

Capability extraction is a pragmatic first move

Most modernisation programmes treat core replacement as their opening move. The pragmatic ones treat it as the last move, and earn that timing by doing something else first.

That something else is known as capability extraction.

You don’t modernise by ripping out the core. You modernise by systematically moving non-transactional capabilities out of it, until the core does only what it’s actually good at. 

There are three capabilities most banks can extract without touching transaction processing:

1. Product and pricing logic. 

Most legacy cores hold product configuration deep inside platform logic. Extracting this into a dedicated layer gives you faster product launches, cleaner testing, and no more release dependency for a rate change.

2. Limit and exposure management. 

Real-time limit checks don’t need to live inside the core. A standalone service handles this with more flexibility, better observability, and no coupling to the core’s processing cycle.

3. Customer and relationship data. 

Core banking systems were never designed to be CRM platforms, so moving customer logic out significantly reduces the blast radius of any future core migration.

Limits to capability extraction

Two limits we need to be realistic about before we move on. First, the ledger and posting engine can’t be extracted. Everything around them can, but those two stay. And capability extraction takes you 70–80% of the way. It will never take you to 100%.

Watch out for false extractions. A capability that lives outside the core but still depends on the core for every decision is just the old monolith with extra plumbing.

In the end, a hollowed core leads to one of two outcomes, and both of them are wins for a modernisation project. Some banks decide the derisked legacy is good enough and run it as a permanent foundation. Others use it as the launchpad for a full replacement, with far less risk than they would have faced otherwise. Either way, the bank chooses which path makes sense on its own timeline.

How to choose between the two transformation strategies

When a bank commits to replacing its legacy core, it typically faces a choice between two well-tread strategies: Big bang replacement vs. gradual, modular replacement.

Most banks treat this like a strategy choice. It isn’t. It’s closer to a diagnosis, and the answer is mostly determined before the debate starts, being heavily dependent on the specific context your bank is starting with. 

Strategy A: Big Bang

Replace like-for-like with a new monolith. One vendor, one contract, one programme. On paper, accountability is clear and the initial scoping phase is shorter. In practice, migration complexity is brutal. Data, integrations, and business logic all move at once, and the release cadence you inherit is whatever the new platform allows. Long-term flexibility depends entirely on how well the new core ages.

Strategy B: Gradual 

Move toward a modular core with surrounding capabilities. Longer upfront design phase. Domain boundaries, integration architecture, and ownership models all have to be worked out before anything ships. In return, migration can be phased. Capabilities decouple incrementally rather than cutting over at once. The total amount of transition work isn’t significantly higher. It’s the same journey, broken into smaller pieces. You pay for that with a longer overall timeline. What you get back is dramatically lower risk at any single point in the programme.

Context matters when choosing between big bang and modular 

Big bang can work for banks with simpler product portfolios, less customised cores, and the kind of operating model that can absorb a concentrated cutover. It’s well-suited to digital banks and smaller institutions whose legacy isn’t deeply entangled with business processes. 

But for banks running deeply customised legacy cores with complex product portfolios, big bang is rarely a real option. The implementation complexity and the risk concentration are too high to absorb in a single cutover.

If your architecture team can’t answer these three questions, jumping into core banking platform selection is premature: 

• What does the core own in the target state, and what does it explicitly not own? 
• Where does integration complexity live, and who has the authority to make binding decisions about it? 
• What does the release model look like two years after cutover?

Make your core boring and put innovation elsewhere 

The best core banking systems are the ones nobody talks about. Stable. Deterministic. Invisible. That may sound like a limitation, but it’s actually the goal. 

What a core banking system should do is post transactions accurately and at scale, maintain a reliable ledger, enforce financial integrity, and integrate cleanly with the services around it. That’s it. If your core is doing more than that, it’s doing too much.

Meanwhile, keep innovation where it actually belongs: in domain-owned services that can move at their own pace, in the product layer where pricing and configuration change without a platform release, in the customer layer where experience is designed and iterated, in the data layer where intelligence is built on top of clean, accessible records.

A stable, well-bounded core creates the conditions for everything around it to move fast. A core that owns too much creates the conditions for nothing to move at all. And the technology decision and the operating model decision are the same decision.

Most transformation programmes expect the new core to be a source of competitive advantage. It isn’t. It’s simply how you keep the lights on.

Ultimately, architecture decisions are the priority 

Platform selection gets most of the attention in core banking transformation. It’s the visible part, the part with a vendor shortlist, a board presentation, and a signed contract at the end. But the decisions that actually determine whether a transformation succeeds happen before any of that.

Where does complexity live? What gets extracted before replacement even starts? What transformation strategy does your context actually support? What should the core be allowed to own once you’re done?

Get those wrong and the platform won’t save you. Get them right and the platform becomes the least interesting part of the conversation. That’s where the real work is.