Across retail banking, we spend a lot of time talking about channels, journeys and experience. Very few conversations start with the core system that actually runs the ledger, posts interest, settles card transactions and reconciles end-of-day balances. Yet every mobile app, every merchant terminal and every instant payment ultimately depends on that invisible machinery.
When the core works, nobody notices. When it fails, everything stops. For customers, an outage is not a technical issue; it is a question of confidence. For regulators, it is a question of resilience. For boards, it is a question of survival.
Having spent much of my career in environments where millions of accounts and transactions move every single day, I have come to believe that the next decade of competitive advantage in retail banking will be decided not by the latest interface, but by the quiet strength of the systems behind the screen. The banks that treat core architecture as a strategic asset will set the pace. Those that postpone the conversation will find themselves constrained by their own past.
Go deeper with GlobalData
Access deeper industry intelligence
Experience unmatched clarity with a single platform that combines unique data, AI, and human expertise.
This article looks at that reality through a practitioner’s lens: how we got here, why the pressure is rising, and what serious, long-term modernisation really requires.
The quiet machinery of modern banking
Every retail bank, whatever its brand or geography, rests on the same basic disciplines. Money must be recorded accurately. Interest and fees must be calculated correctly. Debit and credit entries must balance. Transactions must either complete or fail; they cannot be half-done. These disciplines are enforced by the core banking system.
For decades, this machinery was designed for a world of branch hours and overnight processing. Customers deposited cash during the day, the system processed in batches at night, and balances were updated for the following morning. The pacing of technology and the pacing of the customer were roughly aligned.
Today that rhythm has disappeared. Customers expect to move money at any time, on any device, across any rail. Salary credits, bill payments, subscription debits, card transactions, instant transfers and merchant settlements all hit the bank continuously. The expectations of the outside world have shifted to real time, but many of the internal systems are still operating on a daily heartbeat.
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 GlobalDataMost institutions have responded by adding layers on top of the core: channel systems, payment hubs, fraud engines, data warehouses, API gateways. These layers create flexibility at the edges, but they also introduce complexity in the middle. Every new workaround adds another dependency. Every new interface adds another potential point of failure. Slowly, the bank becomes a cluster of systems rather than a single, coherent platform.
The result is a paradox. On the surface, the bank looks modern. Behind the scenes, it may be running code that predates the internet.
How legacy cores were built – and why it matters
To understand the constraints of today, we have to remember how many cores were originally constructed.
Most large retail banks still rely on systems built when mainframes were the only realistic option for high-volume processing. These platforms were engineered by teams who had deep understanding of accounting and control, but who could not have imagined mobile phones, real-time payments or cloud computing. The designs were optimised for stability, not change.
Over time, as new products emerged, banks did not always re-architect the core. They bolted on specialist modules: a separate card system, a separate loan system, a separate deposits engine. Mergers and acquisitions brought still more platforms, each with its own rules and data structures. Overnight, the “core” became a federation of systems, stitched together by interfaces, reconciliations and manual workarounds.
This history matters because it explains why change can be so difficult. A simple product tweak in the front end can trigger a chain reaction across multiple back-end components. A regulatory update that looks minor in a policy document can require hundreds of code changes across different systems. The organisation gradually learns that altering the core is risky, slow and expensive. Caution becomes the default.
The irony is that the very systems built to guarantee reliability now make it harder to deliver the reliability that a digital world demands.
When real-time expectations meet yesterday’s architecture
The pressure on core systems is no longer abstract. It shows up every day in operations rooms, incident bridges and customer complaints.
Real-time payment schemes require balances to be checked and updated instantly. Card networks expect authorisation responses in fractions of a second. Fraud controls need live access to transaction streams, not yesterday’s files. Regulatory stress testing requires granular history over long periods, held in consistent formats. Customer apps expect a single, consolidated view of the relationship, even when the underlying data sits in multiple systems.
Legacy cores were never designed for this pattern of demand. They are strong at batch processing but less suited to continuous interrogation. As a result, banks often create shadow systems and caches to protect the core from excessive queries. These shadows improve performance, but they introduce another problem: keeping everything in sync. The more copies of critical data exist, the harder it becomes to ensure that “balance” means the same thing everywhere.
From a customer perspective, this shows up as small irritations: transactions that appear in one channel but not another, balances that differ between screens, delays in reflecting card spends or refunds. From a bank’s perspective, it shows up as operational risk: reconciliations that take longer, investigations that require manual intervention, and a rising probability that something will break under load.
At some point, every institution reaches the same conclusion: incremental patching is no longer enough. The underlying architecture needs to be addressed.
The human reality in the engine room
It is tempting to think of core systems purely as technology, but in practice they are sustained by people.
In every bank there is a group of specialists – often long-serving, often modest in profile – who understand how the ledger actually behaves. They know which jobs run at what time, which interfaces are fragile, which reports must be checked before the start of day. Their knowledge is rarely documented in full. It lives in their experience, built up over decades of nightly cycles.
These teams carry an enormous responsibility. When a migration is planned, they are the ones who understand the practical consequences of each cutover step. When a new channel goes live, they are the ones who monitor whether postings are landing correctly. When something fails at two in the morning, they are the ones who piece together the sequence of events and restart the process.
Any discussion of core banking rewrites that ignores this human dimension is incomplete. Architecture is not just diagrams; it is routines, handovers, call-out lists and quiet judgement. Senior leaders sometimes underestimate the strain this places on operations staff. Continuous change programmes, compressed timelines and competing priorities can exhaust the very people the bank most depends on.
A responsible modernisation agenda must therefore protect, respect and extend this expertise. If the people who understand the current system are sidelined in favour of external narratives, the organisation risks repeating old mistakes under new labels.
Rethinking risk and resilience
When boards discuss core transformation, the conversation usually centres on classic project risks: delivery slippage, budget overrun, vendor failure. These are real concerns, but they are not the only ones.
The deeper risk is loss of control. As more functionality is outsourced or delegated to external platforms, the bank can become dependent on technologies it does not fully understand. Contracts may define service levels, but they do not automatically guarantee operational literacy. A bank that cannot explain how money moves through its own systems is already exposed.
True resilience requires more than redundant data centres and backup lines. It requires clarity: knowing which systems are authoritative for which data; knowing how a transaction flows from channel to ledger; knowing how to unwind a process when something goes wrong. This clarity is often missing in organisations where complexity has accumulated gradually.
Modernisation should therefore be framed not as a leap into the unknown, but as a disciplined reduction of fragility. Each redesign should simplify flows, reduce manual workarounds and bring the ledger closer to real time. Each decision should be tested against a simple question: “Does this make it easier or harder for us to understand and control our own system?”
When viewed through this lens, investment in core renewal is not optional. It is a form of risk mitigation, as fundamental as capital planning or liquidity management.
Paths to change without shutting the bank
The hardest question is practical: how can banks modernise the core without disrupting daily operations?
Over the past decade, a number of patterns have emerged that allow for gradual, controlled change.
One approach is to build a new core alongside the old one and migrate products in phases. This “parallel core” strategy spreads risk over time but demands rigorous data mapping and strong programme governance. It works best when the bank can clearly segment products and customer groups for staged migration.
Another route is progressive decoupling. Here, the bank keeps the existing ledger but systematically moves surrounding functions – such as product logic, pricing, fees and limits – into more flexible services around the core. Over time, the core is slimmed down to its most essential role: a highly reliable engine for posting and storing balances. The agility comes from the surrounding orchestration layer.
A third pattern involves creating specialised sub-ledgers for high-volume areas like cards or instant payments, which then feed a general ledger for regulatory and financial reporting. This can reduce load on the main core while enabling richer functionality in specific domains.
Each model has trade-offs – none is a magic solution
What matters is that the bank chooses deliberately, with a clear view of how architecture, operations and balance sheet objectives intersect. Quick wins are attractive, but a patchwork of partial solutions can leave the institution more complex than before.
The banks that succeed in this journey tend to share a few disciplines: they invest early in high-quality data migration, they keep controls simple, and they ensure that business and technology leaders share ownership of the outcome.
Leadership, governance and the danger of “innovation theatre”
Core transformation is not only a technology programme; it is a governance test.
Boards and executive committees are under constant pressure to demonstrate innovation. New digital launches, partnerships and slogans are highly visible. Core renewal, by contrast, is slow, detailed and largely invisible. It is easy for leadership attention to drift away from the hard, unglamorous work of rewriting the systems that actually run the bank.
This is where the danger of “innovation theatre” arises. An institution may accumulate impressive front-end features while leaving the underlying architecture unchanged. For a while, this can create the appearance of progress. But when volumes spike, or new regulation arrives, or a system fails, the unresolved structural weaknesses become obvious.
Serious governance requires the opposite mindset. It means allocating board time to questions that are technical but fundamental:
- Do we know which systems are truly core?
- How many manual reconciliations still exist between them?
- Where are our single points of failure
- How often do we test recovery, not just in theory but end-to-end?
- Are we comfortable that our talent pipeline includes people who can lead the next generation of core engineering?
It also means resisting the temptation to treat modernisation as a one-off “programme”. Architecture is not a project; it is an ongoing responsibility. Just as credit risk is monitored continuously, so too should system health and complexity be tracked over time.
Ultimately, the tone is set at the top. When leadership values stability and depth as much as visible innovation, teams are more willing to raise uncomfortable truths about legacy constraints. That, in turn, is the starting point for genuine renewal.
What the future core will really look like
Looking ahead, it is unlikely that there will be a single “perfect” model of core banking. Different markets and institutions will make different choices. However, certain characteristics are emerging as common reference points.
The future core will be modular rather than monolithic. Key capabilities – customer profile, account engine, payments, pricing, limits – will be separable, so that each can evolve without destabilising the whole. Interfaces will be standardised and well documented, reducing the dependency on individuals.
It will be event-driven, able to react to transactions and status changes as they occur, rather than waiting for end-of-day batches. This does not mean that everything must be instant, but it does mean that the bank can update views of risk, liquidity and customer exposure in close to real time.
It will be designed for observability. That word simply means that engineers and operators can see what is happening inside the system: which processes are running, where delays are building, which services are under strain. Without this visibility, no amount of capacity planning will prevent surprises.
Crucially, the future core will be built with failure in mind. Components will be designed to degrade gracefully rather than collapse abruptly. Fallback paths will be tested in practice, not just written in documents. Communication protocols – both technical and human – will be rehearsed so that when something does go wrong, customers experience clarity rather than confusion.
None of this is about chasing fashion. It is about implementing, in technology, the same prudence and discipline that good bankers have always valued.
A quiet advantage: reliability
In a world full of new entrants and new interfaces, the temptation is to compete on novelty. Yet when customers are asked what they truly value from their bank, the answers are simple: “My money should be safe, my payments should go through, and when something goes wrong, someone should help me.”
Reliability sounds unexciting, but it is the foundation on which every other promise rests. A bank that repeatedly struggles with outages or reconciliation issues will find that no amount of marketing can repair the damage. Conversely, a bank that quietly delivers day after day earns a trust that is hard to disrupt.
Core modernisation is therefore more than an IT agenda; it is a brand agenda. The institution that invests in strong, well-governed, understandable architecture sends a message to customers, regulators and staff: “We take our responsibilities seriously. We are here for the long term.”
In a crowded market, that quiet message may prove to be the most powerful differentiator of all.
Closing reflection
Retail banking has always been about more than technology. It is about people, responsibility and the everyday confidence that money will be where it is supposed to be. Yet technology is the medium through which that confidence is now delivered.
For many years, the industry has pushed its core systems to stretch just a little further: one more product, one more channel, one more integration. We are approaching the limits of that approach. The next decade will require not just extensions, but deliberate rewrites of the architecture that sits at the heart of retail finance.
The banks that treat this as a central leadership task – not a specialist project somewhere in the back office – will be the ones that shape the future landscape. They will be able to respond to new payment schemes without panic, launch new services without destabilising the old, and support customers through shocks without losing control of their own systems.
In the end, the most advanced bank may not be the one with the flashiest app, but the one whose core is so dependable that customers rarely have to think about it. The real transformation will happen not on the screen, but behind it.
Dr. Gulzar Singh, Senior Fellow – Banking & Technology; CEO, Phoenix Empire Ltd
