Europe’s payment rules are leveling up and the response requires more than a new policy doc.
The upcoming deadlines will call for actual production systems that keep money moving. Real-time payments, Verification of Payee, sharper fraud controls, better APIs, new consent flows. All of it has to work smoothly inside infrastructure that’s already handling millions of transactions and the deadlines won’t be forgiving.
That changes the nature of the challenge. Banks don’t want to slow down their broader modernisation efforts, but it’s now necessary to turn regulatory requirements into production-ready technology in parallel.
Two regulatory waves are particularly important and coming up fast.
- The EU’s Instant Payments Regulation and Verification of Payee requirements (January 2027 obligation to receive instant payments, July 2027 obligation to send instant payments and offer VoP).
- PSD3 and the Payment Services Regulation (PSR), which will introduce another set of changes to how banks expose services, manage customer access and prevent fraud.
This article will take a closer look at what compliance will entail and the overlapping engineering concerns it will bring, so you can be better prepared.
The first wave: instant payments and Verification of Payee
The EU’s Instant Payments Regulation is changing the baseline for payments across Europe.
Specifically, this will touch on SEPA, the Single Euro Payments Area that already connects euro payments across more than 40 countries.
SEPA Instant itself isn’t new; it’s been available since 2017. What’s changed is that it’s no longer optional.
Banks and payment service providers operating in SEPA are now required to both send and receive euro credit transfers within a maximum of ten seconds, around the clock. The question is, how will the infrastructure and resources they have support this.
Alongside this, the regulation introduces SEPA Verification of Payee (VoP), which requires payment service providers to check whether the name a customer enters matches the name on the recipient’s account before the payment goes through.
On the surface, it sounds straightforward.
In practice, it’s a real-time engineering problem.
The verification needs to happen as part of the payment journey, without introducing unacceptable friction for the customer. Systems need to respond within seconds and remain available around the clock. They also need to handle the realities of customer data: differences in spelling, abbreviations, legal names, company names and other variations that make an exact string comparison insufficient.
To complicate it further, that service needs to work at scale.
That means banks need to think about much more than the matching algorithm itself. They need to integrate with the relevant payment and routing infrastructure, design the interaction with their existing payment flows, handle exceptions and failures, monitor performance, and ensure that the system remains resilient under real-world transaction volumes.
This is a useful example of a broader trend in financial regulation:
A regulatory requirement can look simple at the policy level and become significantly more complex once it reaches production.
The deadlines are already here
For banks in the euro area, the first major implementation deadlines have already passed.
For euro area banks, the rollout actually happened in two steps, not one. From 9 January 2025, PSPs had to be able to receive instant euro credit transfers. From 9 October 2025, they had to be able to send them and, at the same time, offer Verification of Payee and equal pricing between instant and standard transfers.
The same two-step pattern will repeat outside the euro area, including Poland, Czechia, Hungary and Romania. The obligation to receive instant payments lands on 9 January 2027, ahead of the July 2027 deadline to send them and offer VoP. That gap matters for planning. Receiving capability, sending capability and payee verification are three separate engineering builds, not one switch to flip on a single date.
This creates a very different kind of pressure.
A bank can’t wait until the regulatory deadline is approaching to start thinking about architecture, integration and testing. Payment infrastructure has long delivery cycles, and changes have to be introduced without disrupting systems that customers and businesses depend on every day.
The engineering work required to reach needs to be planned, designed, integrated, tested and operated well before that deadline arrives.
The second wave: PSD3 and PSR
While banks are implementing instant payments and Verification of Payee, another regulatory shift is moving closer.
PSD3 and the Payment Services Regulation represent the next stage of the EU’s effort to modernise payments and strengthen the rules around open banking, fraud prevention and customer protection.
For banks, the implications extend beyond compliance documentation.
They include changes to the technology that sits behind digital financial services.
Banks will need to provide more robust and reliable interfaces for third-party access. They will need better ways for customers to understand and manage which services can access their financial data. And they will face additional requirements around fraud prevention, authentication and liability.
In other words, another set of regulatory requirements will translate into another set of engineering projects.
The exact implementation timeline depends on the final legislative process and the applicable transition periods, but the direction is clear: banks should be preparing their technology organisations now rather than treating PSD3 and PSR as a problem for a future compliance team.
Compliance is competing with the rest of the roadmap
This is where the problem becomes bigger than regulation.
A bank’s engineering organisation is already responsible for keeping critical infrastructure running, migrating legacy systems, improving digital channels, launching new products, strengthening security and responding to changing customer expectations.
Now it also needs to deliver regulatory-driven changes to some of the most sensitive parts of the technology stack.
That creates a capacity problem.
The challenge isn’t whether banks can build these capabilities themselves. Most large banks have substantial engineering organisations and deep technical expertise.
The challenge is whether those teams can deliver regulatory programmes quickly and safely while continuing to build everything else the bank needs.
This is particularly difficult when the work touches legacy payment infrastructure.
A modern API can be relatively straightforward to build in isolation. Integrating that API with a payment system built years or decades ago is a different problem.
The same applies to fraud detection, instant payments and Verification of Payee. Each capability may be familiar in isolation. The complexity comes from making it work reliably across the bank’s existing architecture, processes and customer journeys.
Regulation creates the deadline, but engineering creates the challenge
For banks, the emerging regulatory landscape can therefore be understood as three connected problems.
Regulation creates the deadline.
The requirements are not optional, and the implementation windows are defined by legislation.
Legacy infrastructure creates the complexity.
New capabilities have to operate alongside systems that were not necessarily designed for real-time payments, modern APIs or today’s fraud environment.
Engineering capacity creates the bottleneck.
The same teams responsible for regulatory delivery are often responsible for the bank’s broader transformation agenda.
That combination makes external engineering expertise increasingly valuable.
Not because banks cannot build these systems themselves, but because they may not want to allocate their entire internal capacity to building them.
The implementation gap
There is also an important distinction between knowing what needs to change and actually delivering it.
A bank can have a regulatory roadmap, a target architecture and a detailed list of requirements and still face months of difficult implementation work.
Someone needs to turn requirements into production software.
That means designing the architecture, integrating with existing systems, building the required services, testing edge cases, managing dependencies, and getting the solution safely into production.
This is particularly important for payment infrastructure, where “almost working” is not an acceptable outcome.
A Verification of Payee service needs to work when traffic is high. An instant payment needs to remain instant at 3 a.m. A fraud control needs to identify suspicious behaviour without creating unnecessary friction for legitimate customers.
The engineering quality of the implementation directly affects the customer’s experience—and, ultimately, the bank’s operational risk.
CEE shows what the challenge looks like in practice
The pressure is particularly visible in Central and Eastern Europe.
Poland, Czechia, Hungary and Romania are all dealing with the transition to the new European payment requirements, but their domestic payment infrastructures and approaches are different.
Romania already has domestic VoP capabilities that need to align with the European framework. In Czechia and Hungary, banks face their own integration and implementation decisions as they work toward the 2027 requirements.
In Poland, that centralised infrastructure sits with KIR, the operator of the country’s Elixir and Express Elixir clearing systems, which is building the Verification of Payee capability that Polish banks will connect to ahead of the 2027 deadline. Romania’s starting point is different: a domestic confirmation-of-payee service called SANB has been running since 2022 through Transfond, the national automated clearing house, and several major banks already use it. The work ahead for Romanian banks isn’t building payee verification from zero — it’s reconciling an existing domestic solution with the standardised, pan-European VoP scheme.
The broader lesson is important:
The regulation is for the whole EU, but implementation needs localised care
Banks still need to work within their national payment infrastructure, existing technology stack and specific operating model.
That makes implementation expertise and regulatory interpretation equally important.
What banks should be thinking about now
For technology and product leaders, the important question is not simply “Are we compliant?”
It is:
What has to change in our technology stack to become compliant—and how do we deliver that change without slowing down the rest of the bank?
That means looking beyond individual regulatory requirements and understanding the engineering dependencies between them.
For example:
- Which payment systems need to support instant processing?
- Where will Verification of Payee sit in the existing payment journey?
- How will the bank connect to the relevant national or European infrastructure?
- What happens when a name match is uncertain?
- How will the system behave under high transaction volumes?
- Which APIs need to be upgraded for future third-party access?
- How will customers manage consent and permissions?
- Where does fraud detection happen today, and can it operate in real time?
- Which parts of the existing architecture will become bottlenecks?
- Which work should be handled internally, and where would additional delivery capacity reduce risk?
These are engineering questions.
And they need to be answered before they become deadline questions.
Building for compliance without building a dead end
It’s understandable that the instinct with new regulations is to build the minimum required solution, pass the deadline and move on.
But for payment infrastructure within a bank, that can be a costly approach.
The capabilities being introduced now (real-time payments, better identity and account verification, modern APIs and real-time fraud controls) go beyond regulatory requirements and are the building blocks for the next generation of banking products.
A well-designed Verification of Payee implementation can become part of a broader payment verification architecture.
Better APIs can support future partnerships and financial products.
Real-time fraud capabilities can improve protection beyond the specific regulatory requirement that triggered the investment.
The goal, therefore, shouldn’t be to build a compliance layer that the bank has to replace in two years.
It should be to use regulatory change as an opportunity to modernise the underlying technology.
Where a delivery partner can help
This is where Vacuumlabs works with financial institutions.
As a financial product development company, Vacuumlabs partners with banks and fintechs to design, build and launch production-ready financial products and technology.
For banks facing regulatory-driven transformation, that means going beyond advisory work.
We help turn requirements into working systems: from architecture and product design through engineering, integration and delivery.
The objective isn’t to replace a bank’s engineering organisation. It’s to give that organisation additional specialist capacity when the roadmap becomes too large, the deadline too fixed or the implementation too complex to handle alone.
Because the real challenge of Europe’s payment regulation isn’t understanding what the rules say.
It’s getting the technology ready in time.
