Verification of Payee 2.0: What the Next-Generation VoP Scheme Standard Means for EU PSPs

ByOfficer

Last updated: June 2026

If your bank went live with Verification of Payee on 5 October 2025 and then quietly assumed the work was finished, the next eighteen months will surprise you. The scheme that PSPs built against is already moving. A version 1.1 of the rulebook is published, a version 2.0 is out for consultation, and the matching logic, the error handling, and the operational obligations you coded against in the first sprint are all on the table again. Get the change cycle wrong and you face two distinct failure modes: a live VoP service that drifts out of conformance with the scheme rulebook, and a legal obligation under the Instant Payments Regulation that your service no longer cleanly satisfies.

Verification of Payee, usually shortened to VoP, is the European Payments Council scheme that lets a payer’s PSP check, before a credit transfer is authorised, whether the IBAN and the payee name the payer typed actually belong together. It is the operational answer to a legal command. The EU Instant Payments Regulation, Regulation (EU) 2024/886, inserted a payee-verification duty into the SEPA Regulation, and the EPC scheme is how thousands of PSPs discharge that duty in a common, interoperable way. The two are not the same thing, and the gap between them is exactly where reporting and compliance teams get caught.

This is a change note, not a build guide. The point here is what is changing in the VoP scheme standard through 2026, why the version numbering matters more than it looks, and which obligations are legal versus which are scheme-contractual. The distinction governs how you document conformance and what you tell your supervisor.

Related reading: our Verification of Payee guide for Luxembourg PSPs.

The legal floor: what Regulation (EU) 2024/886 actually requires

Start with the law, because the scheme sits on top of it. Regulation (EU) 2024/886 of 13 March 2024 amends Regulation (EU) No 260/2012 (the SEPA Regulation) and was published in the Official Journal on 19 March 2024. It is the instrument everyone calls the Instant Payments Regulation, or IPR.

The payee-verification obligation lives in the new Article 5c of the amended SEPA Regulation, headed “Verification of the payee in the case of credit transfers.” The text is precise about who does what. The payer’s PSP must offer the payer a service ensuring verification of the payee, and it must perform that check immediately after the payer enters the payee’s details and before the payer is offered the chance to authorise the transfer. The obligation applies regardless of the payment initiation channel. That last clause is the one teams underestimate. It is not a feature for the mobile app only.

Article 5c then sets out four matching scenarios. Where the payer supplies an IBAN and a name, the payee’s PSP verifies whether they match, and on a no-match the payer’s PSP must notify the payer that authorising the transfer might send funds to an account not held by the intended payee. Where the name almost matches, the payer’s PSP must show the payer the actual name associated with the account. Where the payee is a legal person identified by a data element such as a fiscal number, a European unique identifier under Directive (EU) 2017/1132, or an LEI, the PSP verifies against that element instead. And where an account is held on behalf of multiple payees, the account-holding PSP confirms whether the named payee is among them. The fourth, catch-all case in Article 5c(1)(d) covers channels that do not require both IBAN and name, and there the PSP must still ensure the payee is correctly identified.

The deadlines are the part to get exactly right, because they differ by entity type and by currency area. Under the amended Article 5c, PSPs in a Member State whose currency is the euro had to comply with the verification obligation by 9 October 2025. PSPs in a Member State whose currency is not the euro must comply by 9 July 2027. Those are the dates that matter for VoP. They are not the same as the instant-receive date of 9 January 2025 or the charges-parity date, and conflating them is a recurring documentation error.

