PREMIUM APIs

Michael Salmony 0:12

Hello, my name is Michael Salmony and Ralf and Javier and I would like to welcome you to another episode of the Payments Trilogue. And this is a bit of a follow on episode from the last one where we talked to Wijnand about Berlin Group and now we're going to drill down even deeper. And this is mainly going to be a conversation between Ralf who loves open banking and Ortwin who's making it happen. So I'll just let those two get on with it. Ortwin, maybe you can tell us a little bit about what you want to talk

Ortwin Scheja 0:41

Yeah, so thank you for inviting me here to this podcast. Very shortly for to my person. So I'm working since more than 25 years now for SRC, which is the competent center of the German banking industry for electronic payments. And actually, I'm with Berlin Group for more or less the very first beginning in 2004, when we first started to dig into, let's say, roaming of cards.

and roaming systems in Europe. That was the, let's say, the start of the discussion. And, but then since 10 years, I'm now with APIs. So after, after my cards passed, I'm now in APIs, starting with defining the PSD2 APIs for, for Berlin Group. And since six years now, let's say diving deeper into ⁓ premium APIs and set up the, I would say standardized a new full ecosystem.

And to my person in the Berlin Group, I'm the lead architect. So I'm leading the technical work streams and trying to get ⁓ business and IT together.

Michael Salmony 1:51

So maybe you can explain to us what premium APIs are as opposed to the other ones you've been doing.

Ortwin Scheja 1:57

Yes. So what you see is the today in under PSD2, we have the so-called compliance API. So the banks are mandated by PSD2, as you all know, to provide interfaces to initiate payments to get access to account information. And this is reflecting, let's say the APIs are reflecting the service scope of the online channels of the banks. So that is the regulation is the PSD2 regulation mandates the banks to offer

sort of from payment initiation and account information, everything they have on payment accounts, what they have in online channels to reflect this in compliance APIs, which ⁓ can be consumed by TPPs for no cost. And premium APIs now deliver much more, so more services than in online channels. And they will come with business contracts between TPPs and banks.

to set up a new business between TPPs and banks potentially on a large scale. And for payments, would mean what sort of, for example, what sort of ⁓ premium payment functions you need to implement a real, let's say, good functioning of APIs or account to account payments. So what is needed in addition to, let's say, compliance function.

Michael Salmony 3:21

Can you give a few examples?

Ortwin Scheja 3:24

Yeah, so if you go to payments, have, for example, the issue if you want to pay loading and a car that takes hours normally, or maybe half an hour or whatever. But at the time when you're authorizing this at the beginning of the loading of the battery, you don't know the exact amount. So you would authorize a maximum, for example, of 50 euros and then

After the loading has been finished, the loading station will tell the application that only 45 euros were consumed. And then only this 45 euros is booked on the account of the customer. So that is one example. Or a second example that is heavily discussed, of course, in Europe. is the, in UK, for example, the variable recurring payment function. And this is also offered in our APIs as a multiple recurring.

payment functions and where we also see first pilots where this is implemented.

Ralf Ohlhausen 4:26

Well,

actually, maybe to dig a little bit deeper right onto that one, because of course, that's one of the hottest topics, VRP in the UK and then MRP or whatever we'll call it, dynamic recurring DRP maybe in SPAA. So it's ⁓ similar or same, I don't know. Is it similar? Is it the same? Do you see differences between what's discussed with VRP in the UK and what we are or you are defining as part of the Berlin Group?

Ortwin Scheja 4:56

Yeah, I would say yes and no. So I would say yes, yeah, the multiple recurring payments as we have implemented, that's the same coverage without maybe going into the all details. I would also need to check this. But what we are doing now and what we are just starting the consultation on, we have even further ⁓ explored the services in two directions. so we are taking now. So there was one major

let's say credit card features still missing. since what we have done is in the premium payments, we are taking one and after the other of the credit card features into the payment APIs, so that we can deliver the same functions also in account to account payments as for credit cards. And so the feature of pre-authorizations was missing. So pre-authorizations where you have complex use cases, for example, for traveling.

where you can separate the actual authorization of the customer from ⁓ a funds ⁓ reversal and the execution, and where you can also update, let's say, fund reservations or authorizations, et cetera. So this is ⁓ covered in a pre-authorization payment function that is now, as I said, in consultation. And we also

sort of marry this with a multiple recurring payments. So on the multiple recurring payments, will in future have multiple recurring pre-authorized payments. So you can really deal with, you authorize a budget for a month typically. And then the TPP can really choose how to use this budget. So whether to have a reservation for two weeks or whether to bundle micro payments where they are only updating reservations or they are just booking on the budget.

