On the bank’s side, there are two important things to consider.

First of all, the API that allows for Account Name Verification has to be integrated into your online banking environment.

Secondly, data provisioning has to be taken care of. This concerns the provisioning of customer data by your bank to SurePay so that SurePay’s algorithm can match the payment data to your bank’s customer data. Further information on required implementation efforts can be found in the sample Implementation Plan

When making a transfer online, Verification of Payee, the IBAN-Name Check and the SurePay Confirmation of Payee verify entered account details of the beneficiary prior to the actual transfer. The verification is based on the unique combination of the account holder’s name information belonging to a specific account number. The payer’s bank sends the entered account name and number to SurePay, which in turn verifies the details against the available data in order to provide a response. Should entered details be incorrect (i.e. the beneficiary name does not match with the names known at the bank for this account number), then the payment initiator will get a notification. The payer might be at risk of payment fraud or possibly has made a mistake.

Verification of Payee is tailored for the EU market and the SurePay Confirmation of Payee adheres to UK market requirements, rules and regulations.

No, you don’t. SurePay’s Verification of Payee service is not a separate app, nor programme. Your own bank can opt to integrate SurePay’s Account Name Verification service in its online environment, and make it available to you. The service generally works for online transfers and is commonly made available through a regular banking application.

Currently, SurePay’s services are available to customers of 100+ EU banks.

At the moment, SurePay’s  service is exclusively available to customers of 100+ Dutch, UK, French and Italian banks:

Businesses and organisations can also implement the Verification of Payee in their own business processes and systems, regardless of what bank they use.

SurePay’s Account Check deploys an intelligent algorithm that compares the user’s entered beneficiary details against the SurePay database, which contains data from several sources such as connected banks and e.g. the Dutch Chambers of Commerce.

The service takes advantage of multiple data fields of the beneficiary’s bank of registry in order to match with users’ input. The outcome can be a match, a near match or a non-match, in which case the user can be prompted with a notification.

For its operations, it is important that SurePay’s service has access to complete and up-to-date client records of connected banks. Ensuring this will help to prevent fraud and payment misdirection.

In order to ensure high quality matching, the SurePay algorithm needs access to the verified customer data of the bank that has issued the account. For business accounts, SurePay retrieves additional trade names as registered at the Chambers of Commerce, for the registry number that the banks hold in their files for their business customers. This is important because payments to trade names should not lead to a warning notification.

SurePay closes agreements with connected banks for the provisioning of customer data, in which purpose limitation is included and clearly described. Meaning that the data you provision as a bank will strictly and solely be used for the agreed purposes.

Currently the EPC is working on a standardised API for VoP request to be used between API’s.

They intend to have it ready by September/October 2024 and are working with us for information on how to define the API. Their intended timelines will leave a year for implementation of the community for these standardised API’s. This follows the timeline of the VoP Rulebook.

• In defining our own API we will have to take into account that it follows the ACMT023 (request) and ACMT024 (response) message standard into account. It needs not to be followed to the letter since these XML messages are not useful in an API context (too heavy). rather we take the approach PAYUK has taken. their API’s are based on the ISO20022 message standard from the both ACMT messages, whilst taking a practical approach towards a clean and clear API.

For our current bank customers, we are investigating the impact and whether our current API is already compliant with the rulebook (it does look like it). We will, however, introduce a new version of the API which offers the possibility to include other IDs like a VAT, LEI, Personal ID, or other unique identifier to be sent in the request and provided with a response (when available from the responding PSP), thereby offering full compliance with the European Rulebook.

We have a range of solutions available, ranging from minimal impact to solutions that are ready for scale and offer additional value and ease of use for customers:

• Using the single check for batches, this solution will be useful for smaller banks.
• Using our Batch Check API, connect to our API and deliver large files with multiple VoP requests in one go.
• Integrate our (white-labelled) portal into your online transaction channel and offer your customers the ability to perform file checks.
• After initial checks done by your customers, we also offer an alerting service in case something has changed (account inactive, name changed, switched), adding additional comfort for your customers. While not a compliant solution on its own, it does offer benefits for your customers to rest assured their administration is up-to-date.

→ For a more detailed explanation, refer to the article via this link: Verification of Payee for Batches

Banks need to sign an adherence agreement with the EPC to become a participant or appoint SurePay to do it on their behalf:

“To apply to become a Participant, an undertaking shall submit to the EPC an executed and original Adherence Agreement and submit Supporting Documentation to the EPC. A Participant may appoint an agent to complete an Adherence Agreement on its behalf.”

The specific moment when PSP’s will be able to become live participants is not known at this time.

The short answer is no. Participation in the EU VoP scheme is only possible for PSPs (or Routing and Verification Mechanism (RVM) providers like SurePay on behalf of PSPs). PSPs can, however, offer additional optional services (AOS) on top of the VoP scheme.

As SurePay, we will continue to develop services for corporates and investigate the best way to do this in the new European context.

Yes, in the case of a Close Match result, the scheme requires a corrected name to be provided. Although not explicitly stated in the Rulebook, it is intended that no data not known to the payer before should be presented.

Quote from the Rulebook:

“The name of the Payment Counterparty as supplied by the Responding PSP back to the Requesting PSP and the Requester in case AT-R001 indicates Close Match. The use of this attribute is limited to Close Match only.”

Note that providing a name suggestion in the case of a close match on a business account is not supported by the Rulebook, contrary to SurePay’s current practice in the case of a no match on a business account.

→ For a more detailed explanation, refer to the article via this link: Solving GDPR Challenges

For PSP’s operating in a euro country, the deadline is October 9, 2025.

For PSP’s operating in a non-euro country, the deadline is July 9, 2027.

The PSP’s are required by the regulator to offer VoP checks free of charge to their customers. This includes batches, single checks, as well as checks on other provided ID’s.

We expect a fair amount of standardisation in the inter-PSP exchange of requests and responses as defined in the Rulebook. The EPC will provide a directory service that allows fetching the reachability details of each participant. SurePay will ensure actual reachability by connecting to all available participants. These participants may operate within the same country with different vendors, similar to the situation in the UK, or between countries.

Choosing a provider with a proven solution offers several benefits over building a solution yourself or choosing a vendor with no experience in the field:

• Optimised Customer Experience: Perfecting match rates takes time and multiple iterations. This is crucial for a positive user experience. False positives or negatives, or a high No-Match rate, might lead to friction in the customer journey or cause customers to ignore warning messages, potentially achieving the opposite of the intended effect.

• Quality of Matching: The quality of matching becomes an important factor as a responding PSP. Failing to respond or providing an incorrect response might lead to liability for any resulting damage.

• Shorter Implementation Times: Since SurePay specialises in name matching and connecting PSPs to our service, implementation times are shorter and less expensive compared to doing it on your own.

In the UK, we saw different banks building their own solutions with varying outcomes. Some developed solid solutions, while others experienced difficulties and are now looking to replace their solutions with a vendor. This is not a risk when choosing SurePay; we have standardised our implementation process and removed the hassle of maintaining everything.

→ For a more detailed explanation, refer to the article via this link: Verification of Payee and Liability

The Final Regulatory text can be found here:

Regulation – EU – 2024/886 – EN – EUR-Lex

The Public consultation document set for the VoP Rulebook can be found here:

Public consultation on the Verification Of Payee Scheme Rulebook

New item from the EPC on CoP:

Public consultation on the Verification Of Payee Scheme Rulebook

News item where the RFP is announced for the Directory Service for VoP:

Update on the forthcoming Request for Proposal for the EPC Directory Service