SPAA

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

My name is Michael Salmony and I'm joined again by Gijs Boudewijn and Ralf Ohlhausen for another episode of the Trilogue. And this time we want to look at SPAA. I will ask Ralf to explain what that is in a moment, but it's basically an initiative where banks and TPPs have got together to define a new way of of paying. Ralf, can you take us through what SPAA is and what it means and what its goal is?

Okay. A little bit of history, I guess I try to keep it short, but I think it goes back five years or so now when PSD2 came out and at the ECB's Euro Retail Payments Board, ERPB, was discussions and working groups for that and which showed already early signs of difficulties of getting making this work. And the ECB had the idea of what they called a SEPA API access scheme.

and sort of a scheme to complement PSD2, the regulation there to make it really work. And from our TPP's perspective, well, we liked the idea very much because, yeah, we had doubts all along and the early signs were also the same that this is not gonna work for us as it should.

purely based on regulation. So we will need some collaboration with the bank side to make them want doing this and not just have it forced. So a purely stick approach by law forcing banks to do this or that, we did not expect a good outcome. So we wanted to have collaboration. Essentially, exactly what we're trying to do here. So foster the collaboration between the stakeholders and actually try

and not try to base it on regulation or more or stronger or bigger or whatever regulation. So it was all about bigger carrots and not bigger sticks. And yeah, well, it took a while to get together. we had at the early times of implementation, we had really big trouble there with APIs, et cetera. It all went to led to a point where we thought, okay, this can't work.

Michael Salmony 2:33

But then we sat together again, we resumed the group, and eventually we came to a conclusion that, OK, a rough outline on how this should look like. And then what we needed was, OK, well, how to make it a reality. We need a scheme manager. It would all have to now turned into a real scheme with a rule book and everything. So this is how it was then discussed and decided to ask the EPC to play that role.

as they play for all other most other schemes, all other SEPA schemes here in Europe. so, but given the focus of the EPC on payments, it was then renamed to SEPA Payment Account Access Scheme, SPAA Scheme, SPAA Scheme. And yeah, and so for the last, was it, I don't know, two years or so, we have worked there then under the, within the governance of the EPC to create a...

rulebook for that, which was then launched. well, I think I'll leave the dates to Gijs. He's now the co-chair of this even. He must know better. That's a matter of perspective, of course, who knows better. Yes, a lot of images came up when I was listening to you, Ralf. We used to call each other of each other's favorite enemy.

at the time coming from both sides. But through friction, good things appear. So we had absolutely vigorous discussions and absolutely disagreed on everything initially, but eventually after a lot of discussion, it dawned that cooperation was better than fighting each other. And I think for also from the ASPSP side, the acceptance and we've talked about it in other

in other episodes, a business model, a sustainable business model also is vital for something that you would agree on between private parties on top of what the law mandates. We lost a lot of time, indeed as Ralf said, we wanted to reap the full benefits of PSD2. I think that's how the report starts to reap the full benefits of PSD2. It was well intended, but the regulation doesn't exactly prescribe how you do it. It says,

Michael Salmony 4:57

what you need to do, but not how. And that leads to fragmentation, good and less good implementation. And that's how it all started. So we all agreed after these discussions to reap the full benefits we need to cooperate and to harmonize to get more predictable and better interfaces, better APIs. The word API, by the way, is not part of PSD2. That's dedicated interface, but normal people like us call it APIs. But a good and sustainable business model, i.e.

some form of compensation was also vital. So these two components led indeed to the conclusion that we needed. If it works like a scheme, quacks like a scheme, it should be a scheme, which in the scheme needs an owner, home, and that was found at EPC. For the EPC, the...

This was a first time in the sense that there was a formal request from the European Retail Payments Board to the European Payments Council, are you willing to accept our mandate to develop the scheme? And after some consideration, the board of EPC said yes. And what was new here and which was pretty complex was indeed that business model. I mean, the principles, there needs to be a fair distribution of risk and value was the mantra, but what value exactly and based on what?

