Verification of Payee

Combat fraud

Introduction of VoP

But there is a downside to instant payments. In Nordic countries where they have been using instant payments for a few years now, a marked increase in fraud was observed. The primary reason for this increase is the fact that when people are tricked into making a payment to a fraudster, there is no chance for the bank to flag the transaction as suspicious, and contact the payer to double-check if they are really sure about the money transfer. Traditional, slow credit transfers give banks a few hours to undertake such actions.

The Council is aware of this risk, and added an important measure to combat fraud: the Verification of Payee (VoP). In this blog we’ll discuss how VoP is designed, and how Ximedes can help you comply with this new regulation.

What does the ECP mandate?

In their document “Verification Of Payee Scheme Rulebook” the EPC identifies 3 roles: 

• The Requester - i.e. the person or entity that makes a payment to the Payment Counterparty. A payment is defined as a SEPA Credit Transfer (SCT) or instant SCT in the context of the VoP.
• The Requesting PSP - i.e. the bank of the Requester.
• The Responding PSP - i.e. the bank of the Payment Counterparty  

Now imagine the Requester uses the banking website or App to make an instant credit transfer to the IBAN of the Payment Counterparty. The Requesting PSP (in the Council’s terminology), must ask the Requester to provide the name of the Counterparty, as well as the  IBAN. (Alternative identifiers, such as a VAT number, can under conditions also be allowed as an identifier of the counterparty.)

The Requesting PSP then sends an InstantVOP Request to the Responding PSP. The European Payments Council (EPC) does not yet exactly describe how this should work; at Ximedes we prefer a design that uses a directory service that maps the BIC code of the payee’s bank to a URL, e.g.:

BBVAESMM ->“https://api.bbva.com/vop"

INGBNL2A-> "developer.ing.com/verification"

The provided URLs should identify the service that can be called to perform the InstantVOP Request. The InstantVOP Request can then be sent to the indicated URL for verification. The response should ideally be provided in less than one second, but never in more than in three seconds.

The Response

The Responding PSP should reply to this request as follows:

• MATCH | There is an exact match between the name that was sent to be checked and the name and IBAN that are on file at the Responding PSP. Note that in the case of entities both the legal name as well as the trade name may be used.
• CLOSE MATCH |  The name of the payee matches closely but not exactly. In a preliminary document the EPC now suggests that a close match may have:
  • One or two characters that are swapped
  • A first name provided in full instead of an initial or vice versa.
  • A common nickname is used such as Bob for Robert
• NO MATCH | Any name that is not a MATCH or a CLOSE MATCH is a NO MATCH. A NO MATCH is also generated when the IBAN number in the VoP request is malformed or doesn’t exist.
• Identification code not supported/known by the Responding PSP : This response is generated when an alternative code (e.g. the VAT number) is provided, but it is not supported by the Responding PSP.

While the above rules sound reasonable and almost obvious, implementation requires careful attention to the technical details of dealing with text. Especially diacritical characters, punctuation and non-Latin character sets require careful pre-processing to prevent false negatives when matching names.

Other actors in the model

Only licensed PSPs are eligible to take part in the Scheme and must comply with its obligations. However, they may contract some of their work to Routing and Verification Systems (RVMs) or Intermediary PSPs.

RVMs

RVMs are situated between a Requesting PSP and a Responding PSP, and have a contractual relation with both. They essentially forward the VoP from a Requesting PSP to the correct Responding PSP, and may play a role in risk management.

In some cases RVMs also send a VoP response on behalf of the Responding PSP.

Intermediary PSPs

Intermediary PSPs can perform any function in relation to a VoP request/Vop Response, but it  should be transparent to the Scheme, and it does not change the obligations of the licensed PSP. The services should also be part of an agreement between the licensed PSP and the Intermediary PSP.

Lookups by 3rd parties and batches

The Rulebook doesn’t talk about batch processing or lookups by third parties. However, we believe PSPs will provide third parties with web forms and APIs that they can use to make Verification of Payee checks. The market will also demand facilities for batch processing of VoPs, and they offer possibilities for monetization that the base service does not allow. In markets where VoPs are already the norm, such as the Netherlands, services like these have already launched.

OUR MISSION

How Ximedes helps to deliver a VoP solution

While banks have all the data available to create services adhering to the Scheme Rules of the Verification of Payment, implementing these rules correctly is a challenge. On top of that, the demands on performance and uptime are such that implementing these services directly in, or on top of, a core banking platform is not always feasible.

Ximedes has designed a dedicated component that acts as the backbone for VoP Requests that offers for near-instant responses without putting any load on existing (legacy) systems. We gladly help you to integrate this piece of software into your environment. Contact us if you want more information.