A few months ago, I was in a boardroom in Frankfurt with a COO who has been in the industry for thirty years. He looked at a diagram of his bank’s payment stack—a complex, tangled web of temporary fixes dating back to 2007—and sighed.

Tapan, he said, It’s like we’re trying to win a Formula 1 race while driving a vintage tractor that we’ve bolted a turbo-charger onto. It looks fast in the brochures, but I’m terrified to take the next corner.

That vintage tractor is the reality for a staggering number of Tier-1 banks across Europe and the UK. They are currently leaning on payment engines that are decades old. When a system is that old, it isn’t just legacy. It’s a liability that dictates what your bank cannot do.

The Myth of the Safe Status Quo

In banking, we are trained to believe that doing nothing is the low-risk option. But in the current European landscape, that logic has flipped.

With DORA (Digital Operational Resilience Act) and PSD3 looming, the regulators aren’t just asking if your systems work; they’re asking if they can survive the demands of current day payments. This could be payment volumes, unpredictable spikes coming from fintech clients, or high value instant payments at midnight !. For banks  running on a 19-year-old monolithic stack, the honest answer is probably no.

Every time you want to launch a new instant payment feature or adjust to a new SEPA mandate, your teams spend 80% of their time just making sure the old payment engine doesn’t explode under the pressure. That isn’t engineering; it’s archaeology. We call it an Innovation Tax, but let’s be real: it’s a slow-motion drain on your bank’s future.

Legacy payment engines built 20 years ago cannot

1. Provide smart rail selection  or Embed into ERP, TPS systems via API
2. Provide flexible payment initiation formats for  large corp clients
3. Integrate into best of breed nostro management or settlement account liquidity management systems
4. integrate easily with third party fees, relationship pricing and billing engines and have native bundled and tightly coupled capability that does not meet today’s needs
5. Provide custom PSRs – Payment Status Reports
6. integrate into modern rails like Wise, MasterCard Send, VisaDirect without months of development and testing compared to the low code no code composition of modern payment systems
7. Enable banks business or ops teams to implement a new business rule or non stp rule without downtime or may require complex “scripting” compared to the modern UI based rule condition builders and decision grids of modern payment systems
8. Enable composition or extension / modification of the payments workflow unlike modern payment engines
9. Scale. Older payment engines were designed for an era where volumes and client behavior were predictable. Banks knew that the XYZ Automobile manufacturer would send a bulk payroll file with 10,000 payments on the 25th of the month. With modern fintech clients like Tiktok, alibaba, uber, instagram you never know when a promotion will run and payment volumes will spike. In such situations older payment platforms simply collapse under the load !!
10. Embed AI into their processing. Modern payment engines can leverage AI for a range of actions like smart rail selection, derivation / validation of purpose code against free format send to receiver info, unstructured to structured address validation etc

For these and more reasons the time to change that legacy payment engine is now. Payments is the one area in banks where they receive the most customer complaints and the one area where downtime is expensive and Payments is also the area where regulatory needs and compliance obligations are the most demanding !!

So HOW does one do it… Is it like changing the tyres of a moving car ?

Why Rip and Replace is a Ghost Story

The reason banks haven’t fixed this isn’t a lack of will. It’s fear. That fear comes from the Big Bang migrations that went south—the projects that cost €100 million and ended with a board-level resignation.

But I want to challenge the idea that you have to swap the whole engine at once.

The most successful transformations I’m seeing in London and Paris right now aren’t Big Bangs. They are surgical. They are about de-averaging the problem. Banks don’t need to replace the whole 19-year-old stack on Day 1.  Banks need to think through 4 dimensions – Risk, Reward, Systemic Impact and Business Priority. For example retail payments and instant payments can be migrated first as they have the least value and therefore least risk but from an NFR angle and client / media angle are more visible ( should something go wrong) !!. They don’t bring much revenue.  On the other hand, RTGS and CBPR+  bring in much needed Fee based income and FX income respectively and are limited to a smaller client base.

Banks can sequence the migration by MOP ( Method of Payment ) or by Client Segment ( Retail, SME, Wealth, Corporate etc). Banks can also sequence the rollout of a modern payment engine by Business Product – eg Payroll or Pension Payments

The Composable Reality

At Intellect, we talk a lot about eMACH.ai, which is our fancy way of saying Common Sense Architecture. It’s about being Composable. To me, Composable just means giving a bank the right to change its mind. It means if a new regulation drops in Brussels tomorrow, you don’t need a nine-month project to comply. You swap a component. You move on. You keep your Formula 1 car on the track.

Composable architecture also allows banks to migrate from the legacy engine to a new engine based on various other factors or deployment driver keys as depicted below:

What the above means is the bank can choose to migrate all flow coming from H2H to the new payment engine  or all Inward Payments processing to the new engine or all transactions from a given “Initiator” to the new engine.

This is possible with the eMACH (Event driven, Microservices, API First, Cloud Native, Headless) architecture used in modern payment engines. This composability allows flexibility to gradually turn on capability and migrate rails, products, client segments and channels to the new payment engine

My Take

The next two years in European banking will be defined by who has the guts to admit their core payment engine is old. Not to be embarrassed by it—most of the industry is in the same boat—but to be the first to actually do something about it.

A lot of banks have even implemented SWIFT CBPR+ using temporary translators on top of  their legacy engines and that is not a long term strategic solution.

The vintage tractor served us well. It got us through the 2008 crisis and the digitisation of the 2010s. But the race has changed. The track is faster, the regulators are stricter, and the engine room needs more than just another patch.

Let’s stop pretending the old stack is stable and start building something that actually lets you sleep at night and helps you leapfrog into the future.