We are almost celebrating the three years anniversary of PSD2. When it was first introduced, it made many promises for our industry. These promises included more innovative services and more competition, leading to better services and more security for the consumers. It also wanted to remove barriers for new entrants.

Some time ago, I wrote a piece on the issues we were still facing as a PSD2 regulated entity. We see today that the number of regulated Third Party Provider (TPP) in Europe has been, as expected, stagnating, due to the burden of the process.  We've also seen, very few advantages from being regulated versus using an aggregator like our product, Ponto, which provides a “license as a service” model to any software solution such as ERPs and personal or professional accounting tools. 

Nevertheless, we must admit that PSD2 does have some positive impact on the financial industry. It opened the discussion around open finance, and gave banks a sense of urgency to provide better connectivity to both regulated entities, but also to their own partners. Even if it didn’t really use the most appropriate way to do so, it forced our whole industry to wake up and enter the API economy.

At the time of this writing, the European Commission has finished their consultation on the revision of PSD2.

In this post, I’ll share our five wishes for open finance and the revision of PSD2:

1. Stop mixing account information access and payments in the same legal framework

A payment directive should be about payments and only about access to the data necessary for the payment itself to be executed. Mixing two fundamentally different functional use cases in the same legal framework creates a lot of confusion and too much room for interpretation.

It also makes it hard to evolve in a “decoupled” way. Why amend a payment directive to add access to savings accounts for instance? By allowing both services to be served in their respective legal framework, we make it possible to evolve at a faster pace on both topics independently.

Our wish is for a new open finance framework to be created to deal with details regarding access for consumers and corporates to their own banking data (e.g.: accounts history, customer information, etc.). Plus, to keep in the payment directive only the parts related to payment requirements.

2. Reduce barriers to entry, especially for AISP

Currently, TPPs must be regulated if they want to gain access to the bank's PSD2 APIs. They go through a cumbersome and long process in order to gain access. However, for most new Fintech startups, who actually deliver the promised innovations, it’s simply not worth it. Startups usually have limited runway, they can’t afford to spend months in a regulatory process before starting to get money in the bank.

If we really want to reap the benefits of PSD2, it is essential to reduce the barrier to entry, especially for Account Information Service Providers (AISP). Indeed, outside PSD2's scope, there are a lot of ways bank account information is shared today (e.g.: for accounting purposes). It is done either via manual file transfers, FTP connections, dedicated APIs, or via emails. These existed prior to PSD2 and are still non regulated today.

The risk of such services for anti money laundering is non-existent. However, with these current methods, the risk of data breaches can be quite high since the security of the connection or transportation means is not always up to industry standards.

AISP services are one way to solve this issue. Indeed, the PSD2 Regulatory Technical Standard guarantees that data exchanges between parties is sufficiently secured. But in order to really make an impact on how such data is exchanged today, we need AISP to be widely adopted by any software that actually needs this type of data. Hence, reducing barrier to entry for AISP services is essential for the security of bank account information exchange in the future.

3. Start actually trusting TPPs with SCA

Strong Customer Authentication (SCA), plays a key role in any PSD2 customer journey. If we look into AIS specifically, there is no account information that will be exchanged between the bank and the TPP if SCA has not been performed at the bank by the Payment Service User (PSU).

Every 90 days (soon 180 days), an SCA must be performed again at the bank, regardless of the fact that the TPP has lawfully collected an explicit consent from their customer that they wish to keep using the service. This is contradictory. Why are we bothering getting regulated if, even when we capture a compliant consent from our customers, we still need to direct them to their bank?

It would be more logical that the SCA is performed at the bank only the first time the account needs to be accessed via a given TPP. This would establish the technical link, but for any renewal afterwards, the TPP should be in the driving seat. The TPP providing a simple renewal notification to the bank should be sufficient for the access to be renewed, without interrupting the usual customer journey. Again, why bother being regulated and go through audits from our national competent authorities if we are not trusted in the end?

4. Deliver on the promise of an EU level playing field