One operational trap here. The IPR does not create a new periodic report you file with a supervisor. There is no VoP return. What the regulation creates is a service obligation plus a liability and refund regime: under Article 5c, a PSP that correctly performs the verification service is not liable for executing a transfer to an unintended payee on the basis of an incorrect unique identifier. Where the payer’s PSP fails to comply with Article 5c(1), or where a payment initiation service provider fails to comply with Article 5c(2), and that failure results in a defectively executed payment transaction, the payer’s PSP must refund the payer without delay and, where applicable, restore the debited payment account. If the failure was caused by the payee’s PSP or the payment initiation service provider, that party must compensate the payer’s PSP for the financial damage caused. So the reporting angle is internal evidence of conformance, not an external filing. If your compliance file treats VoP as a reporting line item rather than as a continuously-evidenced control, you are mapping it to the wrong shelf.

The scheme that delivers it: VoP rulebook v1.0 and the API

Article 5c says the verification service should, as far as possible, be carried out under a Union-wide set of rules and standards, and that such rules could be developed by organisations representing PSPs. The EPC stepped into that gap. The Verification Of Payee scheme rulebook, reference EPC218-23, was published at version 1.0 in October 2024, together with the VoP inter-PSP API specifications. The rulebook entered into force on 5 October 2025, four days before the 9 October 2025 euro-area deadline for sending instant credit transfers under Article 5a and for verification of payee under Article 5c.

The mechanics are worth restating in plain terms because the rulebook language and the legal language describe the same flow from different angles. The payer’s PSP acts as the Requesting PSP. It sends an instant request to the payee’s PSP, the Responding PSP, asking it to verify the IBAN and the payee name as given by the payer, optionally plus an unambiguous identifier such as a VAT number or an LEI. The Responding PSP checks the data against what it holds for that account and returns one of a small set of outcomes: match, no match, close match with the name of the payee, or verification check not possible. The Requesting PSP passes the response back to the payer. The inter-PSP technical layer is API-based and uses ISO 20022 resource elements.

The adoption numbers tell you why this is now critical infrastructure rather than a pilot. By the time the rulebook entered into force, the EPC register of participants listed 2,673 participant PSPs and 55 Routing and/or Verification Mechanisms ready for VoP operations, and the EPC expects participation to exceed 3,000 PSPs by July 2027, when the IPR obligations extend to non-euro-area PSPs. The EPC launched the EPC Directory Service on 2 September 2025 to support reachability and interoperability, and an automated certification process based on the API Reference Toolbox had been available to RVMs and PSPs since May 2025. A PSP rarely connects to VoP directly. It connects through an RVM, and the routing mechanism is what makes a single Responding PSP reachable across the whole scheme. If your reachability through your RVM lapses, your legal service obligation does not lapse with it, which is the kind of dependency that belongs in your operational risk register, not buried in a vendor contract.

Why version 1.1 exists, and why it is not cosmetic

Live schemes generate edge cases. After the 5 October 2025 deployment, the EPC identified a limited number of issues and inconsistencies that required urgent updates to the rulebook and to the related documents: the API specifications, the API Security Framework, and the EPC Directory Service documentation. These were handled outside the normal annual change cycle precisely because they affected smooth functioning and interoperability between scheme participants.

The EPC ran a public consultation on the urgent change requests. The consultation document carried reference EPC310-25, the response template was EPC326-25, and stakeholders were invited to submit feedback by 15 February 2026 at 18:00 CEST according to the EPC consultation page. Version 1.1 of the VoP scheme rulebook, reference EPC218-23 v1.1 2026, was then published on 16 March 2026. Its effective date is 20 September 2026.

The split between publication and effective date is where teams misread the obligation. A rulebook can be published months before it takes contractual effect, and v1.1 is exactly that case: published 16 March 2026, effective 20 September 2026. The publication date tells your build team when the target is frozen. The effective date tells your conformance and adherence team when the older version stops being the standard you are measured against. Treat the effective date as a hard internal deadline for any change v1.1 introduces, and treat the publication date as the start of your implementation window, not its end.