So the most difficult thing was not so much the functionalities because we had already agreed in the ERPB discussions what the APIs, what functionalities should be exposed on top of what PSD2 mandated, what we call the PSD2 baseline, which is not a really legal notion but because we agreed to accept this is what we believe is the PSD2 baseline, this is what banks have to provide for free, mandatory, or else...

we call premium functionalities and that is what we agreed based on market demand. We interviewed the retailers. What would you like to see? So the end customers of the TPPs, what sort of functionalities would they like to have? So that was already in the report. That was pretty much the easy part. Which functionalities should that scheme offer on top of what PSD2 baseline was according to us? And then the most difficult one was the cost calculation exercise.

Michael Salmony 7:17

because this was, let's say, a greenfield operation, there was no example what was the methodology to be used to do the cost calculation and well, et et So we hired an EPC, hired an outside economic consultant who devised a cost calculation methodology, which of course has to be endorsed first, which we did in the SPAA multi-stakeholder group. So I'm co-chair, but the group is co-chaired by another co-chair, of course, which is Arturo.

and Arturo represents the TPPs, I represents the asset holders. In our terminology, we call ourselves asset holders, the account servicing institutions and the asset brokers. That's the TPPs to create this European open banking ecosystem. But eventually we succeeded in first having developed the methodology, endorsed it. And why is that important? If you don't endorse the methodology first, before you know the results, you will say that results

you don't like the results, will say the methodology was wrong. So first you say we accept the outcome of this methodology. Okay, step one, step two was then to start collecting cost data, which was a pretty difficult exercise for the economic consultant, but it may not be ideal, but we did agree on a first set of default fees. They are publicly available on the website of EPC. The rule book is published. So anyone can see how the business model works.

what's in it for everybody. And indeed, we published the first rule book last November, the default fees were published, and now we are in a phase, by the way, with a lot of support from the European Central Bank and the European Commission, who are observers in our multi-stakeholder group. And it really stresses the importance of this multi-stakeholder co-creation to create, because let's say we have the European Payments Initiative as a more

club solution to have a European payment solution. This is more the open banking way of trying to get European open banking based solutions, pan-European with potentially full reach. Also in, if you will, for the sovereignty of Europe. Not easy. So it sounds as though it was a difficult journey. took a long time and there were quite a few, few battles.

Michael Salmony 9:38

There were some quite complex calculations that needed to be done, but in the end, it's an amazing result. mean, it is two different fractions who had very different starting points, right? There were the TPPs who said they want good quality APIs at the regulatory mandates and the banks who weren't so keen on opening up and providing good APIs. But you found together and found a model also with a business model, not just technically, but actually a commercial model.

that makes it work. So that will allow TPPs to use, to initiate payments using APIs, to look at data using APIs. And I think that's an extraordinary achievement, which again, I think is first in Europe. Open banking is happening all over the world. I'm not aware that anywhere else has a scheme being developed, multi-industry across the various combatting participants who have agreed on something. So congratulations on that. But Ralf, don't think it's working too well. Can you sort of say where we are on this?

Yeah, well, let me just a few comments there. So far, agreeing the concept and agreeing the functionalities and all of that wasn't that difficult because of course banks, you know, actually, and for me, seeing the other side of Gijs sort of the non Jekyll, more the Hyde side, or was it the other way around? I don't know of him because we were in other discussions like the API evaluation group, which was just a regulatory based. And there, that's where the real dogfights happened.

here in SPAA, well, we had, okay, we agreed on what is it that we really want? What is it that would work? And of course, crunch time came when then what's the price of it? So that was the real big thing he already described how we came to some solution on that, which of course, the banks find too low, we find too high. But what we have to, what we have the fees that were agreed.

But what we have to now do is seeing what is the reality of it. So what can we really achieve? And unfortunately, now we have, since it launched officially in the last year, we have a number of asset brokers, TPPs, who became members in the scheme, but we're still waiting for the first bank.

Michael Salmony 11:56

