VERIFICATION OF PAYEE

Michael Salmony 0:12

Hello, my name is Michael Salmony and I'd like to welcome you to another episode of the Trilogue where we look at things from the banking side, which Javier represents, and from the fintech side, which Ralf represents, and from the truth, which I represent. And today we have a lovely guest, Frans, ⁓ where we will talk about VOP. But before we get into the topic, maybe Frans, you can tell us a little bit about yourself and your background.

Frans C. Van Beers 0:40

My name is Frans van Beers. I'm employed at the Dutch Payments Association as a senior payments consultant. Before that, I was working with ING and its predecessors. My main experiences for the last years were the introduction of SEPA together with the interbank community in the Netherlands. Following that, shortly after the introduction of instant payments, including the development, which was that

point in time still new. have 35 years experience in payments both on cards, payments and cash, cash least but still it's very important in Netherlands because it diminishes instead of because of that. And I combined my function at the payments association with some activities for the EPC since 2004 for which I have been a member of the rule book.

committees and since 2021 I share the peace and the payment system maintenance and evolutionary working group. At first I found it a challenge to step in but having fun with combining all the different cultures in Europe and especially the payment appetites in that and Javier knows all about that. Both challenging and fun to do.

But as a spin off of that, I was asked to also chair the task force for the VOP, Verification of Payee rule book. And I thought I'd give it a try. And that has been a very nice journey since because we had very short time. We had a very strict regulation, but we delivered the rule book in the 10th of October in 24. as a follow up on that, many activities on the EPC and issues to cover still.

Looking forward to discussing with you and explaining some of the topics.

Michael Salmony 2:33

Thank you, Frans. That's another instance where we have more than 100 years of a payment experience on screen here today. You've clearly got a huge background in this area. So let's get into the topic of VOP. VOP, of course, stands for Verification of Payee, and that gets lots of people excited and not always in a good way. A lot of people think this is actually a huge effort costing the banks enormous... ⁓

Frans C. Van Beers 2:39

Okay.

Ralf Ohlhausen 2:40

you

Frans C. Van Beers 2:46

Okay.

Michael Salmony 2:57

amount of time and investments and is not really solving the problem because the fraudsters have long moved on to other fraud models which VOP doesn't address. So ⁓ with that, maybe you could prove me wrong or agree with me. However, say what you think of VOP and whether you think it's a good idea.

Frans C. Van Beers 3:17

Although VOP is positioned in some talks or perspectives as a fraud prevention measure, I'm from the group that says it's not for fraud prevention as such. It can help a little bit. It can give more confidence that the payment goes to the right beneficiary, but it will never cover all the fraudsters' efforts, especially authorized push payments.

where the fraudsters are very capable in tricking consumers and businesses to make payments to parties they do not want to pay to. So it will be helpful. It will hopefully give more confidence. Our experience in the Netherlands is that it is a sort of addition that everybody becomes accustomed to and takes for granted and very useful. But ⁓ to see it as a full fraud prevention measure, no.

Michael Salmony 4:15

That's very good. You had VOP in the Netherlands for some while, do you? think you just interviewed.

Frans C. Van Beers 4:16

On the other hand.

Ralf Ohlhausen 4:16

Could I just?

Yeah.

Frans C. Van Beers 4:20

Yes, yes.

That resulted from a fintech startup with one of the banks in the Netherlands, Rabobank, who had a room for new developments under her wings. And from that, for those active in the VOP world, the name SurePay is now very well known. But they, in 2017, 2018, had to convince the classic bankers in the Netherlands, including myself, which said,

can never be possible to check online without infringing privacy rules. They proved us wrong because they thought not of sharing the name, but sharing the result of the matching, which is, if you think of it today, a very brilliant idea. At the time, it was very good that they thought of that. if you think of it as from a privacy perspective, it gives you the opportunity to do what we do now with the instant payments regulation.

⁓ obliging all payment service providers to do. But ⁓ one of the predecessors of ING was Postbank, which had non-stacking bank accounts. And they shared full-fledged data to any business who requested that. But that was in the 70s, 80s, 90s of the last century. And privacy moved on naturally. And with that, the possibility to do so.

