Modernizing core infrastructure is moving from “someday” to “today” for banks under pressure from real-time schemes, ISO 20022 requirements, and rising regulatory expectations. Yet the classic “rip-and-replace” approach still feels like performing open-heart surgery on a person who’s working. Banks can’t stop (or even significantly reduce) payments processing while also swapping out infrastructure running those payments.

Putting that aside for a moment, for most institutions, the real choice isn’t between doing nothing and ripping everything out. It’s about deciding what to genuinely replace, what to strip back, and what to surround with modern SaaS, APIs, and orchestration layers that can deliver resilience and real-time capabilities without destabilizing the core.

This is where the conversation is changing. The thinking is moving away from grand, one-off transformation projects toward a more pragmatic, incremental mode of modernization that acknowledges both the limits and the continuing value of legacy systems.

As Bottomline’s Edward Ireland sees it, full replacement “…is tremendously risky. Your payments and cash management business doesn’t stop. It runs all the time. If you want to rip and replace, you’ve got to rip and replace while you’re on the water.” In other words, doing a total overhaul ‘at sea’ is perilous at best, and suboptimal in any case.

There are, however, very good options for adding payments functionality without disruption, or from taking on tech upgrades that are often too pricey to justify.

 

Why Some Banks Still Rip-and-Replace

Banks are not wrong to fear big-bang core replacement. Cost overruns, delays, and production incidents are well documented. But the risk isn’t only on the implementation side. For many institutions, the deeper danger lies in standing pat and doing little.

Legacy platforms that sit at the heart of payments and cash management are getting brittle, opaque, and harder to change with each passing quarter. Some can’t support ISO 20022 or rich, structured data. Others can’t run reliably in a 24/7 environment, forcing planned downtime that clashes with faster payments propositions.

In some cases, the underlying data model is so poor that even “simple” regulatory changes or new product rollouts become disproportionately difficult to build in.

“If the way [the bank] structures basic information on underlying account holders is essentially a big block of text, that’s very difficult to manage given everything they may want to do in the future,” he says. In those situations, “it’s rip, replace, and restructure.”

He added that these initiatives are also rare for a reason. Full core replacement “doesn’t happen very often,” he said, and when it does, it’s usually tied to something big, like “a restructuring or purchase or a significant investment for the bank itself.”

But there comes a point where the drag from legacy stops being a productivity issue and becomes an elevated business risk. “You can actually hit a roadblock with a legacy system where you simply cannot implement mandatory change,” Ireland warns. “The short-term disruption of a replacement is always there, but it’s up to you to manage that risk. You can’t manage the inability of a legacy system to implement a new mandatory change.”

Therefore, the question isn’t whether rip-and-replace is risky. It’s whether carrying the full cost and rigidity of legacy systems is even riskier.

 

Why Modernizing Legacy Cores is the Norm

Despite the rhetoric, most banks are not tearing out their entire estates. What’s really happening is more nuanced: legacy platforms are being stripped back to their most stable, indispensable components, while new capabilities are layered alongside.

“What we’re seeing is legacy systems being stripped down to core elements,” Ireland explains. In practice, that often means the old platform is reduced to “the core ledger…the general ledger,” while new applications deliver capabilities around it, from payment orchestration and customer-facing services, to reporting and analytics.

That visual is telling. Walk through many back offices today and “you’ll still see green screens, which is the old system, still running in the background. It’s not being used for anything day to day, but it’s maintaining positions,” he says. “There’s still an interface to it.”

That is coexistence in its purest form. The bank avoids destabilizing the ledger while moving forward with modern components that move faster and meet new technology demands.

This approach is reinforced by a broader change in deployment models. Traditional on-premise implementations “encouraged customization,” Ireland says, and vendors sold bespoke adjustments as a major differentiator. That model is breaking down. When you’ve heavily customized a dated banking system, “You can’t take the standard upgrade because you’ve done a [different] configuration. You don’t know if it’s going to work.”

Ireland’s verdict is blunt: “Customization is no longer a USP. Standardization is [the] USP.”

That’s why banks are increasingly looking to standardized SaaS and cloud services for payments, connectivity, and surrounding capabilities. “It’s much easier and more feasible for a specialist provider to provide [resiliency, availability, and scalability] than it is for each individual payment service provider and bank,” he says.

The pattern that emerges is consistent. Keep the ledger stable, surround it with standardized services, and connect everything through clean, well-governed interfaces.

 

Building for an Unknown Future

If there’s one thing banks can be certain of, it’s that they don’t yet know everything they’ll need to support down the line. Tokenized deposits, stablecoins, new real-time schemes, and new compliance requirements will all test the flexibility of all features added now.

“You don’t know exactly what you’ve got to implement,” Ireland says. Regulatory timelines tend to be signposted, but innovation rarely asks for permission. What is clearer is the integration pattern. “What we do know is that [upgrades] will invariably be based on APIs as the standard protocol. What you need to have are good integration capabilities for whatever you deploy” if you want to be ready to embrace the next payment rail or payment data format.

Instant payments are a vivid example. Banks and PSPs increasingly see them as a must-have, yet the operational reality is sobering. Legacy environments designed for batch windows and overnight processing struggle mightily in a 24/7 world.

Ireland describes working with banks that “have been willing to invest” in an instant payments proposition, only to discover that “when they look at their legacy systems and their operational process, it’s a massive lift for them.” And it goes wrong other ways, too.

In this landscape, the FIs that move best share three traits:

  • They treat modernization as a risk and business model decision, not an IT upgrade.
  • They invest in clean data models and API-first integration as core strategic assets.
  • They embrace standardized, cloud-based services where it makes sense, rather than reinventing every wheel internally.

For vendors and partners, rip-and-replace moments are inflection points. “Rip and replace is always an opportunity for us,” Ireland says, because it opens the door for banks to rethink not only their core platforms, but also who they trust for connectivity and orchestration.

For banks, the message is more practical. You don’t have to solve everything at once, and you don’t need to own every component. The real goal is an architecture that can keep growing, and that lets you modernize while you’re still “on the water,” without sinking.