Payments modernisation has crossed a threshold where compliance deadlines are now driving infrastructure decisions, not the other way around
The standard objection to payments modernisation investment is that existing systems still work. Billions of transactions are processed daily without failure, batched reconciliation delivers on its two-hour cycle, and the rails run. With this in mind, the business case for transformation can look like spending money to fix something which isn’t broken.
What tends to break the argument open is a compliance deadline, such as a bank committing to SEPA Instant, or pursuing direct participation in a faster payments scheme. Organisations typically arrive at a project believing it is just a connectivity exercise.
Then it discovers its core banking system feeds the payments engine in batch, and that an instant payment hitting the scheme will sit waiting for the next batch cycle before the account is updated.
“If you want to move to real-time payments, you need to go real time everywhere,” Jeremy McDougall, Strategic Solution Consulting Director, at ACI Worldwide tells Payment Expert at PAY360 2026.
“Operations, monitoring, cut-off times, everything.” The compliance project has become an architecture project, and a board that approves a connectivity budget is now being asked for something considerably larger.
This is increasingly the pattern through which legacy infrastructure gets modernised – not through a proactive transformation programme, but through an operational reality where real-time regulation cannot be grafted onto batch-era systems without touching more than was planned. The CASS 15 safeguarding regime in the UK, with its 7 May 2026 deadline, for instance, is throwing up examples of this very issue.
Firms approaching it as a compliance checkbox are finding that it pulls on threads which run deeper than the compliance team anticipated.
“The real issue,” Serhii Zakharov, CEO and Founder of PayDo, tells Payment Expert, “is the hidden operational drag that builds up over time around that infrastructure – duplicated processes, poor data visibility, complex reconciliation, repeated compliance work, and too much leadership time spent managing workarounds instead of focusing on growth.”
Build, buy, and the systems nobody designed
Sitting beneath the compliance question is the long-running build versus buy argument; though it may be more accurate to say the large operators have accumulated in both areas. An e-commerce business which has been running for fifteen years typically has an acquirer relationship it established in the UK, three more added for European expansion, a couple of banking rails bolted on as open banking matured, and another layer added for Latin America.
“They’ve [organisations] built these carbuncle-like systems,” Mike Peplow, Chief Operating Officer at Paysecure says to Payment Expert, “and now agentic payments are on the horizon, and they’re going back to shareholders asking whether to spend another five years fixing their existing systems.”
The case for buying – for selecting a specialist provider rather than continuing to build internally – rests less on cost than on what Aaron Holmes, CEO and Founder of Kani Payments tells Payment Expert is the focus problem.
A neobank whose engineering team spends most of its time on reconciliation infrastructure is not, in any meaningful sense, focused on being a neobank. “Your core business is the payment product,” Holmes says. “Reconciliation is the side thing you have to do to make the main thing work.”
A vendor which does nothing but reconciliation has competitive pressure to be excellent at it; an internal team managing it alongside everything else does not.
The build argument has its place, especially when you consider the scale of a JPMorgan, for example. Its internal development gives it control and ensures it can retain institutional knowledge.
But for smaller organisations, Holmes says those which choose to build rarely do it in the way that would actually justify the decision. The outcome is usually either an expensive project that underdelivers, or a patchwork of Excel spreadsheets and isolated databases that nobody has authority to decommission. “If they understood the build in the right way and baked the right expertise in from the outset, they can make it work,” he says. “But from my experience, the buy route tends to be the best approach for SMEs.”
Zakharov’s framing of where that logic applies is useful: build only makes sense within your own field. “As a consumer business, you are not expected to develop your own fintech,” he says. “You should select the best available solutions and focus on your core product.”
The data layer nobody is fully using
ISO 20022 is far enough into its migration cycle that the industry has largely moved past debating its merits and onto discussing what to do with it. The operational benefits are already visible in fraud and sanctions workflows. Under the old MT message format, an unstructured reference field reading “I ran a marathon” could – and did – trigger a sanctions hold because the first four characters matched Iran‘s country code, says McDougall.
Structured, tagged fields eliminate this class of false positives; Swift has cited a reduction in sanctions-related payment delays as a direct result of the migration.
What the industry has been slower to exploit is the commercial layer the standard makes possible. Purpose codes allow corporations to tag transactions with the nature of the underlying activity – trade finance, payroll, tax. That context is available to every institution in the payment chain and creates a data layer that didn’t previously exist. “There’s a lot more we can do with the data,” McDougall says. “I don’t believe it’s being fully utilised.”
The downstream value, Zakharov argues, runs well beyond payments teams: “When payment messages carry better structured information, businesses can improve reconciliation, automate more of their internal workflows, reduce manual intervention and gain much clearer visibility across payment flows – better data creates the foundation for faster exception handling, better reporting and more intelligent automation.”
Holmes’s qualification is that ISO 20022 standardisation on one side of a reconciliation doesn’t help when the counterparty data is still proprietary. The proliferation of new payment providers, each with their own data formats, means the reconciliation challenge is in some respects more complex than it was a decade ago, not less.
Timing differences, currency mismatches and format fragmentation persist regardless of what standard the underlying payment message uses.
The vendor problem at the centre of resilience
The Digital Operational Resilience Act (DORA) makes explicit something that payments infrastructure has always had to manage: the firms responsible for operational resilience are often most dependent on the third parties whose failure would most undermine it. The accountability structure doesn’t change – regulated firms hold the licence and answer to the regulator – but the practical question of how to maintain meaningful oversight of vendors whose systems are deeply embedded is not straightforwardly answered by an attestation process.
“The answer is not to avoid dependency altogether – that is unrealistic,” Zakharov says. “The answer is to be much more intentional about where dependency sits, whether it increases or reduces your control over the payment environment, and to have a proper contingency plan.”
The concern Holmes flags is that firms under CASS 15 deadline pressure may deploy AI-based solutions that appear to deliver the required outcome but haven’t been tested against the edge cases that matter. “I do worry that some firms will reach that date believing they have a compliant approach and find out very quickly that they don’t.”
The obstacle with agentic payments isn’t routing or processing – payments infrastructure can handle the transaction once it’s authorised. The issue is how authorisation takes shape when an AI is doing the initiating.
“It’s not here yet. Six different protocols have been issued – Visa, Mastercard, Checkout, Google. As a merchant, you’re going: I have no idea which one this is going to be,” says Justin Fraser, Chief Revenue Officer at Yaspa to Payment Expert.
There is no settled framework for identity, authorisation and liability when an agent acts. Protocols have been issued by major card schemes and processors in the past year, none of them yet dominant.
Payments will absorb agentic workflows eventually, but “probably last”, adds Fraser, because the cost of getting authorisation wrong in payments is higher than in almost any other domain, and the regulatory framework for managing that cost doesn’t yet exist.
“To give an agent the right to pay on your behalf,” Peplow says, “you need to be absolutely sure it’s your agent, with the right permissions, the right authorisations, the right safeguards.” That bar is not close to being cleared.
