GIROAPI

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 we welcome our guest Jens Holeczek who works at the German cooperative organization and runs two enormous projects. One is the digital euro, which we've talked about a lot in this series. So probably not so much about that, but he also does the giroAPI.

And then we'd really like to explore what that is about. So Jens, maybe you could just quickly introduce yourself and maybe also say a few sentences what giroAPI is.

Jens Holeczek 0:45

Yes, thank you very much also for the opportunity to be here and to be in this trilogue. So my name is as you said, Jens Holeczek. I'm working for the German Association of Cooperative Banks, but not only for that. I'm also the project leader since five years for the giroAPI project of the German Banking Industry Committee. What cares about an API scheme, not only for payment, also beyond payment. So we have also some financial information. Maybe we'll come some later to that.

And in this position I'm proud to be here and part of your dialogue.

Michael Salmony 1:20

Thank you very much. So giroAPI, sounds a bit like SPAA. It's sort of an API based scheme on top of bank accounts. Can you help us differentiate that?

Jens Holeczek 1:32

It's very interesting to differentiate or not to differentiate because there was a time coming from the ERPB API work where the German community started and nearly the same time, I believe some later also, was the EPC started with SPAA. And we had at the same time two different visions and started the work. So we are just in a situation that is...

bars going in the payments direction, very concrete on different use cases, while giroAPI has a broad scope and also started at the same time. And I don't like to see them differentiated as a competitor to each other. I see just two initiatives with a different scope and hopefully in the payment sphere they would come together in the future, but that's a part of evolution and not of a revolution. So I don't see a competition overall. I just see...

two situations started and I believe we can learn from each other and then joining evolutional, the payment stuff while giroAPI has a broader scope.

Michael Salmony 2:33

Okay, so.

Ralf Ohlhausen 2:34

Yeah,

could we could actually just ask on that already? Because yes, I understand. We have and I guess you're a little bit in the lion's den here because with Gijs, the co chair of SPAA and I've been there from the start as well since whatever, five, six years or so. But we'll come back to the competitive element or what in a bit later. But

Maybe one of the big questions there then is, where do you see it going beyond what SPAA is doing?

Jens Holeczek 3:10

Yes, as as I see it related to the payment stuff, the payment initiation with additional values like reservation of funds and also some additional stuff. While we also have a giroAPI at first, financial information for other account types like saving accounts, like loan accounts, like card accounts. They're also a part of SPAA, cards and payment also, and I know.

But we're also looking, for example, on a FIDA compliance to have in future additional information on savings accounts and loan accounts, and maybe also going beyond the direct account stuff by banks. So we are open because we have a sub-scheme approach, making us very flexible to extend the scheme, also API-based RTP parts or also other parts with different sub-schemes. And that's what the scope of giroAPI is in the vision.

beyond what the SPAA is doing. But I see the conflict is in the feeling that people have around the world because we started because it's the easiest one with payment. There is the most knowledge about APIs. So of course, we started with payments. SPAA's payments only at the moment. I don't believe it will change also in the future. I don't know. And by that, everybody's thinking that are two initiatives in competition. I see it more they are both on the same time.

And we don't want to stop giroAPI versus SPAA because we have a broader scope. But also we are very interested in what's happening in SPAA. And I believe there are some differences in detail. But hopefully we can bring them together for the future because we can learn.

Michael Salmony 4:51

So guys, do you want to say a little bit? You are the other line in the thing.

Gijs Boudewijn 4:52

Yeah, I think

I can mostly concur with what Jens said, of course. Indeed, the starting point is a bit different. To be honest, the ERPB exclusively asked the EPC to make a scheme for payments and the Germans chose to do something, its their own initiative, not on request of the ERPB. And the sub-scheme approach, Ralf will know it, is in the ERPB report. This is the holistic model we drew already.

in the ERPB report of 2019, we envisaged a sort of umbrella scheme with sub-schemes, where we said that the payments is the first sub-scheme, because that is what EPC can do. And we can imagine, and we hopefully will see that in future others, that was from the Euro Retail Payments Board, the remit is only payments, that others in other domains, like mortgage, loans, insurance, whatever, they would take the model, the scheme with sub-scheme model and

