Picture your core banking system as a Jenga tower. Every product tweak, integration or compliance change feels like pulling out another block and hoping the stack doesn’t topple, and the higher you build, the more every move is governed by fear rather than ambition.
For many banks, that is what hitting the “core ceiling” looks like: not just running out of capacity but reaching a point where the risk of touching the core starts to limit what the organisation can do for its customers.
Historically, financial institutions have had to choose between ease of configuration, scalability and flexibility. Whichever route they chose, at some point they would hit the core ceiling. A core that’s ready for 2040 and beyond needs to offer all, without compromise.
Go deeper with GlobalData
Access deeper industry intelligence
Experience unmatched clarity with a single platform that combines unique data, AI, and human expertise.
What the core ceiling really is
The core ceiling is a two-pronged problem for banks.
The first arm of the problem is when an architecture’s inherent scalability limits – in customer numbers or transactions per second – start to show up as visible performance issues. That might be card declines at peak times, slow response in digital channels, or an inability to keep adding new volume without painful trade‑offs in other areas.
Then there’s the other, related ceiling that banks tend to run into earlier: modification constraints. Internally, you see this as friction from code to client. Engineers struggle to make changes, adapt or move quickly because every change carries the possibility of unintended side‑effects somewhere deep in the stack. Releases become less about unlocking new value and more about not breaking what already works.
It is tempting to blame this purely on legacy mainframes, but many newer platforms end up in a similar place. Some are built around pure configuration: quick to stand up and familiar to business teams, but your ability to differentiate is ultimately bounded by what the vendor has chosen to build and what they decide to put on their roadmap.
US Tariffs are shifting - will you react or anticipate?
Don’t let policy changes catch you off guard. Stay proactive with real-time data and expert analysis.
By GlobalDataOthers offer genuine framework flexibility – giving banks the freedom to make choices on every aspect of their core – but that openness demands skilled engineering resources and careful governance. Without both, the freedom to build becomes the freedom to create your own neo‑legacy.
The open-close principle: a CTO’s Goldilocks zone
The question is how to find a middle path – one that avoids both neo‑legacy custom build and rigid configuration‑only models. For me, the most important shift is adopting an open-close principle in core design. The Open-Closed principle was first formalised by Bertrand Meyer in his 1988 book Object-Oriented Software Construction. “Software entities.” he wrote, “should be open for extension, but closed for modification.” In core banking, this would allow banks to close off the core to direct modification, but open to extension so the business can innovate safely around it.
Instead of encoding every future product variation directly inside that core, you push as much of the variability as possible into modular, composable components that sit on top or around it. Those components can be configured, combined and iterated quickly without jeopardising the integrity of the underlying system.
This creates a Goldilocks zone. You avoid rigid systems that make modification feel like pulling teeth, and you also swerve the kind of chaos where layers of one-off customisations slowly erode reliability.
The price maintenance trap
The open-close approach sounds like a no-brainer. But some platforms are architected around being the cheapest option for a particular segment, with design constraints deeply tied to price maintenance.
As these platforms approach one and a half or two million accounts, or as contactless and real‑time payments volumes grow, those design choices start to bite. This is the architectural ceiling we have highlighted before: the point at which your Jenga tower simply is not rated for any more blocks.
By contrast, architectures designed and tested from the outset for tens of millions of accounts change the question. You are no longer wondering whether the tower will stay standing; you are thinking about what you can safely build next. Capacity and extensibility are part of the same design envelope, not trade‑offs you constantly have to juggle.
Choosing how you want to grow
Ultimately, breaking through the core ceiling is about being clear on the answer to two linked questions: how far do you need to scale before the architecture gets in your way, and where do you want your innovation layer to live?
If your answer to both is “we will work it out later”, you are almost certainly building another Jenga tower. If, instead, you choose an open‑close approach – a closed, stable core with open, governed paths for customisation at the edges, and headroom for higher volumes and transaction rates – you give yourself a different future.
The tower can still grow. But each new block no longer feels like a gamble.
Miles Wilson, CTO, 10x Banking