From that there was reluctance from the banking industry in the Netherlands as well. But the matching idea works very well and was introduced in 2017-18 as I said and almost flawlessly. There is a learning curve of course because the exceptions decide in the end whether it's a perfect product or not. all in all, all...

The introduction was done very smoothly, gradually, for online and mobile payments. And again, as I said, the reaction of the general public, well, that's very logical and very helpful. So.

Ralf Ohlhausen 6:30

Could I

ask you there? Because privacy concern and I'm not sure I guess some people may not know how exactly it works there. So if I'm if the name is matching, then I will I may not even get a message because everything is good and fine. So if the name is not matching, I will be told well, it's not matching. But I will not told will not be told what the

what the real name or what the right name would have been. But I will be told if I have a close match. So if what I put in is close enough to the actual account holder name or the beneficiary name, then I will be told what that beneficiary name is. So can you shed some light on on what that is and how close does the match have to be so that I can find out and that and how we avoid abuse for that? ⁓

Frans C. Van Beers 7:27

Yes, and

if you would like the details of that, you go to the providers in the market because they have all the different algorithms which fine tune that quite technically and both very precise. But in general, ⁓ starting with the match, the regulation also says you must at least confirm it to the payer. So in that case, there's an addition, ⁓ implicit.

confirmation I think will fade out, fade out and will become active confirmation. Yes, it's okay, you can continue. Then the no match is clear. The entered data are too far away from the description at the beneficiary's PSP. That is not necessarily the person you want to pay to, but it is the name associated with the IBAN. And we do not on person identification, but we do on identifying the match between

the account holding name and the account. And that is quite a difference. It's not identifying you as Ralf Ohlhausen, but if it's your account, it's most likely also you, but it is not identifying you. And with that, there is room to say if we spell Ohlhausen, which is not a very common Dutch name, for instance, in a little bit different, one or two syllables changed. We think it's very good, very acceptable that the

say do you mean Ohlhausen as it is spelled correctly. The same goes with the first name. Some in the Netherlands, the first name is not necessarily registered at the account. If you only use the syllables for the first names, then we gave back the registered name either with or without the first name as it is registered. But then in limits. And those limits are to be decided by the responding PSP.

Because the responding PSP knows to which extent it can if the data can accept that the data are close enough from a privacy perspective, because if they do too much, it's their privacy liability as a responding party. So that is why the EPC hasn't decided and I cannot say in detail what the exact rules are for matching, because as I said also in my introduction, Europe is very culturally divided, but also in language use.

and data sets. Some countries have a very simple one, the Dutch keep it simple. So we have a simple Latin character set. But if you go to Greece or to Spain, for instance, or to all the other northern countries in the future, there can be many differences. So the result is based on the assessment by the responding PSP. The rules are to be set by the PSP either standalone or as a community which knows best.

Ralf Ohlhausen 10:02

Yeah.

Frans C. Van Beers 10:22

or together with a provider.

Ralf Ohlhausen 10:24

But maybe maybe a step back first, because I'm not sure maybe we should explain the role of the EPC. ⁓ having basically taken taken up the challenge that was provided by the regulation ⁓ here to provide the rules or a scheme. how did how did that come about? And was it clear that it has to be the EPC? And so now you're leading the task there?

Michael Salmony 10:25

We'll just start from.

Frans C. Van Beers 10:31

Mm-hmm.

Yeah. ⁓ Good thing you put me back on that because for me it's history, but it was a very large discussion at the EPC. Even Javier knows that in his former role, that it was not a given that this non-payment aspect of payments, because it's an addition to the payment, but it's not the payment itself, would be a task for which the EPC was equipped and set in place from its founding.

because the EPC was founded based on the standards for payments and about classic payments and direct debits added with the instant payments. But the VOP is an additional service before you make the payment. And with that, it was not a given. On the other hand, the fact that the rule books for payments in Europe, SEPA, ⁓ written in the cooperation the EPC has,

within the community within SEPA with all the countries involved and all the payment providers involved. Actually, there was only one who could do that neutrally, not on a commercial basis, but neutrally as a sort of standardization body. But standardization plus because it's not the basic standard. is more a how do you apply or combine the regulation with this basic way of forward based on standards in technology.