make it broader than payments alone. Now, you know, it's the Euro Retail Payments Board asking the European Payments Council, so you have to stick to payments. And indeed, was a discussion about a year ago within the EPC, should EPC also broaden the scope of SPAA more to the tune of what giroAPI is doing, more to accommodate also other financial services, and then it was decided, well, we are the payments council.

We are not the mortgage council, insurance council, what not. We do not have that expertise. You need other ecosystems to take the overall holistic approach and see if you can make that work in finance, in other domains, the payments. and I do believe, Jens, that unless we change, let's say, fundamentally, more fundamentally, the whole governance of EPC, EPC's focus will be on payments and perhaps a little bit payments related, but it will not build.

At least I don't foresee that. An insurance sub-scheme, for instance. ⁓ So, and I would hope indeed, and we are discussing that because representatives of giroAPI are also in the SPAA Multi-Stakeholder Group, that at least at the payments part we can converge. One of the ways to do that is of course to use the same ⁓ basic ⁓ API specification model from the Berlin Group. That's what's a good thing.

and we will have future conversations on how to sort of further align, at least do, or avoid taking steps that would hinder further convergence for the payments part. Because again, from an EPC perspective, for now the remit and the mandate is only and exclusively payments and maybe a bit savings accounts depending on PSD2 legislation locally implemented. But that is the fundamental difference. think that general API is...

broader than payments and SPAA has to restrict itself to payments. But in that column I would hope we would see more convergence.

Jens Holeczek 7:56

And at the end, to add that as long as implementations, we are both looking for Berlin Group, and as long as implementations are the same for the brokers and for the holders, as long as efficiency will be there for the market, and then at the end it's equal how many schemes it will be, ⁓ as long as the functionalities are the same.

Michael Salmony 8:16

Would a very naive structure be sort of giroAPI is sort of like the FIDA? It does all the payments and insurance and mortgage and everything, but it doesn't do the payment leg or not exclusive that the sort of payment leg would sit under giroAPI. That may not be what SPAA wants to hear, but it seems to me as sort of how these bits could fit together or is that not likely?

Jens Holeczek 8:42

So if you ask me, it's at the end a part of the market request. And as long as you want to have, ⁓ for example, with one user experience, savings accounts, loan accounts, and also some payment stuff in one flow, you need to have also the technical level, this combined, and then it would be difficult to have not the same technology under the same contract with the same content of the same user.

that make it a little bit difficult just to say you have one scheme under the other and mix it with the other stuff. Otherwise, you will need at least, let me call it a meta frame, what covers then this consensus could be over given to the other scheme. And that's a little bit like the sub-scheme approach, but then you're coming to governance discussions, to dispute handling discussions, you're coming to so many discussions and it's overall, and that was one of the reasons why we have been slower in the progress with giroAPI.

for some time, it's at the end very complex to have a multi-scheme approach to have this compatibility between different sub-schemes, while having the option to have different governance per sub-screen and the same common based technology. So that's very, very complicated in creating it in such a clear way that it can work. And now we're at a place from January that we now can, let's say,

show the market, show the regulation that it could work but it had been hard work until yet and it needs to be proved now that it works and maybe we still need some changes because no scheme is perfect from the beginning, of course.

Michael Salmony 10:22

How do the two lines feel about that?

Ralf Ohlhausen 10:22

Yeah, could I?

Gijs Boudewijn 10:22

I think also, sorry,

Ralf Ohlhausen 10:24

I could could I just say.

Gijs Boudewijn 10:25

think also, sorry, Ralf, that...

I may be wrong because I am not an expert in the other domains, but one of the advantages we in payments have is it's far more standardized than many of the other. Open transactions, oh we can do payments, oh then we can do insurance, oh then, but that all supposes that the infrastructures are harmonized, that they use the same standards, etc. etc. And of course that is not the case. It is too easy to believe that you could just replicate.

It's only insurance but it's same messaging, it's fully standard, but it's not.

Jens Holeczek 11:04