because they have just at one time, let's say, a booking, is where the use case is exactly now. ⁓ So this is really a of, let's say, ⁓ a service where you can, where the customer is only, let's say, giving a restriction by setting a limit, typically a monthly limit and delegate all this, let's say, the rest of the service choices, et cetera, to the TPP and to the...

exact use case where this budget is then used in the integration by the TPP. So that is a very powerful function and that's more than VRP is offering in UK as far as I know.

Ralf Ohlhausen 7:26

Yeah, and it's not just TPPs, I guess, to consume this because, you know, I just read yesterday literally about agentic AI payments using or trying to do micro payments here. And even if you can use all these, you know, fancy new

whatever stablecoins and have millions of transactions in seconds, it still may be good to have a budget allocated to an agent that he can use up then over a month's time or so to accumulate ⁓ the spend and then only do ⁓ the settlement once a week or whatever day ⁓ in their own time. So I think that is very, very interesting. Actually,

and staying on payments. this is part of the ⁓ extended payments API extended service. I think it's called, which is mainly the foundation for SPAA and giroAPI, isn't it?

Ortwin Scheja 8:26

Yes, it definitely is. And say the name, if you call this budget, it shows already in how many use cases and scenarios this can be used. So I fully agree with you. Agentic Commerce will be the next big thing where we could, let's say, relate such a token, which is then used for the actual payment initiation afterwards to an agentic entity. And we are authorizing this. It can use the budget up to this budget. ⁓

Javier 8:46

.

Ortwin Scheja 8:53

Or you can even use these budgets, of course, for corporates. Because the APIs are now able also to, let's say, to offer services directly to the corporates of the bank, so directly to the customers, so that they can organize, for example, budgets for people who have no signing rights, but where they are delegated some sort of budgets to be used anyhow, whatever reason, so that not every payment is always, let's say,

signed every day by people with signing rights, can be a lot of things to do or lot of administrative overhead in a corporate. So this is a new way of really ⁓ focusing these services on such use cases and where at the same time the online channels will deliver much information about this via dashboards etc. So this is all

which will also be standardized in the next steps. we clearly try to design a scenario independent, front-end independent platform for banks to offer, let's say, these sort of premium payment APIs to own customers, to agents, to TPPs, etc. And of course, in the next step, also to cards.

Ralf Ohlhausen 10:20

Yeah, and the...

Javier 10:23

Sorry, presume I may be wrong, but I presume that you have developed these extended services and these premium APIs because the regular APIs and the mandatory services were the ones mandated in legislation were not enough or were falling short of what they intended to provide.

So my question is, what would you advise the legislators to do with these basic services and mandatory APIs? Are they really helpful for the best development of the market or are they a burden that we should get rid of?

Ortwin Scheja 11:04

So, due to the... I didn't fully get the question.

Javier 11:11

What would you advise legislators to do with what is being mandated to provide ⁓ PSPs with APIs and basic services in relation to interoperability and open banking?

Ortwin Scheja 11:18

Okay.

Yeah, I mean, ⁓ if you see in the drafts of PSR or in PSD3, you are seeing already the direction the regulator is heading. This is giving more, let's say, they've integrated all sort of level three regulation into level one. And so this is one part which makes sense, of course, because that is lessons learned from PSD2. And they are also indicating

⁓ that there should be more, let's say, more weight on issues like certification. Because of course, as a standardization initiative, we see that the standards are not always developed following the standard. And this topic can only be addressed by, let's say, by things like certification. a certification could be a very helpful tool. this is in all other, in all

let's say business or premium payment systems, you get some sort of functional certification that is our lesson from 40 years of payments history that you need some sort of certification to avoid, let's say, too much variability on implementations, etc. So this is for me a potential, let's say, enabler of more quality.

also the compliance APIs.

Ralf Ohlhausen 12:58

Isn't the move from the NextGenPSD2 1.3, like the PSD2 standard, to the version 2.0, which you've already defined, isn't that already then bridging the gap between old legislation and what we can expect now from PSR to come and getting us very close?

to what the open finance framework is all about. So I guess less difference between version 2.0 of NextGenPSD2 and open finance, isn't it?

Ortwin Scheja 13:34

Yeah, I would say the migration from version one or to version two had two major drivers. One was that we learned from ⁓ version two that we were a bit too sort of not deep enough in the payment structures. Yeah. If you want to deliver more information, et cetera. So we needed a bit more, a bit more structured approach. A bit less ad hoc. mean, PSD2 was.

