VOP: Key Lessons Learned According to the CTO

QWAC certificates

The security framework mandates the usage of QWAC certificates. A QWAC certificate is a specific TLS client certificate issued under the EU’s eIDAS regulation and used in the context of PSD2. It can only be issued by specific qualified trust service providers (QTSP). Some challenges are:

• The QWAC certificate can only be issued to the PSP and not the RVM, but yet the RVM does the API call on behalf of the PSP. This means the RVM needs to have an agreement with the PSP and store – for each client PSP – the certificate and key securely.
• In the context of PSD2 a QWAC certificate is linked to a role, e.g. AIS or PIS. For VOP the role is irrelevant, but it is not really possible to create a certificate without a role. You can have a certificate issued with the role ‘Unspecified’ but the validity is not clearly defined in the specifications. What we have seen in practice is that a QTSP issuing a certificate with role ‘Unspecified’ will not consider this a true PSD2 certificate and the organizationIdentifier will not start with “PSD…” but instead with “NTR…” which is not accepted by the VOP Scheme.
  Confusing?  Yes, it is all pretty confusing and you can imagine quite some discussions in the industry and with the EPC about these types of things.
• Finally, there are a number of QTSP’s in Europe that are able to issue valid QWAC certificates. All of these QTSP’s should be added to the trust store for responding to VOP requests from different banks across Europe. There is no standard for this, so you have to create and maintain your own trust store.

BIC, BIC8, BIC11, and BIC translation

Another interesting topic is the usage of BICs. The BIC is the Bank Identifier Code which uniquely identifies the bank. Each PSP in EDS is identified by its BIC and it can have one or more accountholding BICs for responding to VOP requests. The EDS is operated by Swift and BICs are issued by Swift so you might think it is a logical choice to use BICs for routing purposes. However, the confusing part here is that it is non-trivial to derive the BIC from an IBAN because the IBAN structure is determined differently per country. And besides that, even within one country:

• A single bank can have multiple BICs (for different branches, currencies, or payment systems).
• Several smaller institutions may share the same bank code but have different BICs.

Each country’s banking authority defines its own IBAN structure, and there’s no global registry linking those national codes to BICs. And while there are commercial solutions available it is not always the case that the requester and responder derive the same BIC for VOP routing purposes. The national registries are not always publicly available either. For example, the registries of the Netherlands or Germany are public while the French or Spanish are not.

To add to the complexity, the VOP Scheme mandates the use of BIC11 in the EDS, but does not enforce this use in the API specifications, which allows for BIC8. To make a BIC11 from a BIC8 you can simply append “XXX” but it is still an issue, specifically for certain French IBANs in which the branch code may or may not be part of the BIC11.

Our customers cover a wide range of banks across multiple countries. Some banks felt comfortable sharing the BIC of the beneficiary bank while others had difficulties and preferred the RVM to take care of this. To this end we developed our own BIC enrichment service, a powerful tool to fill in the BIC in case the VOP request lacks it.

Diacritics

Another issue is one that always pops up when talking about interoperability in Europe. The EPC states in the VOP Scheme API specifications that only a minimum set of Latin characters should be used for inter-PSP API messages although bi-lateral agreements can be made to support more characters. In the Netherlands and Belgium we went live with account verification before the VOP Scheme became in effect and we support the full set of diacritics and special characters. However, it also depends on the banks and their channels. It widely varies per country and per bank how this is dealt with.

After being live with the VOP Scheme for more than a month, there are still two specific issues: 1. some participants give a close-match with a suggested name that contains diacritics. E.g. you match on Rene Muller and you get back a close-match with the suggested name René Müller. If the requester’s bank channel does not allow him to input diacritics it means he will never be able to get a full match. 2. Another problem arises for some participants that simply return an error in the API call if the name contains a diacritic. This is also problematic because there is no separate reason code in the Scheme which means that the end user gets a generic error message that a match could not be done. There are discussions in the VOP working group about these types of things, and this could be subject to change in a future version of the Scheme.

UUID

Another relatively small issue appeared in the usage of a UUID (Universally Unique Identifier) for the Request-Id header field. I have seen this in other situations causing issues as well, a.o. in the UK CoP Scheme.  The problem is that there are various UUID versions available and unless the specifications are crystal clear about this, it undoubtedly results in some parties doing strict validation where others do less strict validation. The ART test tool box did not cover this in depth, and in production we have seen VOP requests being rejected because of this. I suspect that this subtle issue arises because different coding utilities generate and validate UUID in different ways out-of-the-box.

Timestamp

The VOP API specifications also define a Request-Timestamp header. Personally, I have never really understood the need for this header, but the underlying reasoning is that you would somehow want to measure the complete end to end chain of a request-response.  In practice, it was never really clear what validation rules should be implemented. The format of the Timestamp is one thing, with trailing zeros or without (fascinating low level of details I never imagined having to spend time on), but the validation caused for quite some confusion in the early days, with time drifts and often receiving timestamps that were further in the past than expected, or even in the future.  The best thing to do is to skip the entire validation, or in case you want to validate on the timestamp, take a very long margin, for example everything within 1 minute before or after the current timestamp is still valid.