The more you have ⁓ actors like brokers and holders who are near to the payment stuff, because if you're a bank and you have a account and you have also loan accounts and you know the payments world, then you can extend very easily. But if you are an only loan ⁓ accounting bank, we have for Immobilia, we call it in Germany, so houses and whatever, and you have only this business, then you never had...

payments and then it's a fully new world to have this and that make FIDA so complicated why I personally believe this time frame with a short time is is unserious because there are too many actors need to understand from scratch what it does What does it mean to have consents by the user user flows information per API? So for some of the actors, it's fully new what but at least banks have

Payment accounts are no and can extend to the other kind of account types, but insurance is a full new world for everybody, believe.

Michael Salmony 12:10

So I think we understand what giroAPI is. Maybe you could give us an update on where it stands. Is the rulebook finished? Have you got a business model? When are you going to be rolling out, etc.?

Jens Holeczek 12:22

So let me say we have from January started the rule book is published on the website under giroapi.com or giroapi.de for the German version. contract language is German, but it's also for convenience in English translation for everything and at least the technical documents like the Berlin Group documents who are part also of our scheme, mandatory part of the scheme are in English of course.

We have published at 4th of April the version 1.0.1 with some minor bug fixes. So there were some things not clarified enough. There was just some words missing, these two questions. So some minor points. And we have at the moment, believe, within the next two weeks, a second date where you can join the scheme. So we have four dates for this year. And at the moment we have

about 200 banks joined. The first step mostly from the cooperative sector, so they need to proactively say they want to join. We have some other asset holders in the implementation phase because we have ⁓ some mandatory services from the beginning. So you can just join if you have them ready in your implementation. So others will follow and they just missed for a few days a second date.

So some more banks will follow. I don't know how many at the moment because it's not our association's part when they will join. We have the first asset brokers wants to join. I believe the first also sent the first documents and they are now in check if it's fulfilled. So maybe they will have the second date now. So we are at the starting point. We have sandboxes ready for the services, for all services of the scheme.

We have a directory up and running, so where you can also look who is part of the scheme. Of course, it's not tested in practice because as a broker, we'll see if he can really get all asset holders. We tested it in theory, but the difference between theory and practice is always a little bit bigger in practice as in theory. And so we have an operator for the scheme who's doing the office stuff. Let me call it like that.

And we now have in the near future with the Commission of the advisors, the next meeting where we talk about the next version 1.1, where we also believe multiple recurring payments could be a next service and want to ask for the next priorities because it's very important for us. We want to work together with asset brokers, with clear governance structures, of course, a little bit like it's also in the Berlin Group as an advisor model.

and we built this scheme for the market to join forces against a lot of European big techs and whatever we need to join. And that's the vision we have behind. So we are very open to also receive comments and additional requests for the next steps.

Michael Salmony 15:34

That's very impressive. Just for those listening who may not be familiar with the terms, I believe asset holders are basically banks and asset brokers are the users of the data, right? Can you say a little bit about the commercial model? Because I think it's a bit different to the one in SPAA. Can you explain why it's different? yeah, just tell us a bit about that.

Jens Holeczek 15:45

Exactly, exactly.

The

commercial model is always a little bit difficult to talk about because of the competition law. So overall we have one part that are the scheme costs. The scheme costs are just shared between all the participants with a fair model. just by members and there are for the not in the governance participants there are cut it off at a maximum. So if it's more costly than the...

Associations will take the part and the banks from the SA are covered by the associations. But at the moment we see we try to the cost as down as possible and the maximum in member fees for the scheme. It's just cost base is not with making every margin or profit. So the scheme itself is just cost base, non-profit. That's what we do. We have a budget calculation every year and every year.

Depending on the request, will discuss with the advisors. We will have then a new amount lower than the maximum amount that is good calculatable for the market. That's the scheme costs. On the other side, the services. For the services, there is a model, let me say, of articles which are assisted by the scheme also for a very easy invoicing because known.

of the asset brokers wants to have 600 invoices by cooperative banks and 300 for savings banks and whatever. So we have, ⁓ let me say, standards also for transmitting invoice information and articles, names, and what are assisted by the schemes. And you can have bilateral contracts between holders and brokers for everything, everything what you want, as long as you keep in this structure what's the standardized.