PSD2 promised to provide a level playing field across Europe, but in practice, it’s not the case. There have been and there are still quite a lot of inconsistencies and differences across countries in the way the directive has been interpreted by both the different national competent authorities and the banks. These differences create awkward situations where a TPP from country B is allowed to perform their services in country A in ways that are sometimes not accepted by the national competent authority of country A for domestic TPPs.

When talking about the interplay between Anti Money Laundering (AML) and PSD2, it’s even less clear, with National Competent Authorities (NCAs) in some countries unofficially saying to their PSD2 TPPs that there is no specific KYC (Know Your Customers) requirements for PSD2 TPPs and other countries requiring full compliance with AML almost like a bank would need to.

Another example is credit card transactions. In some countries credit cards accounts are a payment account, in some other they aren’t. There are of course very valid reasons to interpret it as such. But in practice, for the Payment Service User (PSU), it is deeply confusing that in country A, they get access to their credit card transactions but not in country B. It damages the trust that PSUs have on TPPs.

Our wish is that a final, and unequivocal interpretation is imposed for all European countries on all matters related to PSD2 and its interplay with other regulation like AML. Consistency from the point of view of the PSU should be the main focus, not legal speak jousting.

5. Make banks and NCAs accountable for the quality and reliability of the APIs

It’s undeniable that the quality of the APIs has improved in the past 3 years. I remember vividly the kind of problems we were facing in 2019, and the disastrous state of readiness of APIs, but also of the processes to get a qualified certificate. We can now safely say that things are getting much better. Still, whenever there is an issue with a bank API, it’s usually up to the TPP to provide proof of non-compliance, as well as to build a case to send to the national competent authority. It means that on top of the regulatory requirements to become and stay a TPP, you also have to spend a substantial amount of time when the API of the bank, for which they received an exemption most of the time, is not working properly.

This adds additional costs on TPPs that are sometimes already short on runway. It’s understandable, the regulators are not used to “test APIs”. Plus, it’s unlikely that any of them actually connected to these APIs themselves, even if it is only through the sandboxes provided by the banks.

One can wonder why the local competent authority did not perform such tests, most of them have IT resources in-house and it would probably be a good idea to require them to assess the quality of the APIs in their respective countries. That’s what API sandboxes are for.

The burden of the proof should also be shared. It’s still strange that concepts such as Service Level Agreements are not pushed on banks by regulators. This would allow regulators to require acceptable resolution times, monitoring and reporting on these Service Level Agreements (SLA).

Today, some reporting is required by the banks, but it is not compulsory and not always relevant. Standardizing what is expected and putting specific targets in stricter SLAs would likely help harmonize the quality across several banks and make it more visible to the regulators where problems actually occur. It’s likely that they are currently rather blind if TPPs don’t spend enough time reporting issues to them. Our wish is therefore that strict SLAs are introduced in the requirements that banks must fulfill to get an exemption from the fallback and avoid fees.

Conclusion

PSD2 was full of promises, and after three years we are starting to see some of them slowly being realized. However, there is still a long way to go, and there are several important points that, according to us, should be taken into consideration in the next revision of PSD2 and other related regulations:

• Stop mixing account information access and payments in the same legal framework so we can make both evolve at their own required pace without impacting each other. That way, regulation can adapt to market innovation faster.
• Reduce barriers to entry, especially for AISP, in order to foster innovation and make account information sharing more secure for both consumers and companies.
• Start actually trusting TPPs. Every SCA renewal should not require that the payment service user is sent to the bank. TPPs should be trusted to collect the proper consents in order to continue the service.
• Deliver on the promise of an EU level playing field by clarifying the gaps in the AML/PSD2 interplay as well as the way requirements set out in the regulation must be interpreted in all countries without exceptions. Make consistency across EU a top priority to avoid PSU and TPP confusion as well as overall mistrust in PSD2.
• Make banks and NCAs accountable for the quality of the APIs by involving the NCA in the testing of the APIs and introducing strict SLA requirements towards banks.

At Ibanity, we still believe in the initial promises of PSD2, and we still keep working forward. Let's see what the next three years will bring to our industry!