PSR & PSD3

Michael Salmony 0:02

Welcome to the Payments Trilogue, where three seasoned professionals discuss payments and more, for Europe and beyond.

Michael Salmony 0:13

Hello my name is Michael Salmony and I'd like to welcome you to another episode of the Trilogue, where my good friends Ralf and Gijs and

Michael Salmony 0:20

I am going to discuss another topic around payments and regulation. The topic we'd like to discuss today is PSR and PSD3. The background for those of you who may be outside Europe is we had this PSD2, which basically kicked off open banking in a formal way that came out about 10 years ago. And it was felt it was time to update that.

Ralf can tell us a little bit about what the thinking was there. And also to have not just an update of the PSD2 into PSD3, but to also add a regulation which comes into force immediately. So you don't have all these transposition woes. Actually, some people see that more as an RTS2, but enough of these acronyms. I think it's best to pass on to Ralf to explain what it's really about. Yeah, many acronyms. That's true.

Well, yeah, you said it. PSD2 is almost 10 years old now. I mean, to be fair, it really only went live in what is it, 2019 or five years ago with the RTS. And yeah, well, it is actually also true that it was more the RTS, regulatory technical standards, which became very controversial as opposed to PSD2, which was the underlying directive there. So

The experience that we've had from a TPP or open banking perspective has been quite mixed. I think it depends a bit on the country because for some countries we had a, I would argue we had a more open banking before like Germany or Austria, Nordics, some countries. But in other countries where there was banking was completely closed before like the UK or more Southern European countries.

There, of course, we had now an improvement. But nevertheless, there were a number of things which are not going right, have not gone right, and we were looking forward to the review of PSD2 and PSD3. We also agree that I think it's a good thing to have put more into regulation, so it's not just a directive that every country can adjust a little bit.

Michael Salmony 2:43

And so with the overall process that the commission had done to review PSD2 and also their suggestion and then like having this PSD3 and a PSR separately, I think we all agree with that.

Now, the two big, well, there are a long list of things that, of course, that we wanted to have improved. But let me just focus maybe on two, the top one from a PISP payments, payment initiation perspective was that with introduction of PSD2, essentially we lost the ability to

establish the level of payment certainty on our own side. there is obviously a difference between initiating a payment and executing a payment. And so you only want to initiate a payment if you are really sure that it will get executed. Because if you initiate it, it is not getting executed afterwards, say on a batch process overnight, then you are in trouble.

as a PISP because you've probably just told the merchant in real time that, yeah, initiation went well, but then if the money doesn't arrive, there is a big problem. So it's a surprising thing for many people. So maybe just to do a quick interjection, because many people do think initiation is the same as a payment. But sometimes somebody can take money out of his ATM account and then there's not enough and then the payment doesn't go through and various other things can happen.

right? and real. Yeah, and there's even people doing doing this deliberately. So they're you know, they go shopping from next from the ATM machine. So they they they shop online quickly, and then they pull the money out from the ATM so that the payment will fail. And they may get the goods and the money will not obviously cannot leave their account anymore. And yeah, so we have we have that. But unfortunately, with the RTS or actually,

Michael Salmony 4:46

the interpretation of the EBA about their own RTS here was that, well, a PIS or payment initiation service does not need any account information. So it's only like you basically kick off an initiation without having any information about the account. So that was their interpretation of how it should work. said, well, it does not. We need to know first.

What is sort of on the account? What is the balance? How much margin is there between the requested amount and the actual balance? And there are many, many other parameters that you get a look at because if the risk is too high that the initiation will not turn into an execution, you will not initiate. in the law, unfortunately, it is saying that you're getting some information after

the initiation, but we needed before the initiation. All this goes away when we have instant, right? This is more historical. well, fair enough. So we hope that the instant payments will reduce that problem significantly. Well, we're looking forward to that. But we're also, of course, hoping that the corresponding stipulations in PSD3 or actually PSR