We have lot of also articles standardized with a zero price. But if you want to have a fully different model, you can just put a price on it like we have ultra flat fee. So it's with zero in the fallback fee. But if you have a bilateral agreement saying, OK, me as a broker with this asset holder, I want to have a flat fee per month, then you can agree on that. And then it's also assisted that you have the invoicing assisted by the scheme.

But you don't need to do it because it would be a burden at the beginning to have those bilateral discussions. You don't know which asset holder you will use as much or which asset broker will come with how many traffic. So we have a kind of fallback fee. So if there's no bilateral contract, then you will fall back on this fee. So you can just start, can look as an asset broker, what is used by your consumers, by your customers, the same as the customers of the banks.

And then you can go to the other side and say, okay, if I still use this additional services and don't do it in another way, like reservation of funds, you have different ways to do the service, but it's the easiest to do it together with an API. Then you can go there and can say, okay, I will only use it for this price as an example. And then you have a bilateral contract, it's assisted by the scheme, but it's a different price as a fullback remuneration.

Michael Salmony 19:10

And you need to do the bilateral contract for several competition reasons because you can't agree on a single price for everybody that wouldn't go down well, I think,

Jens Holeczek 19:18

That's

a big issue, so it's just a fallback remuneration. And if you join forces via an association or whatever and you want to do these contracts together, there are no structures yet because that's part of the associations to have these structures. Of course, that would be an additional option that you say, want to have something like we three TPPs want to have bilateral contract with those 10 banks, for example, and then you pool them. That's also

It would be assisted by the scheme. So you have very flexible for bilateral contracts and the structures assist that. That was important also from competition reasons, but it's not a requirement to start.

Michael Salmony 20:03

But Ralf and Gijs, maybe you could comment because I think you had a different.

Gijs Boudewijn 20:06

Yeah,

one fundamental difference in the fees. So it's never easy, of course, to create a scheme with a business model inside of it, which satisfies both sides, of course, that has to be in equilibrium. ⁓ So the SPAA scheme works in general terms the same as a giroAPI. It has published, so it is fully transparent, it's open.

public knowledge, it works with default fees, is amounts of the same thing as the fallback fees. The difference being that in the SPAA scheme, the default fees have been calculated with a agreed cost calculation methodology. And as far as we know, the published, because they are published, ⁓ fallback fees in the giroAPI schemes are more ⁓ percentage based and not fixed. So the

to the calculation basis of the default fees on the one hand and the fallback fees on the other hand. It's the same, but the structure of the default versus the fallback fees is different. One is fixed fees for SPAA and percentages for the giroAPI. But of course you can agree on a fixed fee as Jens explained.

Jens Holeczek 21:24

It depends on the service to add that. We have some services, have also percentage fees because we see the cost also raises with the amounts, while other services adjust fixed fees because it's equal to how big their amount is. So then you don't have a percentage fee because the work is the same.

Gijs Boudewijn 21:25

Yeah.

Right. If there is no risk, then it's a...

Yeah.

Michael Salmony 21:42

Okay, we spent quite some time on fees, but I think it is important because if these schemes don't have a mechanism where everybody's happy and they get some incentive out of that, the whole thing doesn't work.

Ralf Ohlhausen 21:51

Yeah, well, and if I could come in, because I think it

is indeed the problem. well, when I first heard of giroAPI, or so we were already like three, four years down the road with SPAA and I thought, come on. For the first time, we actually have a European initiative first and and then and we don't have to harmonize 27 countries because we're going central first and then

Germany comes up with giroAPI. So I thought, no, but I have changed my mind in the meantime. And of course, one of the reasons is that, well, you have all the banks and maybe a couple of TPPs. We have sort of all the TPPs, but no bank. So it would be really nice to sort of match and marry or whatever. Here are our activities and we have done

For the last year and a half, I think, or ever since we were looking at both giroAPI and SPAA, we have tried very hard to get things technically compatible. So to have, well, because both are really Berlin Group based, SPAA initially was agnostic to a standard, but no other standard has sort of lived up to the challenge.