Because v1.1 also touches the API specifications and the API Security Framework, the change is not confined to a policy document, and these documents require parallel conformance work. The EPC published the VoP inter-PSP API specifications as version 1.1.0, reference EPC103-24 v1.1.0, in March 2026, together with the machine-readable VOP API YAML_v1.1 package. Version 1.1.0 becomes effective on 20 September 2026 and covers VOP requests and responses in the inter-PSP space only. The EPC also released an updated API Security Framework with additional clarifications on certificate use for VoP, which becomes mandatory on 20 September 2026 for VOP, SRTP and SPAA scheme participants using APIs. If your integration was certified against the version 1.0 or 1.0.1 API artefacts, these updated API documents are technical change requests for your own backlog, and your RVM will have its own conformance window. This is the part of a “minor” version bump that is anything but minor for a payments operations team.

Verification of Payee 2.0: what the next-generation scheme standard is consulting on

Version 2.0 is the regular change cycle, and it is where the more substantive evolution sits. The EPC ran a regular call for change requests against the version 1.0 rulebook, which closed on 15 February 2026, and then opened a three-month public consultation. The consultation document, reference EPC084-26, was published on 1 April 2026, and the public consultation on change requests for version 2.0 runs from 1 April to 30 June 2026. Stakeholders submit the completed response template, EPC085-26, by email by 30 June 2026 at 18:00 CET at the latest, as stated by the EPC. Change requests that receive broad acceptance will be folded into version 2.0, which the EPC anticipates publishing by the end of November 2026.

The structural fact to understand about v2.0 is what v1.0 deliberately left out. The first version focused on fulfilling the IPR legislative requirements and therefore limited itself to verifications related to a SEPA Credit Transfer (SCT) or a SEPA Instant Credit Transfer (SCT Inst). The EPC was explicit that future versions could cover other payment instruments and use cases, depending on regulatory requirements, market needs and stakeholder interest. So the possible direction of travel for VoP 2.0 is outward from the legal minimum: more instruments, more identifiers, more handling for the cases the first version punted on, if those change requests survive consultation and EPC approval.

One concrete example is in the consultation, but the status is narrower than a normal build candidate. Bulk VoP is not covered by the current inter-PSP scheme or API specification. The consultation records several bulk-related change requests, including customer-to-PSP and inter-PSP bulk proposals, but the VOP Working Group recommends not taking those requests forward into the scheme because a SEPA-level bulk process would be more cumbersome than helpful and would affect the SCT and SCT Inst rulebooks. The VOP Working Group instead proposes optional recommendations or guidelines, including possible codes to indicate whether VoP should be done for a specific bulk file. Corporate-payments owners should track the outcome, but should not assume a mandatory EPC bulk API or standard bulk file process will be added in v2.0.

Do not over-read the consultation, though. A change request is a proposal, not a rule. Until the EPC publishes version 2.0 and assigns it an effective date, the binding scheme standard remains v1.0, moving to v1.1 on 20 September 2026. Writing build tickets against unconfirmed v2.0 change requests is how teams burn a sprint on functionality that the consultation later drops. The discipline is to track the consultation, comment where it affects you, and freeze your build only when the version is published.

The RVM dimension: why the multi-stakeholder governance matters to you

The reason this whole cycle moves so fast is the governance layer the EPC built around routing and verification. The EPC convened a Routing and/or Verification Mechanisms Multi-Stakeholder Group, the RVM MSG, to review VoP progress and to steer the VoP 2.0 discussions. That group is where the practical interoperability problems between RVMs surface and where the change requests that feed the rulebook are shaped before they reach formal consultation.

For a PSP, the operational meaning is that your RVM is not a passive pipe, but it is not a VOP scheme participant in its own right. The EPC treats RVMs as scheme-compliant technical providers that act on behalf of VOP scheme participants and must complete the RVM qualification process and EDS registration steps. The PSP remains the scheme participant and the owner of legal and scheme conformance. The EPC Register includes PSPs adhering to the VOP scheme and their EDS registration status, and the VOP Register of Participants is published daily. RVM qualification status is shown separately on the EPC RVM list. A daily-published VOP register is a strong signal: VoP reachability is treated as live operational data, not a quarterly snapshot.