participate. And we had earlier this year, then discuss, okay, how can we do how what what what is necessary a pilot? How what can we how can we get it off the ground? So we agreed a initial tactical pilot followed by a more strategic pilot. So we actually two phases even to that where the initial one is where banks have don't have to do any investment, no minimal requirement, not going to the MVP, the minimum viable product, which otherwise we have defined for getting some common functionality. So here for the pilot,

there's basically no commitment, nothing needed, making it very, very easy. So we may, we really bend over backwards now to get banks participating in this and getting things started. But it is not. So guys, over to you. You co-created this. Why are no banks joining? Yes, that is a bit of a difficult question to me, of course. So I think mainly

and not to say banks, you should feel sorry for banks. The problem mainly is it is not a burning platform. It is a long-term strategic thing. And if you're a bank, say, okay, I'm compliant with PSD2 right now and we will have the PSR probably next year, compliance, okay, I have so much on my mind, so much compliance stuff to do.

I may also be part of the European Payments Initiative or if I'm a Spanish or Italian or Portuguese bank, I'm part of the, let's say the Southern Bloc or we also have what I call an Eastern Bloc around the Polish BLIK solution that's being spreading in the east of Europe. So it is extremely difficult since it is a very light touch thingy. It's just upgrading your PSD2, leveraging PSD2 investments.

It's not you will not get rich from a bank's perspective, but we say, well, you have to be compliant with the law anyway for 50%. So why not build another 50 or use that to have another 50 % functionality where you will get some remuneration. But it's extremely difficult to get it the C-level attention. And I think we also acknowledge that in our communication, we were starting a little communications workbook. We're trying to

Michael Salmony 14:24

evangelize as much as we can. But there is no, there's too little visibility, I believe, on the C-level. There's no boardroom commitment yet that people sit at C-level, the asset holder. Well, if it's a very low regret investment, I would say why not join SPAA? We have to be compliant anyway. Why not try to make the world a better place?

It's probably minimal investment. We're trying to show that we made a report what the deltas are between the PSD2 compliance APIs. What would you need to do to become SPAA compliant? What will you probably need to do because that's another of those factors to become PSR compliant payment service regulation probably next year because there is a certain uncertainty if PSR will create a bigger baseline and it could be in theory that some

premium functionality will become baseline functionalities. And last, a point of uncertainty I understood from the more technical people, we need to build these APIs based on specifications. Europe, apart from the French community, mainly builds the banks, build their specs. Their APIs based on the Berlin Group specifications. They have now published the Open Finance Framework specs. That's another dimension we may want to touch upon.

the more future oriented part of what you've done. So what I understand is that some banks, need to migrate, let's say, to the open finance framework of the Berlin Group to be fully SPAA compliant. So banks that are now PSD2 compliant on, let's say, on version one of the Berlin Group inspection will need and that for PSR that will be necessary anyway, we'll need to change to the version two, the open finance framework of the Berlin Group. And some say this is on our backlog, but not this year.

we will do that when PSR is there. We will need to do it anyway. So we will wait. So it's a diverse diversity, a multitude of arguments why I believe they're all, nobody's negative, everybody's positive. It's a matter of priority and lack of boardroom commitment that you might even give it a bit more push because of the geopolitical importance of it. It's a small thing, but it's very important.

Michael Salmony 16:51

for European open bank payment solutions. No, no, well, it's understandable. I there are so many things going on. It's hard to know where the priorities are, but it's such a shame if this brilliant scheme, which was agreed across multi-parties and has got commercial basis, is then not used. The TPPs are actually endorsing it. That's why we try to do everything to get it up and running. And it will be, but it's You have a few other things on your plate too.

I mean, there's another question in this context because we only have a short short episode here. Is there a there are also some other competing things happening? It's not only EPI and for example, giroAPI, right? This is another initiative which is sounds very similar, right? It's doing a scheme with APIs to do open banking and it goes beyond payments. It does a lot more because the EPC is only doing SPAA.

