REQUEST TO PAY

Michael Salmony 0:12

Hello, my name is Michael Salmony and I'd like to welcome you to another episode of the Payments Trilogue, this time with Javier as our new representative from the banks and Ralf as always from the Fintech and TPP side. The topic we've chosen for today is Request-to-Pay. That's a topic which many have been talking about, I think for over 10 years, which sort of rather reverses the flow.

which means instead of me entering all the details and then paying, the merchant comes and tells me and I just have to confirm it on my mobile. And that sounds like a great idea, but it doesn't seem to be getting quite as much traction as some people have been hoping. So maybe Javier, you can tell us a little bit about the history and where we are now.

Javier 0:58

Yeah, think that the roots are even deeper than 10 years ago because the sparkle that initiated the Request-to-Pay was work being done around e-invoicing. So that's the conceptual origin of the idea of the Request-to-Pay, the idea of ⁓ having much more efficient flows in the invoicing cycle.

⁓ But ⁓ we were in the environment of launching the SEPA ⁓ instant creative transfer. And ⁓ yes, the idea was that there was something missing so that the instant creative transfer could also be used not as a push instrument, but also as a pull instrument. So that was the origin.

And this got a big push at the ERPB, the Euro Retail Payments Board. And a group was established ⁓ to design and to dig deeper and analyze what was really needed. ⁓ So that was the origin. And it was probably now responding to why it is not getting traction.

I think also in those origins, the aims were very ambitious. So it was a general, for all purpose, Request-to-Pay. So it included, I wouldn't say everything because there is even more to the Request-to-Pay, but a lot of details, a lot of functionalities, a lot of factors were added in. And probably that's one of the obstacles to deploy it.

because it needs to be ⁓ landed, it needs to be made a little bit more concrete, specific to the use cases. And probably that's one of the reasons why it is not getting enough traction just at the very beginning. But it is getting some traction. There are some communities that are joining the scheme that are adhering and that are deploying some ⁓ use cases ⁓ trying to use it.

What is still a consensus, it is that it has a huge potential. So still it is perceived as something that is needed, the one missing brick, and that eventually it will be deployed for general purpose ends. But we need to find that way, how to do that. But ⁓ I think everyone is convinced of the value.

And probably they need to get some projects that get priority in the different environments. And eventually it will succeed. But still we need something more to that to be realized and some more work and some more agreement on that deployment. Because as usual, we need a network, not only just some very much convinced.

evangelists but real ⁓ users and users of the instrument.

Michael Salmony 4:22

Yeah. Okay. I mean, before we go to Ralf to fill us in a bit more on the details, I'm still a bit puzzled why it isn't taking off more. It sounds such a great idea. The merchant fills in all the details, so it's really convenient for the user. Also, the merchant doesn't have any reconciliation because of course all the reference codes already in there. The amount is right. You know, it sounds such a great idea, but I believe at the EPC, where normally the schemes are adhered to by thousands of banks,

Here there's actually a record that the adherence is less than the version number. I think there's about the four versions of the rule book and only about two adherents. So that's quite puzzling. ⁓ Ralf, maybe you can tell us a little bit more. What's going wrong and how do we fix it?

Ralf Ohlhausen 5:08

Well, there is there is definitely a chicken and egg problem here. And I think we'll come to it. But ⁓ before going there also and looking back and how we got to where we are here now, because I was involved, actually, I was watching it more from the sideline when it was all focusing on on like, invoicing and all that, because that wasn't ⁓

close to the job I had at the time. ⁓ when then it the the working group decided to enlarge the scope to e commerce. Then I thought, okay, well, now here that's ⁓ right, there was the right down my alley and then I joined that working group or multi-stakeholder group as it was then to

make sure that what has been prepared and which in my eyes was designed by banks for banks. So there wasn't a use case or actually room for non

ASPSP. So because it was all about having an ASPSP on one side, so one bank and another one on the other side. And then you have like ⁓ the merchant and his bank and the consumer and their bank, they would have this Request-to-Pay between them. And obviously, then it's the bank A and bank B. ⁓

