Verification of Payee (VoP) – What Luxembourg PSPs Need to Know About the EPC Scheme

Last updated: April 2026

A payer enters an IBAN and a name. The payment goes through. The IBAN was correct but belonged to someone else entirely. The payer only finds out days later, after the funds have moved on. That scenario is exactly what the Verification of Payee (VoP) obligation was designed to stop. Since 5 October 2025, the EPC’s VoP scheme rulebook has been in force and euro area credit institutions have been required to operate a live VoP service. Luxembourg PIs and EMIs have until 9 April 2027. That date sounds comfortable. The implementation work required to get there is not.

This article covers how VoP works, who is in scope, the compliance timeline, what the EPC scheme rulebook actually requires, and where the operational complexity sits for Luxembourg institutions specifically.

Related reading: SEPA Instant Payments Regulation – A Practical Guide for Luxembourg PSPs

What VoP Is and What It Is Not

Verification of Payee is an IBAN-name check. Before executing a credit transfer, the payer’s PSP must verify whether the payee’s name matches the IBAN provided by the payer, and inform the payer of any discrepancy. The payer then decides whether to proceed or cancel.

The legal basis is Article 5c of the amended SEPA Regulation (Regulation (EU) No 260/2012, as amended by the Instant Payments Regulation, Regulation (EU) 2024/886). The IPR was published on 19 March 2024 and entered into force on 8 April 2024.

VoP is not limited to instant payments. This catches people. The obligation applies to both SEPA Credit Transfers (SCT) and SEPA Instant Credit Transfers (SCT Inst). If you offer any form of euro credit transfer within SEPA, VoP applies. The common assumption that VoP only matters for instant payments has led some institutions to underscope their projects.

VoP is also not a fraud detection system in itself. It checks one thing: does the name match the IBAN. It does not assess transaction risk, it does not screen for sanctions (that is a separate obligation under Article 5d), and it does not replace your existing fraud monitoring. Where teams go wrong is treating VoP as their APP fraud solution. It is one control within a broader fraud prevention framework.

The EPC VoP Scheme Rulebook

To make VoP work across SEPA, you need interoperability between PSPs. The payer’s PSP needs to query the payee’s PSP for name verification, regardless of where either PSP sits within the EEA. The EPC developed the SEPA Verification of Payee scheme to provide that interoperability layer.

Version 1.0 of the VoP scheme rulebook was published on 10 October 2024 and entered into force on 5 October 2025. The EPC defines it as a set of rules, practices, and standards for verifying payment account numbers and names of payment counterparties between scheme participants prior to initiating a SEPA credit transfer.

The rulebook is the minimum. It covers the core regulatory requirement from the IPR and nothing more, at least for now. Version 2.0, expected by end of November 2026, will expand the scope.

Scope of the Rulebook

The scheme is open to PSPs based in the EEA. It is not limited to the 27 EU member states. PSPs in Iceland, Liechtenstein, and Norway can adhere, as can PSPs in other SEPA countries (Switzerland, UK, Monaco, San Marino, Andorra, Vatican City) through the wider SEPA framework. For Luxembourg, this matters because some groups operate across SEPA but outside the EU, and the scheme gives them a single interoperability standard.

One limitation to note: version 1.0 covers only verifications related to SEPA Credit Transfers (SCT) and SEPA Instant Credit Transfers (SCT Inst). SEPA Direct Debits are not in scope. This is a deliberate initial boundary. Expect the scope to expand in subsequent versions.

How VoP Works Between PSPs

The inter-PSP flow has four steps:

1. The payer’s PSP (Requesting PSP) submits the payee’s IBAN and name.
2. The request is routed to the payee’s PSP (Responding PSP) via the EPC Directory Service or a Routing and Verification Mechanism (RVM).
3. The Responding PSP checks its customer records and returns a result: Match, Close Match, No Match, or Not Applicable.
4. The Requesting PSP relays the result to the payer, who decides whether to proceed.

