Banking’s Real-Time, Always-On Era Has a ‘Core’ Problem

By K R Venkatraman, VP & Global Head of Product Architecture and Sudhindra Murthy, Associate Director – Product Marketing, Infosys Finacle

Banking is in the middle of a genuine success story, and the numbers tell it well. According to BCG, real-time A2A payment volumes rose 40% globally in 2024, accounting for around a quarter of digital retail payments worldwide. Within the euro area, 35 retail payment systems processed around 55.7 billion transactions with a combined value of €26.2 trillion in the first half of 2025, as suggested by the European Central Bank’s report.

Real-time payments have gone mainstream. Wallets and embedded finance have made banking feel invisible, in the best way. BNPL has reshaped how customers think about credit. Merchant ecosystems have grown richer and more interconnected, with banks sitting at the centre of an expanding web of partners and platforms. Customers, for their part, have come to expect all of this to simply work, anytime, on any device, without a second thought.

This is, by most measures, exactly where the industry wanted to be. But every one of these wins carries a quiet side effect. Transaction volumes are climbing to levels few institutions anticipated, and an expectation of 24×7 availability that leaves almost no room for downtime. A brief outage today doesn’t just inconvenience a handful of customers; it can ripple through merchant operations, dent trust, and draw the kind of attention regulators don’t forget. Layered on top of all this is the ongoing need to keep innovating, rolling out new products and experiences, without ever letting existing services slip.

It’s a good problem to have, in the sense that it comes from growth. But it is still a problem, and it’s landing squarely on a part of the bank that was never designed to absorb it: the core.

Why is core feeling the pressure

Most core systems were built for a different time, when batch processing, predictable volumes, and infrequent change were the norm. Many of these systems have served their institutions faithfully for decades, which is part of why they’re still around. But that same longevity means every new product, every integration, every workaround added over the years has made the system a little more rigid. Ask a platform built for end-of-day settlement to handle real-time, high-concurrency volumes, and performance strain is the natural result. Ask it to support continuous releases without disrupting live operations, and agility tends to be what gives way.

A full core replacement can feel like the obvious answer here, and for some banks, at some point, it may well be the right one. But for most, today, it’s a tall order as it’s high-risk, capital intensive, and disruptive enough that it can take years to deliver, with real execution risk along the way. That’s a hard case to make when the existing core, whatever its limitations, is still quietly doing its job every day.

So many banks find themselves weighing two paths that both feel uncomfortable. One, keep asking more of an ageing core. Two, commit to a transformation large enough to put current stability at risk in pursuit of future flexibility.

A third path: rebalancing around the core

There’s a more pragmatic way through this, and it doesn’t require touching the core at all. Instead of replacing it, banks can rebalance the architecture around it, letting the core keep doing what it does best, serving as the system of record, while the pressures that are actually causing strain get redistributed elsewhere.

A few principles seem to be emerging as the foundation for this kind of approach.

Decouple transaction velocity from the core. Not every transaction needs to touch the core in real time. By redistributing high-frequency, high-concurrency workloads to sit closer to where they originate, banks can absorb fintech-scale volumes without asking the core to scale beyond what it was built for.

Orchestrate ecosystem flows with intention. Banking today rarely happens in isolation. It runs through a web of merchants, partners, and third-party services. That kind of complexity benefits from structured orchestration rather than ad hoc integration, so that ecosystem growth doesn’t quietly translate into core strain.

Design resilience in, structurally. Availability shouldn’t depend on core uptime alone. With the right architecture, a core maintenance window, an upgrade, or even an unplanned issue doesn’t have to mean a customer-facing outage. Resilience works best when it’s built into the design, not left to chance.

Modernise the core progressively, by hollowing it out gently. Rather than one large, disruptive cutover, banks can gradually move the most change-intensive functions, the ones needing frequent updates and carrying the most operational risk, out of the core and into more flexible layers. Done well, this extends the core’s useful life while steadily easing the risk concentrated within it.

What this looks like in practice

The architectural construct that brings these principles to life is increasingly being referred to as a thin ledger transaction manager, a purpose-built platform that sits between the core and the outside world. Rather than replacing the core operations, it absorbs the low value, high volume transaction demands that the core was never designed to handle, while keeping the core intact as the authoritative system of record. Using the same principles, any set of transactions can be routed to the thin ledger to facilitate hollowing the core at a fraction of the cost and yet, offering a higher availability quotient. It lets banks meet today’s scale, resilience, and innovation demands without dismantling the systems that still hold everything together.

The platform is built around a clear set of capabilities. It sustains always-on operations independently of core uptime, so that maintenance windows or unplanned disruptions never translate into customer-facing outages. It handles high concurrency at sustained low latency, absorbing volume spikes without pressure flowing back to the core. It orchestrates the flows, settlements, and reconciliations across an expanding merchant and partner ecosystem. And it also enables change-intensive functions to migrate out of the core gradually, turning what could be a tactical fix into a credible long-term modernisation strategy.

Together, these capabilities define what it means to operate at the standards customers, merchants, and regulators now expect — without replacing the core to get there.

The payoff for rebalancing is mighty

Banks that take the thin ledger transaction manager approach tend to gain something valuable. They become more resilient to disruption, since uptime is no longer riding entirely on one legacy platform. They can start operating at the concurrency and latency levels customers now associate with fintech challengers, without needing to replace the core to get there. They can modernise at their own pace and risk appetite, rather than betting the institution on one large transformation programme.

None of this makes the core less important. If anything, it lets the core finally do what it does best, holding the system of record steady, while everything built around it is free to move at the pace the market now expects.

The banks that recognise this distinction early, between modernising the core and modernising around it, are likely to be in a far more comfortable position the next time volumes spike, a competitor moves fast, or a regulator starts asking pointed questions about resilience.