Will PSD3 finally unlock the potential of open banking?

The recently published PSD3 proposal addresses many of the issues we have seen during the implementation of open banking across Europe over the last 5+ years. However, in order to actually fix these issues banks will need to make significant changes.

Last week, the European Commission published their proposal for the third Payment Services Directive (PSD3). This proposal comes seven years after PSD2 came into force. Some would say this is long overdue.

PSD3 covers a lot of different areas, but here I’m only going to focus on the implications for open banking. In this regard, the European Commission have set out a single, clear objective:

“Improve the functioning of open banking, by removing remaining obstacles to providing open banking services and improving customers’ control over their payment data, enabling new innovative services to enter the market.”

In summary, these proposed changes are very much needed, as they address many of the shortcomings of PSD2 and the associated Regulatory Technical Standards (RTS). Below I have outlined some of the key differences between PSD2 and PSD3 and highlighted the implications, especially for Account Servicing Payment Service Providers (ASPSPs).

The scope is roughly the same

The scope of PSD3 is still limited to online payment accounts operated by ASPSPs. While there is a bit more definition of what constitutes a payment account, there is still room for interpretation. For example, are credit cards in or out of scope? And what about savings or lending accounts? 

Further definition will be needed to provide absolute clarity here. But this certainly isn’t a comprehensive open finance mandate. Perhaps the  European Commission has missed a trick in not bringing a wider selection of account types into scope?

APIs are (effectively) mandated for all ASPSPs

Probably the most significant enhancement is that all ASPSPs now need to provide a ‘dedicated interface’. I assume almost everyone agrees that this means all ASPSPs will need to implement an API and also that this is a good thing. It should certainly make it much easier for Third Party Providers (TPPs), either directly or via aggregators, to deliver open banking enabled services to end customers (Payment Service Users or PSUs).

However, while there is a recognition that this should be based on some form of recognised standard, there is no actual mandated standard, nor is there any requirement for conformance certification. In markets such as the UK, Brazil and Saudi Arabia, we have seen the significant benefits of a common standard with a strong certification regime. So my concern here is that the c6000 ASPSPs across the EU will all implement slightly different APIs, and that there will still be unnecessary ongoing issues.

Needless to say, this does mean that a large number of ASPSPs will need to implement APIs to replace their Modified Customer Interface (MCI) or ‘contingency mechanism’. But, with solutions like the Ozone API Hub, this does not need to be a complex or expensive change.

Major enhancements for both AIS and PIS

Both Account Informance Services (AIS) and Payment Initiation Services (PIS) will get very useful additional functionality as follows:

1. Permission Dashboard – all ASPSPs will now need to implement a permission dashboard, which shows the PSU details of long lived AIS consents from connected TPPs and which also allows them to easily revoke access. This is a great addition to provide the PSU with additional protection in case they wish to cancel any AIS service.
2. AIS re-authentication – the need for the PSU to re-authenticate via the ASPSP every 90 days, in order to retain long lived AIS access, has now been removed. In its place, the PSU must now reconfirm (via Strong Customer Authentication or SCA) with the TPP every 180 days. This should significantly improve retention rates for TPP services and result in much better customer experience for long lived consent use cases.
3. Payment Status – the ASPSP must now provide all information about the status, up to and including actual execution, even if such updates occur after the payment order has been sent by the TPP. The benefits of this are large and obvious for almost all payment use cases.
4. Account Details for PIS – prior to payment initiation, the TPP will get access to account holder details and account details, including account ID and currencies available. Whilst the exact details of this are open to interpretation and would benefit from further clarification, this should enable further customer experience enhancements for payment use cases.
5. Future dated payments and payments to multiple beneficiaries – both of these are now included in PIS and future dated payments can even be revoked. Again, this enables even more payment use cases.
6. Confirmation of Payee – Payment Service Providers (potentially including both ASPSPs and PISPs) now need to provide a confirmation that the payee name and IBAN match before any payment initiation. While this can result in extra steps for the PSU during the PIS flow, it should offer much better protection against the significant challenge of payment fraud.

Interestingly, the UK standard covers most of these enhancements already. Which means that the Ozone API Hub will support this ‘out of the box’.

Recognition for premium APIs

Whilst everything covered by PSD2 must still be offered to authorised TPPs without charge and without requiring a contract, there is now an allowance that additional or ‘premium’ APIs can be offered by ASPSPs for a fee. 

There is a risk that this creates fragmentation, if ASPSPs each try to launch their own bespoke premium API services. However, the good news is that both the UK Open Banking Standard and the Berlin Group openFinance API Framework already offer a range of premium services. And of course these premium APIs are supported by the Ozone API Hub, giving ASPSPs a significant commercial opportunity above and beyond pure compliance.

What about the timelines?

PSD3 is still a draft which is unlikely to be finalised until mid-end 2024. And it probably won’t be implemented by ASPSPs and TPPs till well into 2025.

Many of these changes were driven from issues raised by banks and fintechs over the last few years. Indeed the resulting EBA opinions have now been included in PSD3. However, this framework is still not based on defined use cases. Therefore, there will be further changes needed to fully meet the needs of the market and the end customers. Some of these changes may make it into the final version of PSD3, but it is unlikely that PSD3 is the end-game. 

It may be a bit too early to start planning for PSD4, however, it is very clear that ASPSPs and TPPs need to prepare for ongoing change.

In summary

While this is not a quick fix, nor does it address all the issues raised by the market over the last few years, this is a very big step forward for fintech services and end customer value. 

For many ASPSPs across Europe, this may seem like a major challenge. But this is where we can help. The Ozone API Hub provides a compliant, secure and cost effective solution which will meet all PSD3 requirements ‘out of the box’, as well as enabling a wide range of premium API services. If you’d like to discuss this and what it means for your business, please get in touch.