The EPC originally proposed a three-second maximum execution time. The final rulebook allows five seconds. The EPC still targets one second as the preferred response time. Five seconds is the outer boundary. If your systems cannot respond within five seconds consistently, you have a problem. In my experience with payment infrastructure, the real constraint is not network latency but the time it takes to run the matching logic against your customer database while handling edge cases.

The Four Response Types

The API specification defines four possible outcomes:

• Match (MTCH): the name matches the account holder.
• Close Match (CMTC): the name does not match exactly, but a similar name is found. The Responding PSP returns a name indication.
• No Match (NMTC): the name does not match any account holder linked to that IBAN.
• Not Applicable (NOAP): the Responding PSP cannot perform the verification (for example, the account is closed or the IBAN is not recognized).

The Close Match response is where decisions get interesting. The scheme returns a name indication to the Requesting PSP so the payer can see the actual account holder’s name (or a close variant of it). How you display that to the payer, what you say about the discrepancy, and whether you allow the payer to proceed anyway are implementation decisions within the scheme framework. The regulation requires you to inform the payer of the discrepancy. It does not require you to block the payment.

Who Is in Scope

All PSPs offering SEPA Credit Transfer or SEPA Instant Credit Transfer services in euro within the EEA. That means credit institutions, payment institutions, and electronic money institutions. The obligation has two sides: the Requesting PSP (payer’s side) must perform the check, and the Responding PSP (payee’s side) must answer it.

Teams sometimes focus only on the Requesting side (checking outgoing payments) and forget they also need to respond to incoming VoP queries from other PSPs. If you hold customer accounts, you are a Responding PSP. You need the infrastructure to receive VoP requests, match them against your customer records, and return a response within five seconds. This is not optional.

Compliance Deadlines by Entity Type

Entity type	VoP obligation deadline
Euro area credit institutions	9 October 2025 (past)
Euro area PIs and EMIs	9 April 2027
Non-euro area credit institutions	9 July 2027
Non-euro area PIs and EMIs	9 July 2027

Luxembourg is a euro area country. Luxembourg credit institutions should already be operating VoP. Luxembourg PIs and EMIs have until 9 April 2027.

The EPC Directory Service and Scheme Adherence

You cannot operate VoP in isolation. The scheme relies on the EPC Directory Service (EDS), a centralized lookup that tells Requesting PSPs how to route VoP queries to the correct Responding PSP. Every scheme participant must register in the EDS.

The EDS contains three things for each participant: the fact that they adhere to the VoP scheme, their technical routing data (so other PSPs know where to send VoP requests), and which corporate identifiers they support.

The VoP Register of Participants is published daily. This is different from the standard SEPA scheme registers, which are updated on a fixed cycle (roughly monthly). The daily publication reflects the fact that PSPs continue to adhere to VoP on a rolling basis.

Adherence to the VoP scheme is mandatory for all current and future SCT and SCT Inst scheme participants who are subject to the VoP obligation under the IPR. The scheme adherence carries a three-year commitment period starting from October 2025, during which participants must remain registered in and fund the EDS. The billing model for the EDS was a point of contention during consultation, particularly for smaller PSPs. The EPC has published opt-out principles for participants who do not use the EDS for routing (for example, because they route through an RVM). But they must still register.

Routing and Verification Mechanisms (RVMs)

Not every PSP will send VoP requests directly to the Responding PSP. Routing and Verification Mechanisms are intermediaries that handle query routing, particularly for smaller banks and fintechs without bilateral connections to every PSP in SEPA. RVMs aggregate VoP requests and route them to the correct Responding PSP based on the EDS data.

In Luxembourg, LUXHUB has positioned itself as an RVM provider for the local market. Whether you build your own VoP connectivity or use an RVM is a build-versus-buy decision. The key constraint: regardless of the route, the five-second execution time applies end-to-end.

Name-Matching: Where the Hard Decisions Sit

