Here at Devengo, we pride ourselves on staying at the cutting edge of what is possible in the A2A fintech world. Even today, only ~16% of the transfers in the European space are instant, but we have amassed an experience encompassing four years, millions of transfers, and hundreds of millions of euros processed instantly for our customers.

However, Fintech is an ever-changing landscape that always tries to adapt to the market’s demands and the needs of consumers and businesses. The European Union adds another layer of complexity -and value!- to this landscape by assuming the herculean effort of coordinating the banking infrastructure of 36 countries, including some of the largest economies in the world, through typical schemes like SCT-INST or SDD.

Last week, a new scheme was introduced: Verification Of Payee (VOP). Even though it will still take another year for it to enter into effect, we have already analysed the new rulebook and want to share with you all the details.

Why VOP?

The legitimate first question anyone may have about introducing a new scheme is why we need it. In the case of Verification of Payee, the reason is very clear. The European Union, and more specifically, Mairead McGuiness, the Commissioner for Financial Services, has been pushing for increased adoption of instant payments for years. Finally, last week, the new regulation on instant payments in the EU came into force after being approved by the overwhelming majority of the EU Parliament.

You may have heard it in the news, but one of the most notorious things about the new regulation is that PSPs are mandated to support SCT-Inst, a scheme that until now was optional to adopt. That means that in 18 months (~Sept 2025), most European financial institutions will support SCT-Inst (receiving and sending instant transfers).

It’s expected that once the FIs are forced to support it, most transfers will be conducted in this fashion because there will be not many reasons to wait for 24/48hrs to receive the money once all the players involved in the transfer meet the technical requirements to do it in 10 seconds.

In this new scenario where most transfers are instant, the users lose any option to “change” their mind or cancel a transfer because it’s still “in processing”. Once the transfer is mandated, it will be settled in the payee’s account in less than 10 seconds, end of story. There is a procedure in SCT-Inst to try to “undo” an instant transfer, called Recall, but the reasons to initiate it are just these three:

• Duplicate sending
• Technical problems resulting in erroneous SCT Inst Transaction(s)
• Fraudulent originated SCT Inst Instruction

So, in practical terms, the most common reason for cancelling -“Oops, I provided the wrong IBAN/Amount/Name/Description“- will not be enough to initiate a recall. Therefore, once everyone starts making instant transfers, the need to make sure that the money goes where it’s intended becomes crucial. That’s how we get to Verification of Payee.

The Verification of Payee Scheme

The published Verification of Payee rulebook provides a clear purpose for the scheme. The scheme should cover:

The provision and operation of rules and practices for verifying Payment Account Numbers and Names of the Payment Counterparties, between Participants of the Scheme prior to initiating a Payment Account-based Payment within SEPA (Instant or regular)

We need a protocol to determine that the account we are sending the money to belongs to the person/company we think. With this check in place, sending the money to the wrong party will be more difficult. What is then the flow of the verification? How does the check get accomplished?

The Workflow

To better understand the flow, let’s recover the example we used recently, where my Spanish company, Solecito SL, banked with BBVA, wants to send 3.700€ to Béatrice Mesureur, a French freelancer banking with CIC, a French bank.

1. The Payment Service User (PSU), Solecito SL, wants to send money to another PSU, Béatrice.
2. The PSU provides its PSP, the BBVA (officially the “Requesting PSP”), an IBAN and the counterparty’s name (as a minimum)
   • Optionally, it can provide other IDs. The rulebook cites examples such as a fiscal number, a VAT number, a Legal Entity Identifier (LEI), a social security code, an electronic ID, etc.
3. The Requesting PSP, BBVA, sends a Verification Of Payee Request (VOP Request) to CIC, the counterparty’s PSP (officially the “Responding PSP”).
   • The request is delivered via a path/supplier chosen by the Requesting PSP.
   • On a funny note, the rulebook states that if the Requesting PSP manages the counterparty account (that’s if Béatrice was banked with the BBVA), it NEEDS to issue a Verification of Payee Request to itself.
4. CIC receives the request and evaluates the match (see the “Matching names” section below).
5. CIC sends a VOP Response to BBVA via the initially used path.
6. BBVA relays the response to me. If the name I provided doesn’t match the records of CIC for that account, BBVA must also inform me that going ahead with the payment “may lead to transferring Funds to a Payment Account not help by the Payment Counterparty.“
7. Finally, with all the information, I choose whether to proceed with the payment.

Although a non-trivial amount of technology is involved in the process (multiple distributed systems, real-time responses, intermediate proxies), the user-facing implications of this workflow may be as simple as a confirmation dialogue shown asking, “The beneficiary’s name of the IBAN provided doesn’t match exactly your information (BEATRICE R. MESUREUR). Do you want to proceed?” However, this simple check may prevent many information errors (like me sending the money to another freelancer who works with us).

Roles, Scope and Rules

To implement this workflow, the scheme establishes which roles may participate and the constraints to which they are subject.

Roles

The roles involved in the scheme are:

• The ones already mentioned are the Requester, Requesting PSP, and Responding PSP.
• A new role, the Routing and Verification Mechanism (RVM)
• The player who serves this will be in charge of routing the requests and responses to the correct party and exchanging messages between them.
• If you remember how SCT-Inst works, this is the Verification of Payee equivalent to the CSM, the Clearing and Settlement Mechanism.
• The scheme mentions that, at least potentially, the RVM can even answer VOP requests on behalf of a Beneficiary’s PSP.
• Although, in theory, any player could play the RVM role, the scheme mentions ACHs as a clear candidate. This means that the CSM, who will probably deal with the subsequent payment, will also take care of the previous VOP.

Therefore, the model is again a four-corner model—like SCT-Inst—with an RVM in the middle instead of a CSM (although, in practical terms, it’ll probably be the same entity).

Operational rules

Okay, so we know the flow we want to implement and who will be responsible for each step. Now, what are the constraints for each of those participants?

1. Scheme participants who have service accounts must commit to serving both roles in the VOP process: sending requests and responding to requests sent to them by other participants.
2. The service must work 24/7. As every instant transfer requires a VOP Request, the availability requirements are the same as those in SCT-INST.
3. The rulebooks allow this scheme to be operated in batch mode on the PSU side. However, if the requester sends a batch of IBANs to verify, the Requesting PSP must still handle the batch as multiple independent VOP Requests in the inter-PSP space.

The scheme establishes two types of requests:

• The simplest one is where the requester just provides an IBAN and the beneficiary’s name.
• There is an extended optional scenario in which an unambiguous ID (e.g., a fiscal number, a VAT number, a Legal Entity Identifier, or a social security code) is added to the two previous pieces of information.

Depending on how the request is made, the possible responses are:

• Match, No Match or Close Match. (In this last case, the response will include the counterparty name in the Responding PSP’s records).
• If the additional unambiguous ID is included, the responses can be Match, No Match, or ID not supported/known by Responding PSP.

As we have already mentioned, this process is a step before sending an instant transfer, so what are the timing constraints?

• The request is time stamped when the Requesting PSP is ready to send to the RVM.
• The rulebook establishes that most VOP should be solved in under 1 second.
• A hard limit of 3 seconds is defined for any VOP request.

If there is no VOP response after 3 seconds, the Requesting PSP informs the user that the VOP cannot be performed. Likewise, if the VOP response is received after the 3-second limit, it must be discarded as the reply to the user must have already been provided. If the Responding PSP can’t answer (incorrect IBAN, the IBAN belongs to another PSP, etc.), it will provide a reason code with the error.

So, in a sub-second process, we send an identification tuple to another financial institution, and it says if the identification data matches their record. Simple, huh?

Well, as they usually say, the devil is in the details, and in this particular scheme, the Gordian knot we must be able to cut for its success hides in the matching process. The EPC knows that and has provided recommendations to ensure players generate the lowest possible number of false negatives.

Matching names, the EPC recommendations

As Patrick McKenzie said in his now legendary, seminal post “Falsehoods Programmers Believe About Names”, there is probably no computer system in existence that handles all names properly. We, humans, are very inventive when it comes to naming things, especially ourselves.

Still, we are very random, too, when it comes to imposing arbitrary restrictions on them, and some countries and/or states will have legislation forcing specific rules when it comes to spelling, meaning, and character use on names. A very notorious example is California, which in 1986 passed legislation prohibiting the use of diacritics in official documents, affecting a vast amount of Hispanic citizens (a decision that has been put in question again in recent years).

Additionally, we have to bear in mind that the account holder name of most bank accounts is manually introduced by a bank clerk when the account is first opened, with the potential of a human error or any unwritten “policy” (have you ever wondered why some people write everything in ALL CAPS when using an “enterprise” software?) getting applied.

The people behind this new scheme know this very well and have been very careful in clearly stating that this is a complex problem and that the EPC can only provide some recommendations on how to match names:

The Responding PSP bears the full responsibility for the matching outcome and, therefore, remains entirely free to apply different criteria to determine the result of the matching process and whether that constitutes a Match, a Close Match, or results in a No Match.

Okay, so our job is to determine whether two names are the same. We must be flexible enough to deal with naming particularities and variations but not so flexible that anything qualifies as a match. Where do we start?

Data cleanup