This is also where a common misconception bites. Adhering to the VoP scheme is not the same as being operationally reachable for verification. Adherence is the contractual step. Reachability through a certified RVM and a correct EPC Directory Service entry is the operational step. A PSP can be a registered scheme participant and still fail to answer a VoP request because its directory entry or its RVM routing is wrong. The scheme treats those as distinct states, and so should your readiness checklist.

What VoP does not mean, and the limits worth stating plainly

VoP is a name-and-account match check. It is not fraud prevention in the round, and it is not sanctions screening. The IPR recitals are careful about this. The verification service exists so the payer can validate the payee before authorising, which reduces misdirected payments and certain authorised-push-payment fraud patterns. It does nothing about whether the payee is a legitimate counterparty. A “match” response confirms the name and IBAN go together. It does not confirm the payee is honest.

Sanctions screening sits in an entirely separate part of the same regulation, and it is easy to bolt the two together incorrectly. Regulation (EU) 2024/886 changed how PSPs screen for targeted financial restrictive measures on instant credit transfers: rather than screening every transaction, PSPs must verify at least once every calendar day whether their own PSUs are persons or entities subject to targeted financial restrictive measures, and immediately after any new or amended measure enters into force. During the execution of an instant credit transfer, the payer’s PSP and payee’s PSP must not run additional transaction-based screening of payer and payee for those targeted measures. That daily customer-screening obligation applied from 9 January 2025 to Article 5d in-scope PSPs and is a different control with a different timetable from VoP. Writing the two up as one workflow misstates both.

A second limit. The verification responses are advisory to the payer, not a hard block. Article 5c is explicit that PSPs must ensure the verification service does not prevent payers from authorising the transfer. A payer who sees a no-match can still choose to proceed. What the regulation requires is that the PSP, at the moment of a no-match, close-match or identifier-mismatch notification, also informs the payer that authorising might send funds to an account not held by the intended payee, and that the PSP has told the PSU about the liability and refund consequences of ignoring that notification. So VoP shifts where the warning sits in the journey. It does not remove the payer’s freedom to override it.

Third, the opt-out. PSUs that are not consumers and that submit multiple payment orders as a package may opt out of receiving the verification service, and must be able to opt back in at any time. The verification service is mandatory for the PSP to offer, but for non-consumer batch submitters it is not mandatory for them to receive. A compliance file that records VoP as universally applied to every transaction for every customer overstates the obligation and will not survive a careful read of Article 5c(6).

Frequently Asked Questions

Is Verification of Payee a legal requirement or a voluntary scheme?

Both, in layers. The verification-of-payee service obligation is law, set out in Article 5c of the SEPA Regulation as amended by Regulation (EU) 2024/886. The EPC VoP scheme rulebook is the voluntary, contractual standard that most PSPs use to deliver that legal obligation in an interoperable way. A PSP must provide a verification service. It does not have to adhere to the EPC scheme to do so, but adhering is how it achieves pan-European reachability with other PSPs.

When did euro-area PSPs have to comply, and what about non-euro PSPs?

Under Article 5c, PSPs in a Member State whose currency is the euro had to comply with the verification obligation by 9 October 2025. PSPs in a Member State whose currency is not the euro must comply by 9 July 2027. These VoP dates differ from the instant-receive date of 9 January 2025 and should not be merged with the other IPR milestones.

What is the difference between VoP rulebook v1.1 and v2.0?

Version 1.1 is an urgent maintenance release fixing issues and inconsistencies found after the 5 October 2025 go-live. It was published on 16 March 2026 and becomes effective on 20 September 2026. Version 2.0 is the regular change cycle, currently in public consultation from 1 April to 30 June 2026 and anticipated for publication by the end of November 2026. It may extend the scheme beyond the SCT and SCT Inst minimum that version 1.0 covered, but only if the relevant change requests survive consultation and EPC approval.