The IBAN lookup is straightforward. The name-matching logic is where implementation effort concentrates. The EPC published recommendations for the matching process alongside the rulebook, but these are guidelines, not rigid rules. Each Responding PSP makes its own matching decisions within the framework.

Common scenarios that cause problems:

• The payer enters “Jean-Pierre Dupont” but the payee’s PSP has “J.P. Dupont” on file.
• The payer enters “ABC Trading SARL” but the payee’s account is registered as “ABC Trading S.a r.l.” Luxembourg legal entity suffixes (SA, SARL, S.a r.l., SCA, SCS, SCSp) produce mismatches constantly.
• The account belongs to a company but the payer enters the director’s personal name.
• Diacritics are stripped by the payer’s interface but preserved by the payee’s PSP. “Müller” becomes “Muller.”
• The payer uses a commercial or trading name that does not match the legal name on the account.

Each of these produces something other than an exact match. The question is whether your system returns Close Match or No Match, and what name indication it provides. Luxembourg adds a specific wrinkle: the country’s multilingual environment (Luxembourgish, French, German, Portuguese) means name variations across character sets are more common than in single-language jurisdictions. A Responding PSP in Luxembourg needs matching logic that handles accented characters, multiple transliterations, and common abbreviation patterns across at least three languages.

The EPC’s recommendations explicitly state that the matching scenarios provided are not exhaustive rules. They are guidelines. You need to define your own matching threshold and document why you chose it. Too loose, and you return Match when you should not, reducing the fraud prevention value. Too strict, and you generate a flood of Close Match or No Match responses that frustrate payers and create noise.

Bulk Payments Add Complexity

The rulebook requires each payment within a bulk file to be individually verified. Salary payments, supplier payments, dividend payments: every line item gets its own VoP check. Between a PSU and their PSP, batch requests are permitted. Between PSPs, only single requests are allowed.

Picture a payroll file with 2,000 entries returning a mix of Match, Close Match, and No Match. How do you present that to the corporate client within the five-second window per check? Do you present results in a file? Through a dashboard? What happens when 15 out of 2,000 come back No Match? The regulation requires informing the payer. It does not prescribe the channel or format. These are UX decisions with operational implications, and most institutions have not fully worked through them yet.

The Luxembourg Angle

Luxembourg credit institutions supervised by the CSSF (or the ECB for significant institutions under the SSM) passed their VoP deadline on 9 October 2025. For institutions that were already live on SCT Inst, VoP was an addition to existing infrastructure. For those that were not, VoP came bundled with the broader instant payments obligation.

PIs and EMIs: The 9 April 2027 Deadline

Luxembourg PIs and EMIs authorized under the Law of 10 November 2009 on payment services or the Law of 20 May 2011 on electronic money have until 9 April 2027 for VoP (along with the send and receive instant payment obligations). As of April 2026, that is twelve months away.

Twelve months is not comfortable for VoP. The implementation is not just connecting to a directory. You need to build or buy the Requesting PSP capability (outbound checks), build or buy the Responding PSP capability (inbound query handling), connect to the EDS, implement name-matching logic, integrate VoP into every payment initiation channel (online, mobile, API, potentially paper-based), handle the UX for match/no match/close match across those channels, build the bulk processing flow, and test end-to-end with other PSPs.

PIs and EMIs in Luxembourg face an additional constraint: they cannot directly participate in TARGET or TIPS because the Settlement Finality Directive (Directive 98/26/EC) does not cover them. They access instant payment infrastructure through sponsoring credit institutions or RT1 membership where eligible. Your VoP implementation depends on your settlement arrangements. If your sponsor bank provides VoP routing, your architecture looks different than if you need to connect independently. Clarify this with your sponsor before locking your technical design.

CSSF Supervisory Expectations