will be amended so that there is this possibility to look at the account. And by the way, yeah, we know that there and said, okay, well, you just need an AIS license as well. And then you look, you use AIS to look at the account beforehand and then you do the PIS. And maybe that would have worked out, but then you need a second SCA for that. And of course, that's what you can't do. You can't have in one payment two SCAs there, one for AIS and one for PIS, which is why that solution didn't.

work. Anyway, but actually talking or coming to AIS, the biggest issue from an AIS perspective has been that problem that you needed the customer to do the SCA in many cases and with the 90 days exemption not always being applied and well.

Michael Salmony 7:06

We actually had a change of the RTS. The only one change of the RTS that has happened in the last five years was that this problem was addressed, in our mind, really only by turning it from 90 days to 180 days, whilst there would have been better solutions. And that is what we are proposing here. if you are looking at AIS, it is a...

It's more similar to like a direct debit, a mandate. So the customer is mandating that the AISP, the TPP there to act on their behalf, to look at the account on their behalf. And, and once you do that, then it's not the customer's credentials and it's not the customer who should authenticate there and being woken up in the middle of the night when we update, you know, whatever their, their, their account information.

It is the is the TPP is the AISP identification there. eIDAS certificate. That is what got to be controlled when then an AISP is accessing it. So this whole thing of having a customer doing an SCA and in the process of an AIS is when they are not actually part of the flow, which usually they are not, then that's just something that has to change. And yeah, so I mean,

I have a longer list to go, but I just want to start with that. An opportunity to react because a chance to comment on that. Yeah. Yeah, it's quite a sad story, Ralf. Well, what can I say? Well, of course, we've had a long and thorny road behind us with a learning, a steep, eventually steep learning curve. And there was

all sorts of things wrong with PSD2 from our perspective, starting with the problem that banks were forced to give away stuff for free, which is not the right incentive to build good solutions. So that's one of the... It took too long. The law was unclear. We had to wait long for level two legislation as Ralf said. We lost a lot of time in not very constructive debates, unfortunately.

Michael Salmony 9:26

But that is behind us. One of the things we also learned is that it's better to cooperate than to fight each other. And if the law is not good enough, we can agree to build something on top of the law, which we've done in the SEPA payment account access scheme in a multi-stakeholder group where both Ralf and I sit. We're hopefully piloting that as we speak. There's a pilot being organized to see if that can work.

but also to see how PSR still will impact on the scheme because that's built on the P2D2 functionality so we have to reassess what will be obligatory under the PSR and then on top of that we can still have, let's say, premium services because the law will not provide for everything. So we lost a lot of time, that is what it is, unfortunately.

Hopefully we do now know what it takes to reap, as we said, the full benefits of open banking on the continent. We have to also realize it is distinctly different than in the UK open banking with a mandate from the competition and markets authority, very prescriptive on how it should be done. In Europe it's more technologically neutral. We have to have the API specifications from the Berlin Group or STET.

It's much more complex, but I think hopefully we are finding out how to do it. Open banking is here to stay. Open banking has to be a success. Together with Instant Payments, I think it holds the promise of building also truly European, pan-European solutions, next to for instance the European Payments Initiative. So PSR with...

the SPAA scheme on top of it, that should hopefully do the trick to make Ralf happy, provide good solutions for the end users. And of course, we will always have discussions on remin innovations. That's logical, but we should get our act together. Together, we should get our act together now, because by the end of the day, it's only the non-European solutions that profit from us not providing good solutions.

Michael Salmony 11:50

And sometimes we forget why on earth are we doing this to provide, as the Commission says, really homegrown pan-European solutions as alternatives to non-European solutions. We have to always keep in mind why are we doing this in the first place. It's not just to fight amongst ourselves. There is a sort of perceived common enemy out there that we want to also provide an alternative for that. And that can only be done in a constructive dialogue and working together.

So good regulation and on top of that cooperation between, let's say, asset holders, asset brokers, the TPPs and the banks. Otherwise it will again not work because the law is the law, but the law doesn't provide good solutions. We have to do that as marketing participants. indeed that's one. That's a lovely way of looking at it. I mean, we all benefit if we get this working, right? The TPPs.