of providing all these functionalities. So it is also and it was only the Berlin Group standard now who has applied for being the basis for it. So we are will both work on the same standard. And we're to of course, do that or the implementation guidelines or instructions in a way that any participant, like all the banks now participating in giroAPI could do SPAA without any further technical investment.

basically using the same basis and the same type of implementation for the overlapping functionality. I appreciate that there is not everything overlapping, but for where it overlaps it would be the same thing because that's how I was hoping that, okay then...

in Germany, all the banks are there. And I guess it's also worthwhile making clear that it is a bank driven it is the the banking associations who are running the scheme. It's not like a 50/50 thing like SPAA, which also was another reason for having hesitations, of course. But I'll come back to that. But ⁓ anyway, so it has led to to the situation where the banks it's their baby. And so they are also

doing it, which is great. So therefore, I see or I thought, okay, well, this could give the right momentum to SPAA here, by having all the German banks who are part of giroAPI, they will do then SPAA in addition for the international parts. now the big but I wonder if the commercial arrangement differences could now get in the way of that. Do you think?

Jens Holeczek 24:55

That's a very

interesting part that you raised. So first let me say one point that's important for me also personally. I'm still looking forward to SPAA and ⁓ what I said earlier, that we don't see us as a competitor. We just had the same time in some parts a different approach, but we also had it somewhere easier because...

If you're coming from a country, associations with a country, you have a more harmonized market that makes a lot of discussions much easier, some others more difficult. But some, at least as a technical standards, are much easier. So that is one of the reasons we all had Berlin Group in Germany. That's not all over Europe. So you have some discussions, not what you had. Ralf, you highlighted that you were API agnostic on the standards at the beginning. Now you're looking also on this.

We had, for example, an appendix where we directly worked on harmonization of the Berlin Group specification in the usage, make it very easy because we think deleting dialects is also something that has known value. But for that, you need to go very, very deep in this translation between the business rules and the Berlin Group specifications where very flexible, but somehow optional, conditional and whatever. And we try to fix as much as possible.

be as clear as possible. But we had an easier challenge because we are just coming from more harmonized situations. ⁓ what's at the end important is that the same implementation can be used. And the second part I want to highlight on this this prices discussion. That's something where I believe we need to join forces also about competition offers, about the regulator and everybody.

At the end, the scheme can always only work if we have the maximum of asset holders have an interest because they can give some value to the market and to earn some money for the investment. And you have on the other side as much as a broker, they say, I see the value is worth this price. So at the end, also a scheme with this default or fallback fee is a kind, it's damned to find the right

price balance because otherwise you will have only brokers and no holders or otherwise have only holders and no brokers. And to have this optimal price is something of a market mechanism and maybe the fallback fees we have in giroAPI if we see too many people try to have, no it's a wrong wording, if too many asset brokers say the price is too high we need to have bilateral contracts and maybe the fallback remuneration.

is too high and we need maybe to change. That would be a big change. It would be a lot of work because every participant needs to resign the contract in this case. But we have this option to find the right market price for all participants and we are damned to do it. Otherwise, no scheme will fly.

Gijs Boudewijn 27:55

That's precisely by the way what we did, Jens. Finding the optimal price from the brokers and the holders perspective that was all part of the cost calculation exercise we did for SPAA. That's why we ended up with the fees, both sides being equally unhappy or happy, if you will. The point is we don't know if it's the right fees because we need volumes first to see if we can attract. you won't. same. And at some point in time, hopefully,

Jens Holeczek 28:20

We're the same!

Gijs Boudewijn 28:24

rather sooner than later, we will have to recalibrate the fees because if we are successful, the prices will go down and you will have to recalibrate. It's simple as that. But it's a chicken and egg thing.

Michael Salmony 28:34

Yeah.

Ralf Ohlhausen 28:34

Yeah, the good news is,

the good news is we have two agreements independently of each other. And I think we're with that we are a bit the envy of the rest of the world. Because no one else has that I think the UK is has been trying for a while and is continue to try finding a model there. And I'm also not aware of anywhere else in the world where open banking like an, like a premium open banking or whatever you want to

Gijs Boudewijn 28:48