The CSSF has not published VoP-specific guidance separate from the IPR requirements. Supervisory expectations flow from the regulation itself and from the CSSF’s general stance on payment services compliance. Based on how the CSSF has approached other payments obligations (the PSD2 reporting requirements, for example), institutions should expect questions about their VoP implementation in the next round of supervisory reviews, particularly for PIs and EMIs approaching the 2027 deadline.

One area where the CSSF will likely focus: the VoP obligation interacts with the Article 5d daily sanctions screening requirement, which has applied to all PSPs (including PIs and EMIs) since 9 January 2025. VoP checks and sanctions screening are separate obligations, but operationally they both sit in the payment initiation flow. The CSSF will want to see that they do not conflict or create gaps. A common mistake: assuming that because VoP checks the name, it also covers sanctions screening. It does not. They are different checks against different data sets for different purposes.

Operational and Control Impacts

24/7/365 Availability

If you are a Responding PSP, you must be able to answer VoP queries at any time. This is the same 24/7/365 requirement that applies to instant payment processing. Your VoP infrastructure cannot go down for weekend maintenance if your instant payment service is live. This means redundant systems, automated failover, and monitoring that covers nights, weekends, and public holidays.

Teams that built their instant payment capability on a 24/7 basis already have this. Teams that are building from scratch for the 2027 deadline need to plan for 24/7 VoP response capability from day one. Bolting on a VoP system that only operates during business hours does not meet the scheme requirements.

Data Quality in Customer Records

VoP matching is only as good as your customer master data. If your account records contain outdated names, inconsistent legal entity formats, missing diacritics, or truncated names, your VoP responses will produce false No Match or false Close Match results. Before going live with VoP, clean your customer name data. This is not a small project. In my experience, the data remediation effort is routinely underestimated. Institutions that have operated for decades accumulate name records in multiple formats across multiple systems. A VoP project that does not include a data quality workstream will generate operational noise from day one.

Incident Reporting

VoP failures are reportable. If your VoP service goes down and you cannot answer incoming verification requests, that is an operational incident affecting a regulated payment service. Under DORA ICT incident reporting, significant incidents affecting payment services must be reported to the CSSF. The threshold for significance will depend on the duration of the outage and the number of transactions affected, but VoP outages during peak payment hours will hit those thresholds quickly.

Record-Keeping and Audit Trail

The regulation requires PSPs to retain VoP check results. You need an audit trail showing: what name was submitted, what the VoP response was, whether the payer was informed, and whether the payer chose to proceed despite a mismatch. This audit trail matters for dispute resolution (when a payer claims they were not warned about a name mismatch) and for supervisory review.

What the VoP Scheme Does Not Cover

Three gaps worth noting:

First, VoP version 1.0 does not cover SEPA Direct Debits. If you operate SDD services, there is no inter-PSP verification scheme for those yet. This may change in version 2.0 or later.

Second, VoP does not prescribe what happens after a No Match result. The payer is informed. But the decision to proceed sits with the payer. The regulation does not require PSPs to block payments based on VoP mismatches (though PSPs may choose to as part of their risk framework). This creates a liability question: if a payer is warned about a name mismatch and proceeds anyway, who bears the loss? The answer is not fully settled across all jurisdictions.

Third, customer-to-bank VoP interactions are not standardized. The EPC published inter-PSP API specifications (using ISO 20022 resource elements). It did not publish standards for the customer-facing side. How you present VoP results to retail customers versus corporate clients, how you handle batch results, and what your mobile app says when a Close Match comes back are all your decisions. The scheme gives you the plumbing. The customer experience sits with you.

VoP Preparation Checklist for Luxembourg PIs and EMIs

For institutions approaching the 9 April 2027 deadline, a concrete checklist:

