The main objectives of the PSD2 directive, which the EU put into effect not long ago, were increasing the security of online payments, making customer accounts available to fintechs via API, and changing the world of digital banking. After four years, however, the tides have turned, and PSD3 is set to arrive. What will the new directive bring? How will it help Czech companies? And do we even need new legislation?
It was January 2018 when the European regulation PSD2 came into force. Politicians, first and foremost, promised it would provide safer and more agile online banking and untie the hands of fintechs. Yet, the reality differed quite dramatically from these expectations. Although it launched a definite shift in how we thought about the online payment industry, any hope for simplifications went right out the window. Young companies soon realised that their services were aggravated by an array of technological, business, and bureaucratic obstacles.
PSD2 – good on paper, bad in the real world
Deploying the original directive proved to be very costly. Banks and other financial institutions paid over 8 billion euros to implement the Open Banking API and Strong Customer Authentication (SCA). Plus, PSD2 and the Regulatory Technical Standard (RTS) left lots of space to interpret the individual regulations. Thus, banks were forced to waste more money on legal and realisation services. An impact study by the European Union showed that most financial marketers were left with a bitter taste in their mouths.
So, where exactly did things go wrong? The mentioned fintechs had to undergo a long-drawn-out certification process and battle against the disunified banks’ APIs. Because the banks aren’t financially motivated to provide a PSD2 interface consistently and with high quality, most opted for the path of least resistance and implemented the absolute minimum set by the directive. In addition, the legislation didn’t require any specific uptimes or response rates from the banks or even a minimum data set that the institutions are meant to provide as part of the PSD2 API. And that’s the reason why, to this day, companies still face constant obstructions from banks.
How fintechs are losing users
Another problem is the consistency of data between the Internet Banking and the API interface. Many banks are missing metadata on transactions, it’s not possible to access an account’s entire payment history, and the balances are sometimes incorrect due to various methods of calculating them. This difference between information in banking and that provided via the API is shooting the applications in the foot, whose goal it is to clarify this information for the customer as much as possible.
Moreover, according to the rules set by PSD2, users of AISP fintech applications (providing mediated information about clients’ bank accounts) must verify themselves with their bank via SCA every 90 days. Understandably, this annoyed many people, meaning fintechs are continuously losing active users. This, for instance, creates a massive complication for applications aimed at personal wealth management.
Problems across e-commerce
The situation isn't any better for companies using the API to initiate payments from the user’s bank account (PISP). That’s because payment institutions frequently won’t provide all the necessary information in the API to make payments comfortably. Sometimes, the current balance or currency used by the account is missing. Other times, the payment status in the interface is heavily delayed or even completely unavailable. Plus, the requirement to undergo SCA for every payment limits multiple use cases, like using a PISP API for payments via loyalty cards.
It’s relatively paradoxical that the sorry state of the individual APIs brought new players to the market. The so-called “open banking aggregators” built a business by fixing the mistakes caused by the directive and unifying interfaces. Today, they unite the splintered APIs and provide companies with a functional interface.
The problems of PSD2 also affected digital marketplaces and e-shops. The required SCA may have improved user security, but it also increased the number of unfinished transactions due to poor UX and a challenging verification process. An EU impact study revealed that, due to SCA, the unfinished transactions stand at 33 billion euros every year. All these mistakes led the European Union to update the legislation with a new set of regulations. The result is that PSD3 is expected to remove the most significant obstacles faced by fintechs in past years.
Greater protection, improved clarity, and fewer hurdles
The new directive will introduce more requirements, primarily for banks. They will soon be forced to provide users with an interface with an overview of all access consents they have granted to third parties. Users will also have the option to withdraw their consents and, theoretically, even renew them. Next, banks will be forced to provide public information on the accessibility of their interfaces and inform third parties at least three months before any possible changes. They will also have to make their test environment available, where fintechs can try their integrations. Also, the requirement for clients to repeatedly verify themselves every 90 days will no longer apply to fintechs using an AISP API. This should significantly increase user retention and make using aggregator applications a more pleasant experience.
PISP APIs can also expect some changes. A feature for deferred payment will be added, and thanks to the API, such payments can be revoked until they occur. The revoked payments can also be renewed, giving users more control over their scheduled payments.
However, the remaining SCA requirement when making payments is a wrinkle in the otherwise revised PSD3. At the same time, banks must have fintechs or users confirm that the recipient’s IBAN and name coincide before sending the payment. While this may reduce the risk of foul play, it also further muddles an already complicated user interface as, currently, there is no “register” that would contain this paired information and help banks evaluate it.
From open banking to open finances
PSD3 isn’t the only change that fintechs and banks can expect to see soon. The regulation Framework for Financial Data Access (“FIDA” for short) is also being prepared in the Union. It’s supposed to open interfaces to most financial institutions and make financial product data available beyond bank accounts.
This, for example, means that customers will be able to compare the cost-benefit of their mortgage using comparison applications without having to manually enter the data. The apps will simply fetch the necessary information from the existing provider via the API. Contrarily, this regulation doesn’t impact current and savings accounts or scoring. Principles such as providing information upon a user’s request and the option to revoke consent are the same in FIDA as in the classic PSD3.
However, unlike the PSD, FIDA should bring a certain required standardisation within data model specifications and API interfaces. This should lead to a more unified digital ecosystem, but there will still probably be room left for the abovementioned API aggregators.
Changes? Within 2 years at the earliest
We will have to wait at least until the end of this year before the new rules come into play. The member states have 18 months to implement them, so we can assume that the legislature will become enforceable sometime around 2026. European representatives promise that the finalisations will be made to the additional FIDA legislation at the start of 2025, meaning it’s also expected to go into effect by mid-2026. However, everything depends on the ongoing negotiations.
For banks and payment institutions, this means they will have to undergo new certification within two years of accepting PSD3, which will prove they are operating under the directive. Although these dates may seem far in the future, thanks to our expansive experience with implementing PSD legislation for banks, we know how good it is to start preparing now.
This article was originally written in Czech for "IT Systems" magazine.