So the rulebook is an intermediate and with that the VOP fits perfectly, the verification of VOP rulebook fits perfectly in the work the EPC does on a neutral basis for the whole community, leaving room for innovations or additions by individual parties or countries or communities. So...

Michael Salmony 12:39

No, it makes sense

to go to the EPC for that. The thing I'm struggling more with is the user experience. I mean, you've been very positive that the Dutch all loved it and it helped them feel safe. And did you just this name check? I mean, in the UK, we've had ⁓ confirmation of pay as it's called there for years and it's horrible.

Frans C. Van Beers 12:50

I'm here.

Michael Salmony 12:59

It takes me through, don't know how many screens and is it re we have to check. you really sure you want to check? Are you going to check? Are you okay with the check? It's going to use your data. Is it okay to use your data? You see his name is Sam. It could be Samuel. And you know, you just feel like, and it could be a fraudster. And even if there's a match, it could still be fraud. Are you sure you really want to go ahead with this payment? It's frightful. It makes me feel like I'm committing a fraud. I don't feel being helped at all.

Frans C. Van Beers 13:27

Mm-hmm.

Michael Salmony 13:27

It's more

a cover your ass exercise to put it plainly, that somebody is trying to make sure it's not their fault if I send the money to the wrong person. Are you sure this isn't going to be happening in Europe?

Frans C. Van Beers 13:30

I'm out here.

Of course, I cannot be sure because your experience proves that it can go wrong. But my experience proves that it also can go right. If you look, starting with the user experience as a design principle, and actually that's left to the market. The EPC has the common basic standard to exchange the data to interact between PSPs to exchange these data to give that check possibility.

and to give either one of the four responses match, no match or close match with a suggestion or technically not feasible for one reason or the other. How you do that is in the commercial space. And as you illustrate that you can do that perfectly or you can do that a little bit less perfect. And what we see is that

Michael Salmony 14:30

Thanks to implement

it properly. ⁓

Frans C. Van Beers 14:33

Sorry, I don't want

to criticize the British financial industry, but the way it was introduced in Netherlands was with a pure customer focus. How do we do it gently, including giving the warnings back? But you should not have to do six or seven screens in the Netherlands. If you put in the name, before I could type the amount, it will give back the name. The name is matched or the name is close matched. Do you accept?

And if the latter is, the last one is no match, it says be careful if you continue now, check again. And that's all. So if you keep it simple or basic and very transparent, I'm of the belief that it will land softly in the market.

Michael Salmony 15:25

I think Javier, you wanted to make a comment.

Javier 15:27

Just

to complement Frans ⁓ answer and to cast light on some other aspect on the VOP, which is history on how it was born at the EPC. It was a tough debate more than one year ago when PSPs realized that there was such a need to do something at the EPC, at this neutral hub or neutral node.

that has to do not only with the functionality of the VOP, but with the directory services underlying the functionality, which were very infrastructural. And the controversy at the EPC was that this was something operative. So this was new to the EPC. It was not just the rule book, which is the VOP rule book that could be done, but entering into the area of providing operating services such as directory service was something new that

even required the amendment of the bylaws. But this was, I think, something that was backed by a huge majority of PSPs around the EPC, that there was such a need to someone providing not only the VOP rulebook, but also the necessary ⁓ directory services underlying the functionality. And that's why it grew at the EPC this...

mission to provide that requested by the PSPs. what I see now is that we have not only those near payment functionalities, non-payment functionalities like the VOP, but also the directory services that could give way to many other solutions and many other functionalities, ⁓ payment and non-payment activities.

Frans C. Van Beers 17:21

If I may add to that, Javier, actually it's also the evolution of the EPC as an organization and its role in that. And that directory services you already mentioned will also be available. I didn't mention it earlier, ⁓ for Request-to-Pay and SPAA. So by design, it is open for those three, SPAA, ⁓ Request-to-Pay and the VOP to serve them.

to also to give them that interoperability because that's the main key element of the VOP rulebook is there to facilitate the interoperability between the PSPs either directly or via intermediary parties which were also new in the month.

Ralf Ohlhausen 18:05

Yeah, well on that one, because, okay, you've explained how the EPC is venturing here beyond the traditional role of providing the rules or rulebooks ⁓ into providing some infrastructure like the directory service, which has to be like a central thing. And therefore, I guess the decision is right to have that also in the well hosted or homed by the EPC.