Yeah, exchanging that those messages and of course, it was meant to be actually creating a payment. So just doing this just exchanging the message back and forth, say, do you want to pay this and the customer says, Yes, I do want to pay this. That is not enough. So the real value was created by then actually making the payment as well.

not just a message, do you pay? Yes, I will. But then actually, yes, do the payment. So that's where these requests to pay service provider on each side of the message would be banks would have to be banks, because that's then that the one could actually then execute the payment and the other one could receive it. So that's how this was initially designed.

And so therefore, from a non ASPSP perspective, non banks perspective, I felt, okay, well, how can this be turned into something useful and manageable, especially because, and of course, coming from the PISP side there, PISPs have their own Request-to-Pay. So they have their every PISP has a Request-to-Pay system built into their systems, or it is basically helping the merchant to

get to request the payment and then getting the payment initiated and etc. So it also looked a bit like maybe a threat to from a PISP perspective to have this now standardized in a way which is sort of more suitable to banks. And that's how then well, ⁓

brought in some suggestions that would change that. In particular, the actual initiation of the payment, so not just the message, but the actual payment afterwards, could also be done then and initiated by a PISP and not just by the bank, so that the consumer side could be handled by a PISP. This is how

⁓ that got in and, ⁓ I don't know if I shall continue explaining, ⁓ because it, essentially what that meant was that, ⁓ we could, you could receive the Request-to-Pay message from the biller side of the merchant side. And, ⁓ and, but, ⁓ the PISP would then turn it, well, basically take it off.

the SRTP rails and put it onto the PSD2 rails to initiate the payment and get the customer's consent for or the answer from the customer, like the Request-to-Pay. Yes, I want to make the payment as part of the SCA, as part of the execution of the payment already. And then basically take it back from there onto the SRTP message rail.

and over to the recipient side and the merchant, etc. So that helps or would help if it was to be taken up to actually address that chicken and egg problem. with that, because one of the problems today is that all the billers or the merchants, they may not use it because they can't reach all

because not all banks are participating and so they can't reach all the customers of all banks. They can only reach, say if one bank is participating, they can only reach those customers of that bank. And of course, that's not what a biller or merchant want. But through the use of or combining it with PSD2 or the open banking, you can actually resolve that. And you can, as a merchant or a biller,

via a PISP, you can reach every one of the 400 million something payment accounts in Europe.

Michael Salmony 11:10

That's a really interesting variant or maybe even a better way of approaching it through the open banking and PIS and TPP variant, which I don't think many people are thinking of. That's really good you raised that. I mean, the way I always think of RTP is in the Nordics, right? You open your online banking and you can see all your transactions and you have another tab which says sort of outstanding invoices. And you can see, this is the doctor and this is the kindergarten and this is somebody you don't recognize.

And you just go pay, pay, reject, and you've paid all your bills. If I compare that to how I normally pay my bills, especially in Germany, where everything comes on paper, you whenever the doctor's bill comes, I have to find out where is the IBAN and which amount and which reference code and type that into my online banking. It's absolutely ghastly. And it's terrible for me. And it's terrible for the doctor because I probably make mistakes and it takes days for me to do it. So embedding this Request-to-Pay in online banking is surely such a compelling thing.

and it's been demonstrated in the Nordics. So Javier, do help me. Why is this not conquering the world?

Javier 12:15

Okay, okay, let me try some some additional information. I don't deny Ralf's comment that at the very beginning when banks started to to ⁓ comment or to debate around Request-to-Pay, they were using ⁓ banking use cases. That's what they knew. But even before that, banks were not that much interested in Request-to-Pay because they felt it was not

financial matter. It was more related to invoicing and to the cycle of information rather than to financial cycles. That's why even many banks were reluctant to discuss that because they didn't feel that it fell in the realm of finance and payments, which was their turf. So it took some time to ⁓ convince them that ⁓