Bulk

One particular challenge is the so-called bulk checks for corporates. A corporate often does not perform a single credit transfer but does this in bulk, e.g. via a PAIN.001 file. As part of the regulation, a bank is obliged to offer each customer the possibility to do VOP checks, including for bulk payments. While a corporate may opt out, the bank still needs to have developed a solution to be able to offer it. However, the VOP Scheme does not provide any standard or guideline for VOP bulk checks. EBICS, which is a specific communication protocol for payment files, has added some specific features for VOP processing, but this is outside of the VOP Scheme.

The basic idea is that for interoperability the PSP or the RVM would be doing de-bulking and sending the records as individual VOP checks. The biggest challenge here is on the customer journey as I have seen many banks struggling with this part, especially it concerns very big files. This is probably one of the reasons why so far many corporates are simply opting out for their bulk payments. The other challenge is on the technical side, because you do not want to overload any backend system. This means you will need to throttle, but at the same time a file must be processed as fast as possible. Imagine if you have multiple customers all submitting big files at the same time. This can become quite complex, and one of the challenges we therefore faced was to even come up with a reasonable SLA at all.

SLA

Talking about SLAs, the VOP Scheme allows for a timeout of 5 seconds on the PSP side. And even though it is mentioned that the response time is preferably below 1 second, it is still allowed to reply after 3 or 4 seconds, up till 5 seconds. This potentially puts a heavy load on the computing resources. In general, one of the challenges we faced was the variation of estimations on the expected amount of traffic after going live. This wildly varied, and especially for the big players in the market it was difficult to predict, which meant we had to do many performance tests, even end to end with our clients, and we had to make sure the system was highly scalable to be able to cope with any unexpected peak loads. Doing performance tests and tuning the system with heavy load going beyond a few thousand TPS is challenging enough by itself, but it was all the more challenging doing this with strict and tight deadlines while simultaneously developing software to comply with the EPC standard, and onboarding many demanding customers and keeping them happy, and without disrupting any of our existing customer base, and doing peer to peer testing with other RVMs.

Requester-only participants

A completely different type of validation occurred when we received unexpected errors for some of our clients. It turned out that some participants in the industry were validating whether the requester had endpoints configured in EDS. But for these particular requester PSPs, the agreement with EPC only covered the requester role and not responder. For whatever reason some participants were therefore doing the wrong validation and rejecting VOP checks from requester-only participants. Admittedly, this has been largely solved or will be solved soon.

EU vs EEA, UK, Switzerland

Also confusing are the rules for adherence of non-EU SEPA countries, like the EEA countries and the UK or Switzerland. Whether or not any PSP in such countries can join depends on the legal framework and the interpretation of different parties to the adherence rules. But still, a bank could have branches in EU countries for which the regulation does apply and for those branches adherence might be mandatory. Independent from the exact regulatory rules, from a technical perspective, any account holding BIC could be added to the EDS for responding to VOP requests. There are a number of FAQ items dedicated to this topic, but be warned, it is somewhat complicated. See https://www.europeanpaymentscouncil.eu/faq/verification-payee-scheme/vop-scheme-adherence

Matching rates

Finally, some words about the matching rates. The VOP Scheme only gives some very high level guidelines about name matching. This means that there is a large variation within the industry and naturally the overall matching rates we see are quite low. With the matching rate I mean the number VOP checks in a period of time that resulted in a MATCH compared to NO-MATCH or CLOSE-MATCH.

In a mature market as the Netherlands the number of matches are as high as 80% whereas the results across Europe are way lower. One of the reasons is the customer behaviour; customers are getting used to VOP and the way they enter names will change and the match rate is expected to go up over time.

However, proper name matching is difficult in itself. It requires the banks to have the account data stored in a structured and clean way. Many banks have multiple systems, e.g. for different type of accounts or as a result of a merger, and often there are silly restrictions from legacy systems involved or there could be country specific customs. Here are a couple of observations and challenges we’ve met:

• there could be restrictions on the length to 70 or even 40 characters, even though the VOP Scheme allows for 140 characters.
• in many countries it is normal to type in the full name, but in some countries using initials is common practice; sometime a first name is not even available
• dealing with nicknames or name variations
• dealing with double barreled names, or composed names
• dealing with diacritics, or even complete different character sets (Greek, Cyrillic)
• dealing with joint accounts; we want to be able to match on one or on both accounts
• dealing with business accounts, and specifically with multiple company trading names
• we should be able to match on other fields, like tax number, instead of a name

All of this will improve across the industry over time, no doubt. But it is important that the matching rate increases, because if you get a warning every time you make a payment, you will at one point always ignore the warning and the purpose would be defeated.