I started my career in payments in 2012, helping Dutch financial institutions migrate from CLIEOP, a flat-file, batch-based local scheme, to SEPA XML. It was painstaking, methodical work.

Payment files were sent in by customers on a daily (or every-other-day) basis, where large direct debit files, often from utility companies, were generated overnight for monthly collection runs.

On the bank side, these files were validated in batch windows and settled the next business day. If something broke, you had hours to fix it before it really mattered.

That world no longer exists.

The same migration path that started with SEPA XML eventually led to SCT Inst, the European instant payments scheme. With it came a set of requirements nobody on that 2012 project had to worry about: 24/7/365 availability, rolling deployments that could never interrupt a live transaction, and core systems that simply couldn’t go offline for end-of-day processing.

The rulebook hadn't just changed. The physics had.

Over the past decade, and now working with financial institutions across Europe, I have seen that real-time rails do not just make payments faster. They remove the one thing legacy architectures were quietly depending on: time.

To understand why real-time changes everything, it helps to understand what made the old model work.

Batch payment systems were actually remarkably well-designed for their era. CLIEOP files in the Netherlands, BACS in the UK, and ACH in the US. All these systems were built around the assumption that payment execution and settlement were separated by hours, sometimes days. That gap was not a flaw. It was load-bearing.

In practice, that buffer carried more weight than people realise:

When I was working on the SEPA migration, we were essentially modernising the format of payments, moving from proprietary flat files to structured, dare I say “standardised” ISO-20022 XML. But the underlying operating model stayed largely the same. Payments still moved in batches through clearing cycles. Overnight windows still existed.

The new message standard was richer, but the timing assumptions hadn't shifted.

SCT Inst changed that. And it wasn't just a technical upgrade, but a completely different contract with reality.

Instant payment interface layers and schemes like SCT Inst, PIX in Brazil, FedNow in the US, and UPI in India all share the same fundamental characteristic: execution and settlement happen almost at the same time. Once a payment is initiated, it is resolved in seconds. There is no downstream window to catch a mistake, no batch reconciliation to absorb an inconsistency. As a result, every decision has to be made upfront. But the shift goes further than speed.

This is no longer just good practice. It is increasingly becoming a regulatory and scheme requirement.

Verification of Payee (VOP), now mandated across Europe as part of the instant payments regulation, is a direct expression of this principle. Before a payment is ever submitted to the scheme, the sending institution must verify that the account name matches the account number. If it doesn't, the payment should be flagged or blocked at the moment the customer is still in their banking app or checkout flow, able to act on the information.

This changes the entire shape of a payment flow. Steps that used to happen after execution, such as validation, fraud scoring, payee verification, and sanctions screening, now have to happen before funds move. And the best moment to surface a problem is the moment when a human can still do something about it.

It is in this shift where the architectural pressure becomes most visible. Most institutions already run sanctions screening and fraud controls before interbank settlement, which is both good practice and regulatory baseline. But real-time compression collapses the window between customer initiation and settlement to seconds, which means the meaningful question is no longer whether controls exist, but where in the customer journey they surface. Controls that technically run pre-settlement but only after the customer has left the flow leave no room for resolution. The payment either clears or fails, with no human in the loop to act on it.

The result is latency where there should be speed, and compliance risk concentrated precisely where it's hardest to absorb.

When I think back to the SCT Inst rollout, the hardest conversations weren't about message formats or scheme connectivity. They were about availability.

A core banking system designed for batch processing typically needs downtime. End-of-day runs, database maintenance, deployment windows. These were normal, expected, and scheduled.

SCT Inst doesn't care about your maintenance window. The scheme runs continuously. A payment can arrive at 3am on Christmas morning, and it needs to be processed, validated, and settled in under ten seconds.

That same constraint applies to VOP lookups, fraud checks, and sanctions screening. All of them now need to be completed within the execution window. Every component in the payment chain needs to meet the same availability bar as the scheme itself.

A fraud scoring service that's down for a rolling deployment, or a verification API with degraded response times, does not just create a technical incident. It creates a compliance failure, or a poor customer experience, or both.

The full operational implications often only became apparent under sustained production load. The architectural requirements, such as rolling deployments, active-active failover, 24/7 vendor SLA chains, are straightforward to identify on paper.

What's harder to anticipate in advance is how every downstream dependency inherits the same availability requirement as the scheme itself, and how that propagates through integrations that were never originally designed with continuous uptime in mind.

The problem has compounded as real-time has become the norm rather than the exception. Payment infrastructure is now benchmarked against card networks. Consumers expect the same speed, reliability, and invisibility from a bank transfer as they get from tapping a contactless card.

The tolerance for "the payment is processing" is gone.

The institutions navigating this shift well tend to share one thing in common: they've stopped treating compliance, fraud, data validation, and scheme connectivity as separate layers to orchestrate, and started treating them as a single, unified execution decision.

This is the shift that matters. In a real-time world, every payment is a decision made instantly, with little to no buffer for retries or correction.

That decision depends on data being structured and actionable at the moment of execution, which is what ISO 20022 is actually designed for when processed natively rather than mapped into legacy models.

It also depends on fraud and compliance controls to be embedded directly in the flow, not appended to it. And it depends on an architecture where pre-execution checks like VOP are first-class citizens of the payment journey itself, not bolt-ons that introduce latency or fragility.

The goal isn't just to be faster. It's to be correct before you're fast, catching the wrong payee, the failed sanction check, or the malformed data field in the moment it can still be resolved, rather than after funds have moved and settlement is final.

The move from CLIEOP to SEPA XML felt, at the time, like the big transformation. It turned out to be a warm-up.

The real shift, from batch to real-time, from post-execution controls to pre-execution decisioning, and from scheduled downtime to continuous availability, has changed the fundamental physics of how payment systems need to be designed.

But here's what I want to leave payments leaders with: this is not just a technology project.

Modernising for real-time payments means your entire organisation has to operate differently. IT teams need architectures that support continuous deployment without downtime. Operations teams need to move from batch-era monitoring and exception-handling to 24/7 models where issues surface in seconds, not overnight reports.

Compliance and risk teams need controls embedded directly in execution, not reviewed after the fact. And leadership needs to understand that when a scheme runs continuously, every dependency in your stack, every vendor, every integration, every internal service, inherits that same availability requirement.

The institutions that are getting this right aren't just the ones that picked the right payment connector. They're the ones that recognised real-time payments as an organisational transformation, and built, or chose, infrastructure that could support that from the ground up.

Because in real-time payments, the physics don't negotiate.

Curious how a unified payments execution layer can help your institution meet real-time demands without adding architectural complexity? Read our latest payments report on Building a future-proof payments infrastructure, or explore how Mambu Payments supports real-time execution.