We should start that analysis and that debate. And of course, what they bore in mind were banking use cases. So that I fully agree. But it was very soon that the community realized two things. First, the request to pay was already in place. It was functioning here and there. And in most cases, outside the banking ⁓ activity.

So everybody recognized that the real aim was to produce something that could become a European standard. So harmonizing what was already in place. And that was well beyond banks. Banks realized that it was not a matter they possessed. It was something more general. Because even it came from outside the banking activity. So that was first that the Request-to-Pay was in place and that there was a need to harmonize to

to produce something standard. Second realization was that it is not a financial message. It is a communication. It is a message. It's not a payment transaction. Here again, ⁓ this is an important detail. You don't need a ⁓ payment scheme manager to produce something. You need something beyond that. And we had to even to change.

the scope and the mission of the EPC to allow not only payments but also other activities related to but not specifically ⁓ that you could term payment transactions. ⁓ With these two ideas in mind, first that it was already in place and then that it is just a communication, it is not a financial transaction, ⁓ it was very easy to understand that

the whatever scheme should be produced, had to allow all kind of organizations to join. And precisely that was at the very beginning of the first version that was issued already ⁓ allowed all kind of organizations. And this is another obstacle for that because the homologation process is not an easy one. So that I can advance. ⁓

⁓ also tried to make it more efficient and leaner and I hope it will eventually it will produce some ⁓ more easier process to adhere to the scheme. But it was not easy because it was understood that you had to allow both large European banks and small fintechs or even not even ⁓ PSPs. ⁓ many other organizations

anyone can join the scheme. You don't need to be either a bank or another kind of PSP. So that also brings diversity and complexity to the functioning of the scheme, which may be another hurdle for the scheme to take off and get traction. And then I think Ralf mentioned it. ⁓

Here we have another chicken and egg problem. The community has to agree on which first use case is deployed and which is the first aim we really consider to deploy the Request-to-Pay. And that's probably the biggest problem because it is not that they don't want it to be done. It is that they have different or ⁓ more urgent priorities.

Michael Salmony 16:56

Yeah, I get that and I understand the problem about the ecosystem, which may be even larger than the usual one. It's beyond banks. What I don't really buy, sorry, my role here is to challenge and to disagree and to spice things up and to speak the truth. ⁓ What I'm afraid I don't agree is how anybody cannot see this as a financial transaction or payments, right? It is a message, yes, but payments is full of messages. Swift is only messages, right? Lots of people think it's payment.

Ralf Ohlhausen 16:56

Yeah.

Michael Salmony 17:26

It's actually only sending a message. So why this thing should suddenly be excluded from the bank's thinking, I don't really understand. But Ralf, you help me out here.

Ralf Ohlhausen 17:34

Yeah.

Well, it I think it was structurally important to decouple it from the actual payment. So you have the message first, and then you have them, you have the payment second. And one reason for that is because you may not want to do the payment right away, you may only agree to pay next month, or next week, or you may only agree to pay half of it, or in installments. So this was spilled into the scheme.

allowing those functionalities. Or you may also say, No, I don't, I will not pay. So those are all possible answers. And, and therefore, I think from a logical perspective, structural perspective, it is right that ⁓

It is separate. that also meant, as Harid just said, that the service provider, the SRTP service provider, so the companies, the entities to participate in the scheme, they don't have to be PSPs. It is a messaging service and you don't need much license or whatever. You definitely don't need a PSP license just for that. But if you're not a PSP, if you just do the messaging, then of course you cannot provide

You can't combine it with the actual payment and therefore you have more complexity than well, how then to actually do the payment if yes, it shall be done and whatever in installments. So this is why I said is that there's a clear advantage. If the service provider is a bank or now at least a PSP in the sense of including also TPPs, because then you can do both. You can handle a message and you can then do the payment itself.

And so that's why I think it is indeed true that it is still of a big advantage to any to PSPs versus non PSPs playing the service provider role. But I think one other element, I mean, we sort of alluded to it, but it's, ⁓ I think one of the issues is that ⁓ a lot of the the interest