1. Confirm your settlement arrangements. Clarify with your sponsoring credit institution whether they provide VoP routing, or whether you need independent connectivity to the EDS and RVMs.
2. Adhere to the VoP scheme. Submit your adherence pack to the EPC. The VoP Register of Participants is published daily, so there is no quarterly cycle to wait for. But process your adherence early enough to allow for testing.
3. Register in the EPC Directory Service. Registration is mandatory. Budget for the EDS fees over the three-year commitment period.
4. Build or procure the Requesting PSP capability. This is the outbound VoP check for your customers’ credit transfers.
5. Build or procure the Responding PSP capability. This is the inbound query response for other PSPs checking IBANs at your institution. It must run 24/7/365.
6. Define your name-matching logic. Document your matching threshold, how you handle partial matches, Luxembourg legal entity suffixes, multilingual names, and diacritics. The EPC guidelines are a starting point, not the answer.
7. Clean your customer master data. Audit account holder names for consistency, completeness, and character encoding. Fix truncated, outdated, or duplicate records before go-live.
8. Integrate VoP into every payment channel. Online banking, mobile app, API for corporate clients, any paper-based or phone-based initiation. Each channel needs VoP check and result display.
9. Design the bulk payment VoP flow. How do you check 2,000 payees in a salary file, present results to the client, and handle mismatches? Build and test this flow specifically.
10. Obtain the required certificates. Requesting PSPs need an eIDAS QWAC PSD2 certificate (containing your NAN) for mutual authentication. Responding PSPs need a TLS EV certificate.
11. Test end-to-end with counterparties. VoP is an inter-PSP service. You cannot test it in isolation. Schedule testing with your RVM provider and with PSPs you expect high volumes from.
12. Confirm VoP does not interfere with sanctions screening. VoP and Article 5d screening both sit in the payment initiation flow. Ensure they operate independently and do not create gaps or conflicts.
13. Build the audit trail. VoP request, response, payer notification, and payer decision must be recorded and retained for each transaction.
14. Plan for incident management. VoP outages are reportable under DORA. Include VoP in your ICT incident response procedures.

What Comes Next: Version 2.0 and Beyond

The EPC has indicated that version 2.0 of the VoP scheme rulebook will be published by end of November 2026. The details are not yet public, but based on EPC consultation documents and the version 1.0 limitations, expect the scope to expand. Potential additions include support for direct debits, enhanced additional optional services, and possible refinements to the matching recommendations based on the first year of operational experience.

For PSPs that are already live, version 2.0 may require system changes. For PIs and EMIs implementing VoP for the first time ahead of April 2027, building with version 2.0 requirements in mind (once published) avoids a second implementation cycle shortly after go-live.

The broader trajectory is clear. VoP is one component of the EU’s push to make instant payments the default. Combined with the receive and send obligations, charges parity, and Article 5d sanctions screening, the IPR is restructuring how payments work in Europe. VoP will not remain static at version 1.0.

Building VoP Right the First Time

The technical implementation is not trivial, but it is not the hardest part. The hardest part is the decisions that sit around the technology: matching thresholds, UX for ambiguous results, bulk processing workflows, data quality remediation, and the operational model for 24/7 VoP response. Those decisions are yours. The scheme gives you the interoperability framework. It does not tell you how to run your shop.

Luxembourg PIs and EMIs still have twelve months. That window closes faster than expected once you factor in EDS registration, certificate procurement, RVM selection, end-to-end testing, and data cleanup. Start now if you have not already.

Sources and References

• Regulation (EU) 2024/886 (Instant Payments Regulation) amending Regulation (EU) No 260/2012: EUR-Lex – OJ L 2024/886
• EPC Verification of Payee Scheme Rulebook v1.0 (EPC218-23): EPC Document Library
• EPC VoP Inter-PSP API Specifications: EPC VoP Scheme Page
• EPC Register of Participants and EDS information: EPC Register Page
• EPC revised entry-into-force dates for 2025 rulebooks: EPC News
• Regulation (EU) No 260/2012 (SEPA Regulation): EUR-Lex

Disclaimer: The information on RegReportingDesk.com is for educational and informational purposes only. It does not constitute legal, regulatory, tax, or compliance advice. Always consult your compliance officer, legal counsel, or the relevant supervisory authority for guidance specific to your institution.