of course, also for the bank side, a lessons ⁓ learning curve. ⁓ And we needed to, of course, to consider how do we deal with the separation of the sort of microservices you have in a bank and but you are always bundling in online channels. And we also bundled in the compliance APIs for version one. And the second part is on the account information. We, of course,

prepared the system for open finance so that you are differentiating when you are dealing with contents, example, differentiating different account categories, much more, let's say, detailed access rights. you see this now with, for example, user APIs coming up where you have for corporate specifically, where you have sometimes many people who have signing rights and how to organize this in API, how to show this to the customer.

in a good digitalized way. And all these complexities came in which were not covered. And specifically, course, also to separate the documentation and to make much more clear what is the technical framework we are using and what are all these technical functions we using and what are the services. Also to make the documentation much more readable than version one, which was one big dinosaur.

evolving in all the, let's say, remind the discussions we had with the regulators in the beginning of the PSD2 history. So every three months there were some news from the regulators we had to integrate in the standardization, etc. And all this was, let's say, restructured and I think that was very helpful also for the understanding of what we really intend to do in standardization.

Ralf Ohlhausen 15:58

So do you think that all the banks will now move to 2.0? And if yes, is it more driven by regulation PSR expectations or more by monetizing premium services in the end?

Ortwin Scheja 16:13

Yeah, what we see is that all premium APIs we see being developed, for example, the German market, is one of the leading markets in Europe on this. That's all based on version two already. And nobody is investing anymore in version one. But I see also the major part of the banks, that's my expectations from the discussions with the banks, will migrate the compliance solutions to version two only with PSR.

or when the PSR is more visible, what PSR will mandate, et cetera. So you need a good reason, of course, to migrate because of the costs related to it. And so either to say, yeah, we are setting up now a full premium set of services. This is from the very beginning on version 2, so we are not investing anymore, of course, in version 1. But for the compliance solutions, I expect a late migration.

Ralf Ohlhausen 17:10

And actually talking about commercial monetization, we already touched on it with when we discussed with Wijnand about the administrative service API and the possibility to agree pricing between ⁓ the bank and either a corporate or a TPP accessing that API. And there is now also a pricing API coming, I think. so

How will that work and how will that maybe replace the need for schemes and scheme fees which are multilateral?

Ortwin Scheja 17:48

Yeah, so we have described already these sort of features and how schemes and ⁓ APIs play together in the operational rules for the administrative services. So that is a document I recommend to read for everybody because it's about the basics of potential cooperation and API consumption. ⁓

But let's say, of course, the thing is that in schemes, you normally have multilateral fees defined and this might not always be applicable. If you're going to premium APIs and if you go to, let's say, corporations between banks and TPPs, there will be the need of bilateral agreements and prices. I mean, that's not new. It's everywhere also applicable to cards. ⁓

And there we said, from the very beginning, want to have a very efficient procedure to organize this. And that's why we enable with the new price API coming up, we have set up a, let's say, technical system, how to define prices by API calls. And it's a very complex ⁓ API in the sense of, of course, you could have, ⁓ let's say, prices per call, you could have flat fees for sub functions.

or whatever. this is of course, the fantasy can be very ⁓ large on price definitions and price models. Of course, it's a very complex issue. And that is reflected in this price API and the TPP or corporate when using the APIs of the bank directly. They would read this price API and counter sign it. And as soon as they counter sign it, is sort of applicable to the applicable to the API.

consumption, but we still scheme still needed because let's say how to anchor these sort of price confirmations into a real business contract is still needed. Yeah. I mean, because the interpretation of just bits and bytes needs always a contractual basis if it's about fees and you cannot just ⁓ say follow the implementation guidelines from something.

that would not be sufficient to have a legally binding document between a client and a bank. And if the API client is a corporate, this will be done via the general terms and conditions of the bank, the corporate signing. Then it's easy because you have a contract together, but for TPP, you will still need a sort of contract between the bank and the TPP and that can still be facilitated by the scheme. And then you could have this done.

at the one side and at the other side than since, say, as a scheme. But bilateral price definitions can be handled via this API. And the scheme doesn't, let's say, care about this. They're just setting the framework for this, the contractual framework, which is still needed. And that might come later in later steps that we have also contracts that I will assign via this API. But that is for us. We are trying to take this step by step and not

Because if we are designing the full system from the very beginning, that would take years and wouldn't help because then you wouldn't see implementations. We need to take this step by step.