There's not an agreement,

Ralf Ohlhausen 29:00

classified has ⁓ managed to agree like a business model for it. I think but but that is, of course, absolutely required for for making premium open banking work somehow.

Michael Salmony 29:07

Yeah, a good point.

Jens Holeczek 29:18

At the end, if for the customer it should have added value and should make life of us all some easier, we just need to have all fun with the business for our common customers. That must be rule. And as long as one side is too unhappy, I'm not saying everybody needs to be happy, but as long as one side is too unhappy, it will not work.

Michael Salmony 29:39

And at the moment we have this interesting situation where SPAA has lots of TPPs but not many banks and giroAPI has it the other way around, right? Lots of banks but not many TPPs. So let's hope this does indeed come together.

Gijs Boudewijn 29:54

If I may, Michael, one very interesting thing I think Jens said, which Ralf knows we've also been discussing recently in the SPAA Multistakeholder Group is now that it has become more clear and yes, there is still a Polish API and yes, there's also still the French STET. But apart from that, there seems to be sort of consensus that the future is, pan-European future is based on the Berlin Group specs. And what you said that you...

have influenced the functionality mapped on, if I'm not non-technical, on the Berlin Group specs is one thing we said, well, now it's clear that Berlin Group will be the way forward. Maybe we can sort of sanitize our rule book and make it simpler by really tuning it into the Berlin Group specs. And maybe the exercise you've been doing, if I understood correctly, could be very helpful for us to do that exercise, to sort of clean up the rule book.

from everything that we don't need if you choose only for the Berlin Group specs and not from an agnostic perspective.

Jens Holeczek 31:00

I believe that's one part what's needed in SPAA. Another part is we try to be in giroAPI with the use cases as much, not with the use cases, but with the services, edge must use case agnostic as possible. So if you have, for example, reservation of funds, in giroAPI, it's equal if you use it for a petrol station, getting electricity or in e-commerce pay by delivery.

So it's just the same service because the rest could be done on the asset broker side, makes implementation much cheaper as if you make three services just as an example. It's illustrative only, but if you make three different services to pay e-commerce, pay by delivery and petrol stations with an authorization in beginning and the concrete amount some later, and if you make three services, you have three implementations.

raising the cost could be done cheaper on the broker side. So what we tried in giroAPI, and that's maybe also part why we have a different governance and choosing for a different governance in the past, that we try to understand what the mark need and we try to search for the cheapest way to fulfill this with the most agnostic service for cheapest implementation. And that's also part of the difference because that's also something I see in FIDA if you have.

People don't know the implementations on the banking side, they have a wish. The wish is, okay, we want to know it. But if they talk to you how you need to fulfill it, it may be much expensive as if you have the choice how to fulfill this wish. And that's something if the governance talking about the implementation and the users are talking about implementation on the other side, that's always garbage because it would be the same as if I talk to the broker and say how they need to implement

the user story in the interfaces that would not work. They know their business, I know my business. They need to say that are my requirements and the whole decide need to make it as cheap as possible that the price is okay for everybody. That's also one of the difference between governance and how the services are framed at the moment.

Gijs Boudewijn 33:08

I'm looking at Ralf here because I'm personally not so sure if we have such a different approach here. Indeed, SPAA started with asking the market, what is it you want? What are the use cases you want to be covered by the API services? But we are not implementing functionality, what we call the function, but they are API services. They need, the brokers need to fulfill their use cases. We are not doing so. I think it's a bit of a semantic misunderstanding here and not so much.

fundamental different approach, but maybe I understood it wrong, Ralf.

Ralf Ohlhausen 33:41

No, no, I think you're right. is. Well, I can understand where Jens is coming from, but it is indeed the case that it is also, I think at the end of the day, what counts also for SPAA within SPAA is not a specific use case. is functionality. So API functionality that will allow then

a myriad of hopefully use cases and it's only the brokers decision than what to do what to make out of it and not and not because we don't want to be that limited either. We don't want to be limited to like five use cases in SPAA we the out of the functionalities you will be able to make 50. And one other thing I wanted to come back to though was the the governance because as already highlighted earlier, so this is a bank driven bank owned