But it is not going into the actual infrastructure of the connectivity between, like in the same for all the SEPA schemes, the infrastructure is done by external players. So here, these are the, I guess, the so-called routing verification mechanisms, RVMs, ⁓ that are providing that physical connectivity, connection.

that you then have to use or can you use, can you do it yourself as a PSP?

Frans C. Van Beers 19:10

per design.

Based on our starting point as a task force and now in the working group is that the VOP obligation lies individually on each PSP. So each PSP must adhere to the scheme and must be open for the service. With that, like payments, you could do everything yourself. But also like payments, the number of participants is that large.

that you need concentrating points for that to make that more efficient and reachability more organized. And ⁓ for that, the RVMs are in place, but under the liability and supervision of the PSPs from a rulebook perspective. So you can, as a PSP, directly enter the VOP interoperability by saying, I'm open and please send your request to me directly.

Or a PSP can say, it's too much burden for me. I would like a service provider, especially for that. And I find an RVM or routing and verification mechanism provider to do that for me. And that can go from only reachability to also providing the algorithm or other services. Well, that's up to the PSP based on its coverage by itself, as well as its capacity and capabilities to have that in-house or outsourced.

But having said that, the operational activities can be outsourced, but the responsibility and liabilities remain at the PSPs. And contractually, they can arrange anything bilaterally with their RVMs, to which extent they request that from them as well. But in the end, like CSMs, are not responsible for the payment. RVMs are not responsible for the VOP.

Michael Salmony 21:03

I have more of a policy question for you, Frans. One of the themes we have in the Trilogue is to say the industry should organise itself. In fact, that's one of the things that we do here. We do cross industry dialogue to solve things. Now, VOP was introduced through regulation. Now, hand on heart, would VOP have happened if the regulator hadn't stepped in? Would it have been even better if the industry had organised itself? Or are you happy that the regulator came in?

Frans C. Van Beers 21:31

My opinion is as good as anybody else's in this area because having done the rule book and having done the discussions in Europe and also referring to what you said earlier, not always the best experience in some countries, I cannot predict whether it would have evolved in this way. There were some movements that some VOP or confirmation of payee

providers sought each other between for instance the Netherlands and France there were some contacts to say can we exchange your implementation with our implementation but in general I would say like with payments the true boost and the true push for full reachability will come from regulation in the end

It happened with payments, happened with instant payments, happened with direct debits, and it now happens with VOP. The one thing, if I could make a comment, and if somebody is listening outside the payment industry, but more on the regulatory side, is that it should not go that far that it should define operational requirements. should better, the regulation should better define obligations and outcome of

those obligations to what end users leave it to the industry to design and to implement and to find the ⁓ technical solutions for that. VOP in that sense has not those hinders, but on the other hand, we for some countries are missing some elements like the text ID to be used in some countries as an identifier instead of the IBAN is not possible yet.

It would have been for some countries very nice if that could have been directly from the start, but that will now be an AOS, an additional optional service. So would that have been as far as it is today without the regulation? No. Would it have been happening without regulation? I can't say.

Javier 23:39

If I may, ⁓ think regulation is needed when we need to go a step further in uniformity, in homogeneity, in the creation of the single market. Because VOP here and there, we have national solutions with national flavors, with fragmentation. And to avoid that fragmentation, we need some kind of regulation. that's, would say, the bright side of the medal.

we need some kind of regulation to align and to bring this homogeneity to the market. Then I fully agree with Frans. The other dark side of the medal is that if it goes too far, it's interfering, it's creating friction, it's not allowing the best solution to be devised. But ⁓ if regulation remains in the smart remit, it's very useful because it helps accelerating

this kind of pan-European market, a single market that still needs to be ⁓ fully built.

Ralf Ohlhausen 24:46

Yeah, but on the question on whether it's going over the top. Well, Michael, you mentioned that the experience in the UK is difficult. But at least if I understand correctly, you only need to do it once if you sign up a new beneficiary. So you don't have to do it for every transaction. It's only when you add someone new into your like allowed list or whatever beneficiary list, then you have to do it. So it's like a one off.

Here, we are now having to do this every single time. isn't that something that is really going over the top? Could we not have a better solution for that?