is on the receiver side is on the merchants at the biller side, the one who wants the money. But much of the work is on the issuer side on on on well, allowing customers to make those payments. And but then you can't charge the customer for it. So I think it's a business model problem. Again, once more, where

You have the acquirer or let's say the recipient side, that's where the money is and you have the issuer side and they want to have some share of it. well, as long as we don't have an interchange built into this SRTP, we'll have that issue then again.

Michael Salmony 20:26

You get into interchange models.

Yeah. So you start getting into interchange models, but I think you're right. I mean, if it's all in the hand of a bank and that's what we saw in the Nordics, right? Where they understood in many areas, right? They saw that banks doing identity is a good idea. They saw that doing Request-to-Pay, putting it in your online banking and putting it in your mobile app. So you just confirm it. I mean, I don't see the obstacle.

that there might be several responses that I want to pay it in installments or I don't want to pay at all, or I want to pay later. When the thing pops up on my mobile banking app, I can decide how I respond to that, right? So I don't see a problem. In fact, I see it as an advantage that you can decide when you pay and you can add installment models and all that. Javier, I think you had something to add to that.

Javier 21:16

Yeah,

yeah, well, I was trying to better understand you when you say that it is not financial. Well, it all depends on how strictly you speak, because everything life can be financial, political, social, because we live in a financial, political, social world. So, yes, it is financial because it belongs to your financial life. But when you go more strictly to the meaning of that kind of transaction, it is not a financial transaction. There is not a movement of funds.

Because in that sense, also verification of payee is financial because there is a payee. So you could term that transaction as a financial transaction. But here as well, with the Request-to-Pay, the verification of payee, strictly speaking, is not a payment transaction. It is a information exchange, which goes beyond payments, goes beyond ⁓ even financial because you can have a verification of payee for many purposes.

not simply to initiate a payment. You can have a verification of payee used to, for in many cases, for open finance and other ends, not even closely related to any financial transaction. So it's a question of understanding and how you define, how strictly you define the scope of financial transactions.

Strictly speaking, it is not a financial transaction. It is an information exchange. it belongs to the core of finance, and it can also be more remotely connected to finance. That's one of the virtues and also one of the complexities of the scheme, that it belongs to that world in which it can be very, very financial, but it can also be used for other purposes.

which brings richness but also complexity to deal with and to really identify ⁓ which could be the most interesting ⁓ use cases. As for the economic model, yes indeed, it's a bilateral ⁓ market. So here we have costs and values being distributed unevenly. And probably there is a need to have an underlying economic model as in many other network.

activities. ⁓ Good thing is that I don't see that there is any obstacle for that to happen. So you can deploy an economic model. I think there is no rule against that. In this case, not from the regulatory side. ⁓ So I think it can be ⁓ thought, analyzed and deployed with that economic model underlying the transactionality.

Michael Salmony 24:13

Okay. I mean, I think it's a bit nitpicking, quite honestly, sort of whether it's inside the payments and financial space or not. But I take your point and I think a lot of people have been using it as an excuse so they could not think about that topic. mean, there have been some confusions also with the invoicing, right? I've spent far too much time in my life on invoicing to know there's always a confusion whether an invoice is a different thing to the payment of the invoice. Those can be done in two very different ways. And there are...

links, of course, interconnections, but one is not the same. Yeah, mean, what I'd really like to hear from you is, in the last few minutes, do you see any chance of this taking off? always the regulator, again, have to force the banks again to make it happen for the benefit of the merchants and the consumers.

Javier 24:47

to me the most.

Ralf Ohlhausen 25:00

Yeah,

if I may say so, yes, I do. And I think that it is so the value has not really been ⁓ understood, or come to the forefront, but it will. And actually, I mean, and it's not sure, I think it's also a matter of what are the alternatives. So I think one of the reasons is that, you know, we have