Javier 21:14

I don't know, Ortwin, if I've understood you well or if I am inferring in the right direction, but I think that there is a differential appetite of implementing APIs on Open Banking across Europe. And there are some local markets, some national markets which show more appetite or which are attracted to go quicker than others.

Even if there is certification and we have PSR and all that, don't you see or don't you perceive that there is a risk that there is another ⁓ type of fragmentation with another disguise, which is open banking being differentially ⁓ developed in the different national European markets?

Ortwin Scheja 22:05

I don't know. mean the PSR is already, let's say, a reaction of the regulator and saying this is not a directive anymore, it's a regulation. So it's not anymore up to the different markets to define the functional scope, etc. That's done by the Commission or European regulators, not by the national regulators anymore. That is one, definitely one step towards more harmonization in the European market.

Javier 22:24

Yeah.

Ortwin Scheja 22:33

And don't forget, mean, in our API development, we are not only focusing on the TPP business. So all the premium payment APIs, are often of the full credit card features, they could, of course, also be used by wallet systems. let's say this is maybe a historical... So the wallet systems were a bit before the open banking APIs were really developed, at least most of them.

And it's of course a question in future whether you shouldn't use the same APIs also for the wallet system. not only for TPPs, to have these APIs being the, let's say, ⁓ the minimum set by a bank they offer to all their front end systems. to reduce, and that's what standardization of course always offers, it reduces costs heavily.

Javier 23:31

Mm-hmm.

Ortwin Scheja 23:31

because you can generate a lot of synergies, ⁓ et cetera. And that steps even into, let's say, in future into discussion whether you shouldn't use exactly the same APIs also for the, let's say, European card systems. So it shows how, let's say,

⁓ how big the vision is. ⁓ It's very long term, we know, but what could be offered to the market by banks.

Javier 24:00

Yeah, Okay,

yeah, yeah. I think regulation is there, okay, and it's a uniform regulation that applies to everybody, but I was asking more about how it will be adopted, how it will be deployed in the different 27 member states. Do you see that finally we will have a more uniform deployment of ⁓ open banking and APIs used widely by everybody?

more or less, so no big differences in between the different national markets.

Ortwin Scheja 24:38

Yeah, I expect this to happen, of course, from the functional side, whether these all these APIs so that was, let's say, always the complaints from the TPP side, if I understood Ralf correctly in the past, that the let's say the implementation is of standards is varying, not due to the standards, but ⁓ due to implementation decisions of banks. And ⁓ I think this is where what I read from the legal texts that the let's say

I said already before today that certifications and to really prove that you are following certain standards is a much yeah will have much more weight and the next describing whether will this mandated is another point but there will be more let's say more more concentration on this issue by the regulators that's what I expect yeah let's see what the regulators how they will really act and this will be having if so this will have

⁓ heavy impact on the implementation and also on the let's say on the quality of the API's you can you can achieve ⁓

Ralf Ohlhausen 25:43

Yeah, and if I may comment, because I must say I'm not overly optimistic that regulators in or national competent authorities in all these countries, which have been very weak so far on any enforcements, that they will suddenly change and that will have stronger enforcement on PSR. So I continue to believe that the majority of banks are on a defensive path. They were trying to get away with the minimum

Well, they can get away with and that depends on their regulator on whether they let them do that or not. so not, I'm not optimistic on the regulatory side, but there is this other aspect and you alluded to it that these, all these APIs, of these premium APIs are also there or probably mainly there for banks to address their corporate clients.

and to allow their corporate clients to use everything and to have more automation there. And so that's basically one question on how that is important. But the second one is that ⁓ the other consumer of the API will be AI. So we discussed already. what's the plan?

on making it easier to consume for AI. So for example, is there a plan to have MCP front ends to all these APIs or do you plan some other plans in this direction?

Ortwin Scheja 27:12

Yes, actually we have, as you might have seen it, it's on our roadmap this year to define this and we started the discussion and we had no time yet to discuss this this year because we were driven so much by the digital euro, which is another, let's say, direction where we are turning to. But of course, agentic functions will be very important and I guess that we will end up with certain MCP models.

Yeah, but that's only my first impression. But let's say the first discussion showed already that we first need a clarification whether this is automatically direct access or whether this is a TPP access or what is about consent, what is about SCA. mean, agents cannot just act on their own. And of course, the solution would be to deliver them payment tokens once they have been authorized, for example.