Gijs Boudewijn 34:14

Exactly.

Ralf Ohlhausen 34:37

bank governed scheme. It's not a 50-50 like SPAA, which made me very skeptical initially, but actually was similar for the Berlin Group governance ⁓ before, well, at the time when I sort of joined in there from ⁓ a demand side perspective to the advisory board. And I think you mentioned you're following a similar arrangement.

there with advisory boards. the TPPs or the brokers have an advisory role, but not so they have an advisory board, but not on the real board. And now that of course, is a is a bit of a different thing between advisory board and a real board. But I should say that with hindsight now, I don't know a few years before already with Berlin Group governments, like, I can confirm that ⁓

When it's when we are not talking compliance, when we're talking premium services, when we're talking about some commercial arrangement, when we are trying to find win-wins, then all the trouble that we had in the past with open banking back and forth and where especially Gijs and I spent years in battling fiercely is really dogfights.

None of that has happened really in SPAA and I guess also not in in giroAPI because this is it is there is so much common ground and will for cooperation and finding a win-win that this is really so much better than just trying to to create competitive services based on sticks on compliance only on forcing banks into something that they don't like.

Jens Holeczek 36:30

So at the end it's always the same, equal to the governance structure. our interest also from the banking side is to have something that is used. And it would be a very bad choice not to listen on what the market needs.

Michael Salmony 36:46

That's fair. I think our time is gradually coming to an end, but one question I do have to ask Jens and the others, why Germany? Why did this competing scheme or this extra scheme come along in Germany? it had come out of the Nordics or the Netherlands or Hungary, I wouldn't been surprised. But why was it the Germans?

Gijs Boudewijn 37:00

I'm

Jens Holeczek 37:04

It's maybe the same situation like why is a Berlin Group not named Paris Group or whatever, Madrid Group, or where it could have been the first meeting in the past. I believe maybe it's because Germany had with the GBIC always a buddy who was talking about standardization also in the past. If you look 30 years ago, like a credit transfer is done between banks, there had been agreements. So in a kind of multilateral schemes, Germany always had lot of experience.

I don't know if before PSD2, other countries had something like FinTS or HBCI specifications and standards. So we always were working on multilateral standardization agreements. And if you look also for this Girocard schemes, we also had this business schemes, some experience in the past. And I believe it's just a reason that from our history, we have some.

experience and still the same people on board can bring their knowledge into the creation of this new scheme. Maybe that's one of the reasons. I don't have another reason for it as this.

Michael Salmony 38:17

No, I mean, that's one in the eye for people who don't believe Germany is innovative. mean, they have shown that they were one of the first on PSD2 and they're the first on this new thing, despite it being incredibly complex, multi-dimensional market. So that's a huge achievement you've done there, Jens.

Jens Holeczek 38:33

Michael, we don't talk about digitization overall in Germany. Then I would fully assist what you are saying. So we are there something of the backlights, I believe sometimes. But for the banking field, for the API scheme, I think we are not in front. We are just on the same speed like SPAA. And hopefully we come evolutional more and more together because at the end, it doesn't make sense. Payment always had been scale, scale, scale.

And we also need here one implementation, maximum usage. yeah, we are open for that. But we don't want to restrict ourselves to bring the vision to the front. So just start evolution and not revolution. That would be the better way at the moment, I believe.

Gijs Boudewijn 39:19

Maybe one more wish, just get rid of the Funklöcher.

Michael Salmony 39:23

you

Jens Holeczek 39:24

⁓

I have lot of wishes on that, but...

Michael Salmony 39:28

Okay, let's not delve too much into the use of fax devices in German government, otherwise we will spend a bit more time here. But I think, Jens, you've been incredibly lucid. Thank you very much for explaining this topic, which is indeed complex, and Ralf and Gijs for spending the time with us together. You three young people in your open-neck shirts and me fuddy-duddy with my jacket and old-school tie.

I think we can sign off and thank you all for watching and thank you all here ⁓ for this podcast.

Ralf Ohlhausen 40:04

Thank you. Thank you.

Jens Holeczek 40:04

Thank you for your invitation.