Asking you Frans sorry. ⁓

Frans C. Van Beers 25:32

Now asking me, I thought you were addressing Michael, that you'd answer this question.

Javier 25:35

Yeah

Frans C. Van Beers 25:35

⁓

Michael Salmony 25:36

Yeah.

Frans C. Van Beers 25:41

Yes and no. The burden of IT developments and administrations is the aging of data. And you never know whether somebody you put in 10 years ago is still having that account or is still the yet maybe they have divorced and you want to pay to the one and not to the other or people have married and they say we have joined forces. And so there are many instances which

those data can be outdated. And secondly, it's a matter of cost. I think the underlying question in your, the underlying thing on your question, Ralf, is that you are afraid of, sort of assuming that the cost is high and that the impact is high and that the efficiency could be very low.

not the feedback we had in the Netherlands when introducing it. In modern technology, with modern technology, you can do it in a flick of a second. If the rails are straight and very well stretched out, within a few seconds you can do it. Why shouldn't you do it and keep the data where they are at the originator or the beneficiary party and not

as a copy on your own, so that you are always sure that it's okay.

Ralf Ohlhausen 27:06

Yeah, but

talking about cost, which is, of course, very interesting here, I think, as well, because we, I think, can be proud that here in Europe, the cost of a credit transfer is pretty low compared with other places in the world. So we have driven efficiencies in account to account transfers. And well, everyone knows that the even the ECB central system like TIPS is charging very low fees.

for settling instant payments. generally speaking, the cost of doing account to account transfer is probably the lowest of all types of payments. Now, introducing VOP in addition to every single one of those payments, do you think it will be a negligible part additional incremental cost, or will it be a significant incremental cost compared to the otherwise cost of the payment?

Frans C. Van Beers 28:04

I'm in a lucky position with the Payments Association that it's not my burden to address. So I can only say what I hope it will be that in the end, looking at all four of us long experience in payments, efficiency is always the driver. And when it's too dear today, it will drive to a more feasible, acceptable efficiency level tomorrow.

And if you can't do that or you have legacy systems that will clean out as well in due time. So I don't think if it's an obligation, it's simple and straightforward. I hope the incremental cost will be marginal to the least not overriding the cost of payment. And as it is a standard part of it, let's see how that will evolve.

But if you want to throw answer to that, ask the PSPs what they have to pay to their RVMs today and what they expect from them to pay to tomorrow or the day after.

Michael Salmony 29:06

But it's not only a cost question, it's also the, I mean, I have this obsession with user experience. It's also the topic of consent fatigue. You're getting another screen or another seven screens in the case of the UK where you again have to click on something and say, yeah, yeah, yeah, yes, I do want to make the payment shut up. know, it's like the privacy pop-ups, which have become completely meaningless actually, because people just...

click on accept or reject, they never read anything, it is to become yet another screen which you need to get out of the way. And that's something that has caused me to turn here.

Frans C. Van Beers 29:39

Again, sorry to disagree, the quality of the user experience can mitigate that quite easy, at least. And I invite you to open a Dutch bank account and see how it works and then challenge your other parties in the UK maybe to how to do that. But having said that, not boosting about the Dutch market as such, but ⁓

It doesn't have to be difficult. And yes, if it's another screen, it will indeed be a burden, but it doesn't need to be another screen. It can also be a pop-up or a line in your payment interface as well. And with that, it's very smooth. You can change color, apart from colorblind, of course, because that's this accessibility act. It's another thing. The text must be correct, but color can support. ⁓ And then it's also automatically in the flow, ⁓ I would say.

And with this optimism, I sometimes have to convince also my VOP group that it can also be easily done, of course. But then they have to convince each other to the common standard and then we see what comes out. But that's all in the user experience corner. So, yeah, I hope that both the cost as well as the user experience will be acceptable for the market and that we get used to it as we got used to IBANs and got used to international payments or cross-border payments or separate payments in an easy way.

Michael Salmony 31:06

Javier, think you had a closing question.

Javier 31:08

Yeah,

I know you are busy in the preparations for the 5th of October and I don't want to put pressure on you, but you know well that one of the motives of the EPC is that it's a forward-looking organization aiming to anticipate the future. So have you had time to start thinking on what will be needed to be done after October 9th? provided we arrive alive to October.