benefit, the bank's benefit, that's been shown in all sorts of other industries as well. If the incumbents open up, mean, it is way to fight against foreign solutions, which makes me a bit worried why EPI isn't using this technology, for example, why isn't it based on SPAA. But that's another discussion. But maybe we just return back now just back to the PSR.

Ralf, you said you had a longer list of things you wanted to Yeah, I have. But let me highlight here in reaction also something that we're actually not want more regulation. If anything, we want less regulation because I agree that the industry collaboration is the more promising route. we have, that's why we have engaged in SPAA together with the banks for many years now and hopefully bringing it to fruition now.

because if, you want to, if you want to compete in payments, especially retail payments, which I think is sort of the Holy grail of, where functionalities and capabilities that you need, you, can't base that on, on compliance, on forcing banks to pay. Well, so this has to be a collaborative approach. So like a PSD2 is just like a little sort of like a base case where you can do some simple use cases. That's what you can do there. But if you want to go.

Michael Salmony 14:08

to that holy grail retail payments. If you want to compete with the cards and the wallets from the East and the West, you need something absolutely first class that can only really only work based on collaboration, not on regulation. Nevertheless, of course, here we're talking about PSR. And so what we want is not a bigger PSR or a bigger PSD3. We want a smaller and better one. So we want to cut down, but we want to also correct

the pieces which just did not work. So we have learned our lessons hard enough and now we have a great opportunity to improve it and get ahead again of the rest of the world who is trying similar things and are profiting from our errors and our problems. Now, well, we have this opportunity and we should get it right. There was...

One thing maybe also to highlight because we have a long list, the single biggest problem that we have from a TPP's perspective identified is actually the governance or is the fact that we had these three objectives in PSD2, which was about improving security, improving competition, improving innovation. And we've done everything on security and we have done

not much on competition, we have done nothing on innovation. and it's not maybe not surprising because the supervision, the governance of it, so the EBA on the central perspective, but also all these national competent authorities in the countries, not one of them has competition or innovation in their mandate. They had absolutely zero focus on that. And

no one is paying for it. So no surprise that we were not moving there. And that is maybe one of the differences in the UK where the competition authority had a lot of say in their version of open banking. So it was one of our requirements that we should try to get the competition authorities, the central one and also the national ones involved.

Michael Salmony 16:27

into the governance of PSD3 PSR. Now it's not looking like it will happen. We'll just get more of the same. It hasn't been proven that it has worked better in the UK way, If we talk to the people in the UK, they say we seem to be a little bit ahead on the continent now because we have a compensation model they're still looking for.

I'm not so sure which way is better. I think our collaborative approach by the end of the day will prove more. Yeah, well, the collaboration part, I fully agree. And that's why, but we hear, I guess today we're talking about the regulation. I already said that I wanted to have it cut down, not expanded, I it cut down, but corrected. And maybe...

Well, one important thing there is, of course, the interaction, the so-called secure communication between the TPPs and the banks, so essentially the APIs. there is... We had the... With PSD2 and RTS, they introduced a concept of what's called a dedicated interface. In my mind, that is already the core of a big, big problem.

having an interface which is dedicated to TPPs. So having one which the banks have to build for TPPs and the TPPs have to use, which puts it into a unique, I like to call it a monopoly situation. And that is the crux of the problem for many, many of the issues. Now, yes, we want to have

automated or machine to machine interfaces. So APIs, yes, we want to have APIs, but the more parties are using them, the better. It should not be dedicated just to TPPs because of that, of course, opens the door for banks to This is a total misconception because the word dedicated only meant other than the user interface.

Michael Salmony 18:45

So you have the user interface, me as the account holder, I have my interface and we have a special interface for the third party. That's the only, that's a semantic thing. Well, it's, it's, well, it's not, it's not just semantic, unfortunately. Well, you know, if you were screened, What we see today, what we can see in basically every, almost every bank in Europe, they are having a

They are having a very good API, which is serving their mobile apps. So for their mobile, they're basically their mobile API for their own customers. And then they have usually mediocre and in some cases really, really bad dedicated or TPP APIs, which are working by far, not to the same level. And that