We must start by cleaning up the data provided reasonably to compare it with the highest possibility of matching. Some of the recommendations for this preprocessing step are pretty obvious, like removing leading/trailing spaces or non-alphabetic characters (e.g. ~, @, #, $, %, etc.), but the EPC suggest other non-trivial modifications:

Transliterate all the non-ASCII characters

Although ISO-20022, the standard used for the SCT-INST scheme, completely supports UTF-8 as a character set, it is not required or even expected that every adhering bank/PSP supports it (yes, encoding is still a problem in 2024 ¯\_(ツ)_/¯).

As a consequence of this limitation, the implementation guidelines restrict the set of characters to use to ASCII:

Although this troublesome restriction has been discussed multiple times, it is still in force today without any hint that it will change in the near future. Collateral of this restriction is that all the data related to an SCT-INST transaction must undergo a transformation known as transliteration before it’s sent to the CSM, where non-ASCII characters are replaced with an ASCII approximation.

In Rails, the framework provides a feature to help with this transformation: ActiveSupport::Inflector#transliterate. Unfortunately, the default coverage provided by Rails, based on the I18n library, only covers Western/Latin characters:

To make transliterations more robust and universal at Devengo, we have developed our own transliterator based on the fantastic AnyAscii library that provides binding for many languages, including Ruby.

On top of supporting practically all Unicode characters, this implementation gives us support for emoji transliteration (Yes, some people put emojis on bank transfers :) and a more performant replacement:

All name checks will, therefore, use transliterated strings to increase the chance of matching names.

Common titles removal

The EPC recommends removing the titles people sometimes use as the prefixes to their names (Mr., Ms., Dr., etc.). Some titles are prevalent in some countries and circles (Germany and Academia come to my mind, for example).

Unfortunately, although there are some Titles lists, there is no canonical, multi-language reference that we can use as reference, so PSPs will be forced to collect their own “dictionaries” for these processes, and regex’d them for cleanup.

Matching evaluation

Once the provided name has been cleaned up, we come to the moment of truth where we must determine if it matches the account holder’s name we have on record. The scheme establishes only 3 possible outcomes:

• Match: Only when “there is an exact match (i.e. no deviation at all) of the first name and the last name (in the unstructured name string).”
• Close Match: “there is only a small deviation between the name given by the Requester and the name registered by the Responding PSP”
• No match: anything else.

Let’s see each one of them.

Match

This will happen if, after the cleaning up, the provided name and the name in the record match 100%. For example, D. Aitor García Rey will be a perfect match for AITOR GARCIA REY because once the name has been cleaned up, it will be Aitor Garcia Rey, and the comparison must be case-insensitive.

The recommendations state that this should also be a perfect match if the provided counterparty is only one of the account holders and another person is authorised as a holder in the same IBAN (e.g., my spouse).

Close Match

Given that all companies, including the PSPs, deal with imperfect data on their databases (typos, obsolete info, etc.), 100% exact matching will hardly be the most common situation. To provide a scapehatch to prevent a large number of false negatives, a “close match” outcome is introduced.

If a “close match” result happens, the Responding PSP will return the actual name they have on record associated with that IBAN. So I may send a VOP request for Aitor Garcia and get a response that says there is a close match with the provided name: AITOR GARCIA REY. The recommendations are, however, very clear in that the returned information on a close match must be as minimal as possible, in line with data protection laws:

The Responding PSP is strongly recommended to apply data minimisation when submitting a name in the “Close Match” Response

But what could be considered a “small deviation” when matching names? Some of the recommendations mentioned in the scheme:

• A spelling mistake that does not exceed the defined level for string difference set by the Responding PSP. There are many methods to calculate the “difference” between two strings, Levenshtein, Cosine similarity, Hamming Distance, and PSPs are free to pick the one that suits them better and establish the level/threshold they are comfortable with.
  • After testing and fine-tuning it for a few years in Devengo, we use Cosine similarity that, with the correct threshold, provides a good ratio detecting common typos and variations. For example, the cosine similarity between Aitor Garcia Rey and Atior Garcia Rpy will be 0.953, and we will consider that a close match.

• Two switched letters will be considered, e.g., Aitor Garcia Rey and Aitro Garcia Rey.
• The first and last names have been inverted, e.g., Aitor Garcia Rey and García Rey, Aitor.
• First name missing, e.g. Aitor García Rey and García Rey.
• 1-2 letters change with the same phonetics, e.g. Aitor García Rey and Haitor Garcia Rey.
• The first name is presented only as an initial, e.g., Aitor García Rey and A. García Rey.
• Well-known nicknames, e.g. Txema Noriega and Jose María Noriega. This is another point where the lack of a canonical, multi-language reference for nicknames will make it almost impossible to apply this recommendation robustly.

No match

The rest. No surprises here!

To increase the probability of false negatives, the requester PSP can offer the requester the option of providing an extra identifier (alongside the IBAN and the name), such as a VAT number, National ID, etc. In this situation, the same cleanup described before will be applied, but only two possible responses are considered: (exact) match and no match.

In summary, any person who has worked with names knows they are deceptively tricky, and these recommendations will be reviewed every year and outside the scheme change management cycle.

A board, the Payment Scheme Management Board (PSMB), is assigned to this task. Any new or amended recommendations will be applicable as soon as 90 calendar days after the updated version is published to provide fast iteration on best practices observed once the scheme is being used in production.

Verification of Payee, a welcome addition to the EU payments landscape

This new scheme will benefit all parties involved, providing an easy way for customers to detect fraud and prevent unintended transfers. This is especially true once the new instant transfers regulation is in force and its use is expected to explode. It will also provide the rest of the SEPA schemes with a handy tool that has existed in other systems for a few years.

We at Devengo are very excited about its arrival and look forward to being one of the first PSPs in Europe to support it.

Do you have any questions about the Verification of Payee and its implications for your company? Let us know on LinkedIn or Twitter. We would love to hear your comments!