and to associate to agents certain budgets etc. That is of course thinkable. But again, this needs to be well understood and I think we need a learning curve here and also with the banks how the agentic model ⁓ works with their own interfaces, with the TPP interfaces etc. And ⁓ I expect there, let's say, very good discussions in the next six months.

And let's see where this leads. But that's of course now after we have delivered most of the things which are needed by the digital euro, this will be the most important topic for the rest of the year to be discussed in Berlin Group.

Michael Salmony 28:55

Hmm.

Ralf Ohlhausen 28:56

Could I ask you, going a bit beyond the payment side into what's called another one of the extended services, premium services of the Berlin Group is the extended AIS. So going beyond the compliance AIS that we know from PSD2, this extended AIS and all the extra functionality, can you explain a bit what is there? Because that is, think, what is ⁓ leading the way into open finance.

Ortwin Scheja 29:24

Yes, so in Extended AIS we are covering already ⁓ many account types of the banks. So we are covering not only payment accounts, AIS, but also loans, ⁓ credit cards, savings and securities. And the securities part is of course a very big API, as you can imagine, so that you have all sorts of information about your portfolios.

orders, ⁓ order history, transaction history, etc. And ⁓ that is from the banking part, I would say a big part of FIDA, of the current FIDA scope already. And this needs to be extended, but we are starting with this already because we are now also starting to discuss in Berlin Group how we could use these not only for FIDA and that it seems like FIDA is still in under discussion and we see how this really ends up.

in the European ⁓ legislation, but we have other applications like cooperation with other companies, etc. where they need sort of audit confirmation from the corporate banks and where a lot of this data already needs to be standardized and for this specific use case. so this is also something we are into this year to extend the let's say the the sort of financial instruments which

could be shared with the third party ⁓ into more complex one than just accounts. And that would be, I would say, is the 20 or 30 % still missing from the banking part of FIDA in the standardization? And this is what we are starting now to address and where the audit companies are very interested in to get, let's say, really structured data and not only, let's say, PDFs from the banks as it is done today.

Ralf Ohlhausen 31:18

Yeah, it's one of my biggest concerns is actually the shortfall ⁓ in FIDA to only looking at account information, as opposed to executing, doing things on those accounts. So there is no equivalent to the PIS side that we have in the PSD2. ⁓ So at best, if FIDA comes at all,

we will be able to get account information, extended account information, maybe from all those different types of accounts, like an investment account, but we will not be able to initiate an investment, to make an investment. So this is where I think we are already now looking at agentic AI being an important alternative or complement maybe in this context, because they will not have that restriction.

to only look at account information, only having this read access. There is also the write access. And that, I think is, yeah, is a pity that FIDA is not already foreseeing that.

Ortwin Scheja 32:32

Okay, that is up to the legislative travel to judge and to say, but I can only say that of course it will be from a standardization point of view once we have the account information defined, ⁓ it's an, I would say a small step to also deal with the, let's say agent perspective. So to act also on these sort of instruments and... ⁓

For example, we have a change request where we say, yeah, to sign saving contracts. Yeah, so to directly distribute saving contracts via the APIs. Why use platforms for that as today? Why not offering this as a bank directly? that is again, I mean, that's a major driver and civilization is of course to have the, let's say the value, the huge parts of the value chain again in the bank.

and not in external platforms. And that can only be delivered by standardization. so a ⁓ more efficient corporation is only able with standardization. ⁓ We know very well from payments, but this is also, of course, applicable to other banking business. It's always a network ⁓ economy.

needs standardization if you don't want to rely on platforms. that is, let's say, always the important part. And that is what we have as a vision to enable the banks to use standards as a sort of new model or an alternative model. Platforms will not vanish from this, but it gives more choice to implementations. It gives more freedom to banks to act.

That is, course, an economic perspective, always ⁓ very good.

Michael Salmony 34:26

Hmm.

Ralf Ohlhausen 34:27

Yeah, and we have this situation where we have, think a lot of what we discussed depends on consent. So consent by, well, the human in the end, but maybe delegated or budgeted to some extent, all that. now we now have this, or we have coming up.

⁓ the idea of a dashboard, of a consent dashboard in PSR. And if FIDA comes along, we'll have the same there and hopefully actually one on the same. anyway, so is there, you have your consent model as part of your architecture. Is that evolving into a dashboard standard that would harmonize things there?

Ortwin Scheja 35:11

Yes, so we will end up in a consent dashboard in the PSR standards. And even if it's only for the online channels of the bank, we will deliver because dashboards and customer communication is more more important if the business you are standardizing is getting more more complex and discovering more services, you need a better overview of what's really happening there for the customer.