Well, it shows two things. So firstly, it's not ignorance or inability that banks don't understand how to do good APIs. They are doing great APIs, just not to TPPs, unfortunately. we need the concept of dedication is what the problem is. We have rid of any unique

Sorry of any single choice because any monopolistic situation is the is the opposite of quality is the enemy of quality what we need is to have a choice of Interfaces to be used and by the way, we also need the contingency in any case So any single one interface, even if it's the best one Will fail one day and we can't build our business on a single points of failure. So we got a half We got a drop

all these technical dependency in the regulation. The regulation got to say, hey, you got to whatever, communicate securely, fine, fair enough, but stop telling us how and with what sort of interfaces and what sort of technology. And by the way, these technologies, of course, will also change. Yeah, Ralf, think your point is abundantly clear by now. Sorry, Michael, to...

Michael Salmony 21:06

But what do you suppose? I'll speak topics. Ralf could continue for hours probably on this one. I know him. But as the ASPSP, they need to know what they have to do, what their compliance bottom line is. So you can't just say, you got to provide secure access. Yeah, right. But how? What? Where? It has to work. You have to harmonize. You have to standardize. Otherwise you

will be the first one to complain that it's fragmented and in Germany they're doing it differently than in the Netherlands and blah-di-blah. So you can't solve that that way by leaving it open. Finding the right balance of telling them what the result should be, stop, full stop, and with some indication on how to do that because otherwise what...

Now you're not being entirely consistent, Sorry, Gijs. You're normally saying the regulator should only say what to do and not how, and now you're arguing to the contrary. Not completely, but you have to have some indication on the how, because if you don't do that, Ralf will complain that it's a fragmented landscape, because every bank is programmed its own how.

And that's not what you want. I don't. I don't. And I know that you think we would, but we don't because building, we have built different API or we have dealt with different APIs even to the same standard because each implementation of the same standard is then a different thing again. So we can do hundreds of different APIs. What we cannot do is making it making them better.

from our perspective. So we can integrate more and more of them, but we can't make them better. So they have to come with sufficient functionality. And it's not just a technical question about availability, which is what the PSR is now focusing on, because the availability is one thing, but the biggest problem of all is the lack of functionality inside the APIs and bringing that to a level. And I'm not talking...

Michael Salmony 23:19

to bring it to the SPAA level. So we appreciate that we are really only talking there on sort of basic functionalities. That's what we, but we've got to get that basic functionality right. And then we can build on top of that. We can have schemes, we can have additional functionality, premium functionality, and yes, we'll pay for it and all of that in order to create something that can, that is really very competitive.

But the problem here is, Michael, Ralf is really an API expert because he works in that field and he knows what is going on with banks and APIs in Europe. I am not a technician. I know shit about APIs from a technical perspective. And the last thing I have is an overview of the performance of APIs across Europe. So I am a bit at a loss here because I cannot.

have any sensible agreement or disagreement with Ralphie because I just don't know. Okay. Well, the solution to this is choice. The banks were given the choice of what sort of interfaces they want to provide. Now the vast majority went down the route of creating new interfaces, addition to that, what they have for their customers. Even if they were API based, like for mobile.

apps, they built another API. And, well, you speculate why they did that. There was no obligation, but they had to be given the choice and most of them did it. Now,

I would assume because these APIs... There is of course the possibility that some did it because they have This is not a sensible discussion because I'm not in a position to discuss this with you. Okay, okay. I can just leave this dialogue. is not a dialogue. Fair enough. I will not go into the technology. But banks were given the choice of doing this or that and if that would have been reciprocated.

Michael Salmony 25:24

that TPPs will then have the choice on which interface they want to use, then that, I think, would have solved 95 % of the problems. Maybe, I don't know. But can we have choice on both sides that counts? But poor Gijs is now struggling with his... Yeah, I'm looking at the time. Let's move on from API. Don't worry. Would you say that the PSR is bringing us forward, both of you? Is it helping or is it still not enough because we're missing this governance piece? It will never be enough.