Frans C. Van Beers 31:35

Yeah.

Javier 31:37

What will we need to do afterwards?

Frans C. Van Beers 31:39

There are two sources for that. One is the things we picked up during our discussions as ⁓ required requirements for some communities. And that's also the additional fields to the IBAN and the name for some countries to support additional services for that and to make that standard. The second one is the business to business because we didn't touch upon that, which is quite a high discussion topic.

that we have decided that we will look into that because some countries are standardizing the VOP for B2B business to business or business to bank actually for bulk I have to say and to see whether that can be standardized if you are multiple bank as a corporate but that is in the commercial space. The first discussion we have to have there is are we as EPC community in a position to give some standardization although the fact is that some countries have it already.

Okay, so we'll see about that. So yes, we will be forward looking. We will be looking into the additional services which are becoming a common standard and then added to the rule book. We have to decide which, we haven't decided yet when we will produce a new rule book or an update of the rule book, sorry, it's better to say, because as this is only fulfilling the basic needs for the Instant Payment Regulation.

with that leaving out quite a lot of opportunities. I think that the rulebook, work block will be quite busy the next few years to discuss and to populate that and to get input for that. But then it's up to everybody to invent a change cycle is there to bring their wishes forward and see where and then we see where some community is evolving.

Ralf Ohlhausen 33:25

But talking about forward looking, I have also one more question or let's say a comment. think I found it very interesting that

choice have been done here by going the API route, as opposed to the more traditional back end banking connectivity, etc. So this will be the first time, or let's say the second time after PSD2 to that every bank has to provide some API access, and it will be more importantly, the first time

Frans C. Van Beers 33:42

Mm-hmm.

Ralf Ohlhausen 34:04

that every bank has to actually use the API's of the other ones, which so far was sort of only the joy of the TPPs. And now, what do you expect there?

Frans C. Van Beers 34:19

⁓ Because it's obligatory, will happen. ⁓ And PSPs having not the appetite to use APIs, they can use the RVMs to go to your RVM to do that. So that the connectivity is in between the RVMs, routing and verification mechanism providers, so that they can interact on API level and they can decide with their customers, i.e. the banks.

the PSPs I officially have to say how to do that. So that can be mitigated. it was the assessment that APIs were the best technical way forward. With that introducing some XML ⁓ API translation issues, but for that there was an additional set of, I think, seven or eight characters which will be added to make it exchangeable with JSON. So

For that, that bridge is closed or laid. ⁓ also, ⁓ although ISO 20022 XML is the standard for payments, it was decided it was not necessarily the one also needed for ⁓ the VOP. And maybe speed wasn't a topic, but I wasn't in those discussions, so I cannot comment on that. But what we see now is that

Everybody has now its own option to test and to implement and to ⁓ give the service back to their customers as well. the, the, sorry, rephrase for the inter-PSP, it's APIs or inter-RVMs, but customer to bank can still be the classics, whatever you want, XML or other. And with the PSD option already there.

We built upon that, there are some elements are reused for also introducing the VOP, IPSPs. And is that challenging? We will see. Nobody can object now because it's accepted in the EPC as a community that this is the way forward.

Michael Salmony 36:33

Okay, Frans, thank you very much for standing up against all our questions here. You've given very robust responses everywhere. I wish I could share your optimism about the user experience. I'm afraid EPC is wonderful at producing rule books. There's huge success in that. their user interface things...

The IBAN, you know, that was not the greatest invention for consumers, I think, right? With, don't know how many digits and lots of zeros in the middle. Lots of countries call it IBAN, the terrible. I mean, as soon as you get into the consumer space, I think it gets difficult. But I hope you will develop a Dutch model and not a British model. And therefore the consent will go very smoothly. So thank you to Frans and to Ralf and to Javier for this episode on VOP.

which of course is on everybody's mind since the deadline is looming and everybody will be impacted on this. So thank you and I hope you who watched this enjoyed this episode. Thank you.

Frans C. Van Beers 37:29

Okay. You're welcome.

Javier 37:35

All the best with the launch, Frans.

Frans C. Van Beers 37:38

Okay, okay, thank you.