And that's why, let's say, dashboards also for the extended payment functions will be more and more in our concern how to standardize this. But let's say the consent for AIS is something different as, let's say, a consent for call it, for example, an order, a financial order. That's very different. there we will, so if we start to standardize this or then

we will go more the direction from the payments where you have then the dedicated consent functions on the services such because the services they are so different. mean, a payment is very different from an order. It's very easy to have the SCA, so I wouldn't call this consent, but the SCA channels and how this works. So the customer authentication, how this is integrated into the framework.

And that is, let's say, what also version two is offering. Not only the embedded decoupled redirect, what we have, but digital signatures, asynchronous customer authentication afterwards in the online channels, and now even cards as an SCA ⁓ approach to how this is integrated uniformly to every service and is very service independent. Now that is independent of a service. So that is described in the whole framework. And that makes the framework so strong that you can then easily set up new services

And then it's from a technical perspective already clear how the consent process will be dealt with. And so once implemented in the bank, that can be just reused. And that is the strength of the approach and let's say a result of years of discussion in the technical.

Javier 37:22

Yeah. Orvin.

Ralf Ohlhausen 37:24

Yeah,

so if I understand you correctly, this is about replacing all these backends. So the banks are so back-end heavy ⁓ and everything has worked on back-end connections. And now taking this all to an API front-end is a bit of a ⁓ quantum leap.

Ortwin Scheja 37:38

Yes. Yes.

Yes, exactly. the complexity in future will be only in the APIs.

Javier 37:42

Yeah.

And Ortwin, how do you see open finance in Europe in 10 years? Will we have got to the arrival line or will we still be in the making of, not yet enjoying the benefits it is promising today?

Ortwin Scheja 38:09

Yeah, so I'm an optimistic person. And you need that, you need this optimism to drive standardization because standardization is sometimes a very dry business. Because standardization is a very strategic business, actually. And that's, I think, sometimes sub-estimated by market participants. But standardization is key in network.

industry and how you drive standardization is a very strategic question. And let's say our vision of course is that in 10 years

the whole interaction between banks and TPPs and agents and corporates and private users, they will all be via these standardized APIs because otherwise the costs cannot be, let's say, they are not bearable otherwise. So ⁓ you need highly standardized platforms ⁓ to

let's say to have the synergies reached you need for ⁓ for mass business. But how this relates then to what we also see in 10 years, so much will happen. mean, the emerging of banks, how will this change the industry? That's very difficult to predict for everybody of us, guess. But we see this, of course, that the capital union discussions

and how this will change Europe and the whole ecosystem. I think it's very clear that it will be changed a lot in 10 years. If you look back now 10 years ago, we just started the discussions on PSD2 and what this really means for banks. now we have achieved, let's say, discussions on how should premium APIs really look like? How should this interact? How does this relate to wallets? How does this relate to cards with the digital euro?

And it shows that in the next 10 years a lot will happen. So that at least I think is very clear. A lot will change. And standardization will be ⁓ one of the very important parts of this developments.

Michael Salmony 40:31

Okay, I think it's almost time to wrap up. Ortwin, you've made a fantastic case for standardization. I particularly liked your argument, the more standardization we have, the less we need platforms. I think that's something that's a really good insight because we all know that the mixed benefits of platforms, right, to then sort of completely capture us and monopolize us. And so maybe more standardization is required.

I was also intrigued with the price APIs. I I know there are sort of price negotiations every time you open a website with some advert servers. What price will you pay for me to get a sneakers advert in the next millisecond? So I know these things do exist. I'm still struggling a little bit to see how that's going to work in payments that we have these sort of dynamic pricing APIs going backwards and forwards. But it's an intriguing idea. What I thought was... ⁓

I think worth developing is the sort B2B side. I mean, I'm not sure that the big banks really need standardization of APIs with their big corporates. I think they've already done that. The ERP integrations and everything is already there. But for the sort of mass market, I think there's a lot of opportunity. I mean, the thing where open banking works the best, to my knowledge, in the world is in the UK for SMEs to submit their taxes.

And that's a standardized process that is facilitated by open banking. I think there's lots more potential there. So ⁓ look forward to what Berlin Group will be coming up in the future. So thank you very much, Ortwin, for enlightening us on all your thinking. Very interesting as usual. And ⁓ thank you all for the lovely, lively discussion and for watching. And look forward to seeing you all next time.

Ortwin Scheja 42:19

Okay, thank you very much for having me