focused on payments. Maybe Ralf, you can comment on that. How does giroAPI fit in with that? Is that a competition or compliment or how do you see that? Yeah, well, when I first heard of it a couple of years ago, I thought, no, not again. So we're doing something European thing. are maybe boiling the ocean, but we get something that works everywhere. And now what we don't want is some national competition,

different solution and which sort of the whole thing falls apart again. So I was very critical skeptical initially, but now it's a bit different. It's also maybe with a bit of luck that it is the giroAPI is entirely based on the Berlin Group standard. And at SPAA, we have created something which can be independent of the standard, which is above the API standard, which can be fulfilled by different

API standard like the UK standard or a French STET standard or whatever other standards they call, they could all provide the functionality. So we're independent of the actual standard, but a Berlin group API currently being the only one which has developed all these extended premium services, which actually can deliver the functionality of SPAA. So all the other standards, STET and UK.

Michael Salmony 19:10

et cetera, they are not having sufficient functionality. So it's only at the moment the Berlin Group standard that can fulfill that SPAA functionality. And so what we have focused on here in the last year or so is to try to make sure that it is actually completely harmonized in a sense that if you're a German bank implementing giroAPI, you have done the work already.

for SPAA. So it's the same ready where the functionality overlaps. It's the same implementation. There's no nothing to be done extra. So technically the same now, I think where we may face a problem is with different commercial models. So whilst the, Gijs explained, we have a cost-based model here. Their giroAPI seems to go a different way. So that's maybe where I'm not sure whether a German bank would then

Well, we could easily do both. Technically. Yes, they could. But from the commercial side, there might be differences, but of course it's all solvable. So at the moment and sorry, I should mention that the giroAPI is a initiative by the banks, the German banks. It's not a 50 50 thing between banks and TPPs in Germany. It's by the banks. So hopefully all the banks will actually then they'll be the first one there to, to, to join and run it and make it happen. And with that.

And if the banks can then kill both birds with one stone, hopefully they will also join SPAA, seeing all what we can do to outside Germany in the same way. wonderful. I think it's to wind down. I'm afraid we don't have much time. I'm a big fan of both of these initiatives. Quite honestly, SPAA and giroAPI, I think they're both going in the right direction to bring this API topic to life. And we will see convergence, Michael. We have, of course, discussions with giroAPI.

to ensure that we stay aligned and at some point in time both will converge. That's my hope. giroAPI is looking broader, right? It's not only doing payments, so maybe SPAA will be the payment bits that slots into giroAPI.

Michael Salmony 21:15

It'll also all come together when we start doing open finance, which is a sort of broader topic. So I think it'll all come together in the end. At the moment, it's maybe a little bit of a rocky road, but I think it's fantastic that not one, but at least two initiatives are happening to make this API world happen. One minute because I want one other misunderstanding, making, with just one minute. The other, European Payments Initiative, as it is, and SPAA.

Just to stress some believe that they would be mutual exclusive if you do the EPI not API but EPI European payments initiative You're not in SPAA, which is not true If you even if you run a bank in the EPI consortium, you still have to comply with a law You still need to do open banking. So I would say SPAA is complementary to EPI. You can do both or one or the other or neither I mean that neither is mandatory but

They are not mutually exclusive, they are complementary. Okay, that's an interesting idea. I hadn't heard that one before. I mean, we certainly heard from EMPSA that they want to also support EPI. So all these people are sort of coming together and supporting each other because we all want to have a pan-European efficient, modern way of doing it. I personally think an API approach is good. And EPI would have been a good way of basing their pan-European thing on using APIs, but they didn't. We discussed that in another episode.

but it's all sort of coming together eventually. So I'm very, confident. I will make a second attempt to close this session and thank you, Gijs and Ralf, for your very lively contributions and hope you, all you who've been listening to this episode, enjoyed that and please check out our other episodes and see you next time. Many thanks for watching and listening. We hope you enjoyed this episode.

Looking forward to seeing you again next time.