card on file, have direct debit, etc. You have alternatives at the moment for billers. So most of the billers have many alternatives on getting their invoices paid and all that and also for merchants. So therefore, I think the more developed it is, the country, the more alternatives. And actually, you know, I worked around the world and moved from country to country every few years and always left behind

a legacy of things still to be managed. And most of this was in the developing world. So it was pretty poor countries, but they did have, and that was maybe one of the reasons why they did have this e-invoicing built into the banking. So the only way I could actually handle this after I left was because my bank had, within their online banking, had the ability to pay all my bills still going and all of that. So...

This is not something which is it is, guess, usually in some countries and you mentioned Nordic so but but not in others, not in Germany, for example, I guess not in France. So but I think it will come because ⁓ and I think one driver for it is the security of this messaging. And

The more fraud we have and the more artificial interactions we have, the more fake messaging we have, the more we are prone to issues on using SMS or WhatsApp or other alternatives to exchange messages, the more value people will see in having a very secured, end-to-end secured messaging for payments.

Michael Salmony 27:22

Yeah, that's.

Ralf Ohlhausen 27:22

and

only rely on that and not on more dubious ways of messaging for payments.

Michael Salmony 27:29

I mean, I agree with your point that we need more security because we have lots of scamming and fake messaging. I'm not quite sure how RTP helps in that case. That's one thing.

Ralf Ohlhausen 27:40

Well,

it is a message that is controlled by ⁓ a scheme in this case. You have a service provider on one end and an end on the other end, and they have their connections to their customers on each side. So it is an end-to-end controlled, secured message.

Michael Salmony 27:57

If you're sure, it's really coming from a validated entity, which we don't have fully.

Ralf Ohlhausen 28:02

Well, within

the scheme that is ensured.

Michael Salmony 28:06

Yeah. And the other thing I would say, I mean, surely one of the joys of RTP is I can pay it through any of the rails that you mentioned. I can pay by card. I can pay by bank. I can pay by wallet. I can pay by crypto, right? This is again, it leaves the choice completely to the customer. So I think that's actually speaks for RTP. But Javier maybe you want to say the final word.

Javier 28:26

I

will give my view. I think with many other things there are two hands. On the one hand, I'm being optimistic. I come from a community from Spain. And you mentioned there are very few adhered entities. All of them come from Spain. And there are plans in Spain from the Spanish community to adhere entirely to the scheme because there have been tests and more than tests, actual

transactions, more than hundreds of thousands, which have been very successful. the trials and the first experiences have been very positive. the whole community is moving into that, starting with focused use cases, but aiming to have a wider scope. So that, I would say, signals that the market would be willing to deploy and to push for the idea. That's, I would say,

good thing because eventually in other communities some use cases will be found and later large organizations will require that to really happen on a continental basis and then it will become the international element and that would be the logic underlying the deployment. there are market forces in favor of that happening. So that's my optimistic side.

On the other ⁓ hand, I think it's still a weak ⁓ project. So if there are many other priorities coming from the outside world, from the authorities, they can suffocate ⁓ this to be an idea. So I think there are risks if the communities have to ⁓ deploy different things because of different purposes and different mandates and different priorities.

they may kill the Request-to-Pay baby.

Michael Salmony 30:24

Very good, Javier. Those are wise words. Your predecessor was always known for saying everything was invented in the Netherlands. So it's very good to have you now to point out how many clever things have come out of Spain and that maybe Spain is, I mean, Spain was one of the first in open banking and now I've learned that they're also one of the...

Javier 30:40

Even financial

ideas that Dutch people say were born in the Netherlands came from ⁓ Spanish and Portuguese immigrants. So, but that we can discuss history on another episode.

Michael Salmony 30:51

Like what?

Another

time. Okay, fine. All right, then I think we've reached the end of our time. Thank you so much, Ralf and Javier, for the lively discussion as always on Request to Pay. And I hope the audience enjoyed this as much as the other episodes. And please do continue to follow and watch us if you find this interesting. you.

Ralf Ohlhausen 31:16

you.