for one side, but I think we've said enough about the interfaces now. There's a lot more in there. One of the goodies, I think, for the PSPs is the change in the settlement finality directive that is coming to allow direct access to clearing and settlement of PSPs if they want so. Some of them may wish to do that, others will keep doing that indirectly through banks, but at least that functionality is there now. If I may bring something to the table, Ralf.

you worry about APIs, we worry about fraud and liability and discussions ongoing on the concept of what is authorization. Is that an objective thing? You have performed strong customer authentication, i.e. you are liable for the transaction as a payer or is also the intent and that is resulting from these discussions on fraud and reimbursement by banks if somebody has been scammed out of their money.

through social engineering. I did it, that's not the point, but I didn't want to do it, so can I please get my money back? Well, today you can't, at least not if have no legal rights. There could be voluntary reimbursement schemes, we have that, for very specific cases, but one of the dangerous things going on is that the fundamental definition of what is authorization may go into the wrong direction, thereby, let's say,

making all payments uncertain because you never know what the, and at least the bank doesn't know what the payer wanted to do. They can only say, he logged in, used his SCA, did the payment, full stop, and then the terms and conditions, you're liable for that transaction because we never know as payer's bank what the intent of the payer was. So that should be objective and not subjective. That is really.

Michael Salmony 27:50

would have very, very far reaching consequences also for the PISPs because if that uncertainty of intent would be introduced, also the complaint of Ralphie, don't have the certainty it's going to be executed, then the uncertainty would extend until after the execution that you would have to re-emerge the customer when Ralf has paid the merchant. But sorry, but your customer didn't want to make the payment. I mean, that's a horror.

I have no idea how you would ever get to grips with the intent of the customer, right? mean, that's a very abstract concept. It may change after. So that seems a very dark alley in things again. Unfortunately, this line of thinking seems to have some traction in the co-legislative process, which is extremely worrying. So we shouldn't absolutely not go there. That would be devastating potentially to the whole ecosystem.

would get rid of payment certainty because of the intent of the payer. This is for us, that's unthinkable and it would be detrimental to everybody, I would say, and would only lead to more fraud probably. So that's one thing that's worrying us. But to your question, and of course verification of payee will also be mandatory for the, not only for instant payments, but also for the regular SCT, which is good. So I think it's...

To answer your question, apart from the liability perspective, which still out there, it is well intended to improve, course. Otherwise, there was no point in reviewing the PSD2 and making it better in a PSD3. So it will never be good enough for some, but...

legislation is a compromise and the compromise has to be struck somewhere and should be better than the previous time around and PSR will be reviewed in four or five years time and then we will also have the new change management cycle that we will know then by then that PSR also did not do enough for competition innovation etc etc and that some things need to be altered in PSR too.

Michael Salmony 30:07

So I'm sensing that you're more happy than Ralf is with the PSR? Not necessarily, but I still think the real progress is not in the regulation itself. I fully agree with Ralf. It should be smaller, it should be more robust, but then on top of that we need to have industry cooperation to make it really work in more flexible way.

with business models and so on. And that's what we see hopefully on the open finance framework, the structure we have developed there. I think that is more the right, have basic legislation and then data sharing arrangements need to take the shape and share data sharing arrangements on top of the law between market participants. That's the only way to get better results and have it more adaptable to market needs quicker than you can do through legislation.

No, that's, think the theme of this trial or podcast series that we need to work together to make these things work and regulation can only sort of set some of the ground rules at best. And that's why it's good to have things like SPAA. Maybe we'll do an extra episode on that. We already have another episode on fraud, which is another area where we all need to work together to make that work. that's, that's, that's clearly the way to go. But I thank you both for your, for your time. I think we can look forward to another discussion in four years on.

PSR2 and PSD5 or whatever it is by then. This is a never ending cycle as we've seen. So thanks very much for being so lucid and thanks to everybody who's watching this episode and look forward to seeing you again on another one. Many thanks for watching and listening. We hope you enjoyed this episode. Looking forward to seeing you again next time.