Does VoP replace our sanctions screening?

No. VoP is a name-and-IBAN match check. Sanctions screening for targeted financial restrictive measures is a separate IPR control: PSPs must screen their own customers at least daily and after any new measure, rather than screening each instant transaction. The two have different obligations, different compliance dates, and should be documented separately.

Do we have to block a payment when VoP returns “no match”?

No. The verification result is a notification to the payer, not a hard stop. Article 5c requires that the service must not prevent the payer from authorising the transfer. On a no-match the payer’s PSP must warn the payer that proceeding might send funds to an account not held by the intended payee, and must explain the liability and refund implications of ignoring that warning. The payer can still choose to proceed.

Can a corporate customer opt out of VoP?

A PSU that is not a consumer and that submits multiple payment orders as a package may opt out of receiving the verification service and may opt back in at any time. Consumers cannot opt out, and the PSP must always offer the service. The opt-out applies to receiving the service for packaged orders, not to the PSP’s duty to provide it.

Does VoP cover bulk or batch payment files today?

Not in the inter-PSP space. A VoP request currently concerns a single verification of one IBAN, and processing VoP for bulk files is out of scope of the scheme and the inter-PSP API specification as it stands. The version 2.0 consultation records bulk-related change requests, but the VOP Working Group recommends not taking them forward into the scheme, proposing optional recommendations or guidelines instead. Treat a mandatory EPC bulk standard as not expected in v2.0 rather than assumed.

Is there a VoP report we have to file with our supervisor?

The IPR does not create a standalone VoP return. The obligation is to provide the verification service and to meet the associated liability and refund rules. The practical compliance task is maintaining internal evidence that the service is offered, performed correctly across all initiation channels, and kept conformant with the current scheme version, rather than submitting a periodic filing.

Related Articles

Key Takeaways

  • The payee-verification duty is law under Article 5c of the SEPA Regulation as amended by Regulation (EU) 2024/886, published in the Official Journal on 19 March 2024. The EPC VoP scheme rulebook is the voluntary standard most PSPs use to deliver it.
  • Euro-area PSPs had to comply by 9 October 2025; non-euro-area PSPs must comply by 9 July 2027. These VoP dates are distinct from the other IPR milestones.
  • The VoP scheme rulebook entered into force on 5 October 2025 at version 1.0, reference EPC218-23, with an API-based inter-PSP layer using ISO 20022 elements.
  • Version 1.1, reference EPC218-23 v1.1 2026, was published on 16 March 2026 and is effective on 20 September 2026. Publication date and effective date are different deadlines and govern different teams.
  • Version 2.0 is in public consultation from 1 April to 30 June 2026, document reference EPC084-26, with publication anticipated by the end of November 2026. Possible scope expansion beyond the SCT and SCT Inst minimum remains subject to consultation outcome and EPC approval.
  • VoP is a name-and-IBAN match check, not fraud prevention in the round and not sanctions screening. The daily customer-screening obligation for targeted financial restrictive measures is a separate IPR control.
  • A no-match is a notification, not a block; non-consumer packaged-order submitters may opt out and opt back in.
  • There is no standalone VoP report. The compliance task is continuous evidence of a conformant, correctly-performed service across all initiation channels.

Sources and References

Treating VoP as a moving standard, not a finished project

The single most useful reframing for a PSP is this. VoP is not a regulatory deliverable you shipped in October 2025. It is a live scheme on a published change calendar, sitting on a legal obligation that has its own separate deadlines, with version 1.1 effective on 20 September 2026 and version 2.0 due by the end of November 2026. The institutions that handle this well are the ones that put the EPC change cycle on the same governance footing as a supervisory deadline: someone owns the consultation responses, someone owns the API conformance refresh, and someone keeps the legal obligation and the scheme standard in two clearly separated columns. The ones that struggle are the ones who let the project close after go-live and rediscover the change cycle through a broken VoP response in production.

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.

Similar Posts