Very happy to be here today. I'm going to be talking about European regulations upcoming in the banking industry, which, which is PSD. And I'm a coder and architect, so I have a bit of a spectrum in the technical stuff in the third part of the talk. So I hope you'll follow and that you'll get some insights from this. Talk a few words about myself.
I'm Mohi, I'm the CT and co-founder of the FinTech Practice of Tech Consultancy Group, which is called COO. And so we design and we build apps for banks and, and fintechs as well in mostly in France, in the UK as well.
And my, my big passion has been in the past few years around APIs and open banking and open finance, not just as a way to fulfill recommendation, but also as a way to develop new opportunities for customers and for and for banks.
And so in the talk, I'm going to be, before talking about the future of this regulation, I'm gonna go, go back a bit in the past on how the, the, the power balance between banks and customers changed.
I'm going to provide a quick walkthrough of the different regulations in that space, both in the past in upcoming, and a few, a few insights that we got, building some sort of a framework to handle these regulations. Not just the one coming, but hopefully the one coming next.
And I'll, I'll, I'll end the talk by saying that it's not just compliance, it's also a way to, for banks to, to build new business opportunities.
So the, the, the story for me, I, I wanted to make it begin very early in the 15th century was the Medici Bank. And the Medici Bank back in the time in, in Italy and mostly in France, was a very, very powerful bank. They're also pioneers because those are the ones who invented the double entry book kick bookkeeping system, which is the cornerstone of the modern accounting.
And so they had a huge influence because obviously they, they, they were very big. So the, they had a, a big influence on the economy in Italy, but also on politics because they, they used to serve as kings and popes. And so I think that at the time, banks were more than ever extremely powerful and king in the ecosystem.
And my, my feeling is that it didn't change so much up until recently because maybe 40, 30 years ago, there was no digital.
When you wanted to do something with your finance, you either had to go to a local branch to make a phone call or a send a letter, but it was always with your banker. And now it seems a bit weird to us because we interact usually with several banks, with several fintechs. And so this, this power balance has changed a lot. And not just because of fintech's competition, but also because the regulatory framework has evolved a lot in the past, in the past 17 years.
So the first step was PSD one. So the first version of PSD one, which is 2007, the, the idea was really to start the competition with the US and to provide a space in the, in Europe for transactions to flow in an easier fashion. Mostly built around the, the network, obviously. But this was a, I think a big shift 'cause it started to create a lot of other possibilities.
The most famous one being PSD two, which arrive more than 10 years later.
And PSD two is very well known in the tech space because the, one of the big ideas of PSD two is that banks are forced of exposing through APIs, customer data, mostly transaction data, and also another set of APIs to initiate payments, which is something that banks obviously hated because the data is most of the value that they have on their customers. So it's, it's been a biggest struggle, depends on the countries, but in France, at the very least, it's been extremely painful for banks to comply.
And then you have, you have GDPR, which doesn't concern only banking data, but I think that both PS D two and GDPR are really around protecting the customer. For instance, accessing these APIs requires strong customer notification, which is a big part of the regulation.
And so I think that the, the regulation is more and more shifting power from the banks to the customers and whatever FinTech or software they wanna use besides their bank, it's not being very successful.
As I said, obviously banks do not like to communicate this a lot, but when you look at APIs to provide transaction data, it's taken sometimes, but at the moment those APIs are pretty stable. But when you look at APIs that allow to initiate payments, well, you can see that you have around one LO two, this is in France, but one and two transactions fail, which is very five years after the implementation. The regulation, it's a bit frightening to see that you have this much failure.
And the factors, there are many factors, the stability of APIs, the, the trust that the person has in the user journey where he's supposed to initiate the payments.
We mentioned before in the talk before SMS versus biometry.
I mean, there are a lot of factors that make this failure go up or down, but the, the fact is that the performance is really not good. And so PSD three, I think the, the main, the main target of this new regulation, which is going to come in the, in the coming years, is to try and solve those problems with PSD two. There are three main pillars in the regulation. The first one aims at improving the stability. So banks are going to have to provide uptime and error rate data for the APIs. And they're gonna have to report on that every quarter.
They're gonna have to provide a bit like a modern tech players, API status page, which are supposedly going to be updated in real time release management. They won't be, be able to change stuff on their API and if they do, they need to warn a three months in advance and they need to provide the fallback flow.
If their API is down, they should allow any player to scrape their website to get the data in another fashion. So this is the first target which is going to tackle the problem I mentioned in the previous slide. The second one is security. So they're going to try to make this more secure.
And what's interesting is that some measure are going to make to lighten the constraints and some other are going to make them harder for, so you'll have iver validation to prevent fraud. Checking that the name provided will match the, the, the account holder. Strong customer notification is actually supposedly going to get less requiring because you can have two of the same strong customer notification.
You, you know, you need to prove that you own something, that you know, something that you, that you are someone. And so you can, you'll be able to use two of the same category.
However, banks will need to perform this strong customer authentication update themself every 180 days while before this responsibility was pushed to third party providers. Those are the companies that are allowed to consume the APIs and to provide them to you.
And finally, the third pillar is around transparency. So banks will have to create a, a front end interface for customers to see to which players the data and identity has been shared to, and they will be able to revoke the strong customer authentication to any consumer of this data.
So, which is going to cause probably some development costs for bank. So this is PSD three and I've avoided you to read the, I don't know how many pages of, of regulation I've done that for you. And basically the, the idea is that it's going to come very fast because Europe is supposed to ratify this this year and banks are already started from the discussion that we have. They're already starting to design these changes before implementing them.
And we, we think it's going to have to be implemented in each nation by end of 2026.
And the other extremely big change is that unlike PSD two, there will be some penalties regarding non-compliance to those, to those rules. Because up until now, I, I know some banks that still do not have any PSD two APIs. Well now I think that when you have a a penalty that is a percentage of revenue, usually things start to happen. So we'll see about that. The other regulation, I'm gonna go very fast with this because it is, it's going to come a bit later. It's called fier.
I don't know if you say Fider actually. And Fider, while PS D three was aiming at making the quality of APIs more demanding, fier is going to widen the variety of data that should be made available. So not only payments and bank accounts, but you also need to as a bank to expose insurance information, credit account loans, any to any form of data. And this is usually data that banks think are more valuable than just transaction data. And so they'll have to provide that through APIs.
We, it's, it's less, it's less urgent. So we don't quite know if the same penalties will be applied, but this will be also another big shift for, for banks.
So we have, we've seen, when trying to look at PSD three and fiar, we've seen three main challenges for bank.
The, the first one is how can they improve the, the stability of their APIs, the metrics that I showed before. Second of all, how are they going to manage to do those developments? And I'm thinking mostly about feeder because those different data insurance loans usually are owned by different departments of the bank. So you'll have cost of development, but also cost of teamwork while PSD two has been managed through usually one team. Now you'll have to have insurance loans corporate to make this work. And finally, a big question we ourself is how can we make those changes a bit future proof?
So in our opinion, what comes next after DSP PSD three and what changes can be made to avoid rework?
So for API stability, the big idea that we've started experimenting to reduce error rates on APIs is to build a stack that relies on two, on two big components. One is observability and the other one is AI ops.
The, the big problem that banks have when they want to improve the stability of APIs is that they, they need to understand which areas of the information system has the most errors and the most issues so that they can focus their efforts on a specific part of the information system. And so gathering all the, the metrics, the logs, the traces, and pulling them in observability tool like Open Telemetry, which is an open source tool, allows you to get all the data the same place to standardize it.
And then you can use AI to process this information and to have several things you can identify the deployment which introduce a regression, for instance, this is one of the causes of API stability issues.
You can build what we call a weak point hit map. The idea is to have a, a view of the architecture of the bank where you can see which areas are buggy and cause the most problems so that you can start investing on those. So the big idea is not to make fixing the issues easier, it's really to make finding out where the issues come from way easier and to reduce the lead time.
So this architecture, and this has worked a lot because we've managed in three months to reduce by to Hal the number of 500 errors that we had in a quite complex banking, it where we had a lot of errors and we didn't know exactly which, where they came from.
The second I for the cost of development and teamwork is really to, to map the, the different domains. So I mentioned loans, I've mentioned bank account insurance.
So domain driven design, which is basically the idea of having a domain expert and a tech expert in the same room, allows you to really identify the sub-domains that you need to expose, for instance, through feeder. Because feeder will require you to expose APIs for all those objects. So this is domain driven design I think we will obviously need, although most of the banks have already selected one for DS P two will need an API management stack with an API gateway, a developer portal that allows developers to subscribe and to publish APIs in an easy way.
And finally, team topologies, which is a a, a quite good book if you haven't read it around team organization would suggest that we would put some teams that own each of these subdomains a team topology called those complicated subsystem teams.
And their goal is to basically make the domains very easy for anyone trying to consume the a p including consumers or third party providers and a platform or enabling team to manage the API management stack. So platform would be, I provide a platform enabler.
Enabler would mean that this team would also be in charge of helping all the teams implement what is common between those domains, such as strong customer authentication for instance. So this is the second idea.
And for, for building future proof assets, what we believe is going to happen is that things are going to be more and more real time. Right now banks provide APIs which need to be pulled regularly, for instance, every five minutes. So party providers will pull data and I think we'll need more and more to arrive at the point where when a transaction happens, it's immediately fetched, for instance, through WebBook.
So I think that this is going to be one of the change that will come in the, in the regulation that banks will be not only forced to publish APIs, but also WebBook so that the attack will pulled or an event system could be another option. And this will pose I think, big challenges in terms of identity verification because when should we do this verification? If data keeps flowing without the user doing anything, I think this will be interesting. So just to conclude that this is not just obviously matching the regulation.
I think that seeing APIs as a business opportunity has been very successful for several players such as Amazon. I mean AWS has been supposedly beat built around the, the Jeff Bezos mandate to told his team build APIs as if you had to sell them tomorrow. And AWS became big success because of it.
But also in the banking space, you have baby VR, which is a, a Spanish bank who's provided before feeder, basically all the APIs that feeder will force them to provide.
So the a I market, and although they don't show revenue numbers in terms of a p monetization, you can see that their growth of the digital channel has been quite impressive. And in the UK you have nawe who are building the, the who are calling themselves the bank of APIs and they've already started monetizing APIs so that it is just not just a constraint, it's also a business opportunity. So you can see they've built Pay It, which is starting to generate revenues through APIs, which is for me, the first use case where I've seen actual monetization numbers show up online.
So basically we've tried to describe some insights on how we can make those change easy, but I think the, the, the conclusion is banks should also try to make money out of this because otherwise it's keep going to be a constraint for them. And it's, I don't think it's the right mindset to, to go on in the future. Thank you very much. Thank you Woody. I'm.
