On June 28, 2023, the European Commission (EC) published a set of new legislative proposals, notably for a third Payment Services Directive (PSD3) and a Payment Services Regulation (PSR). It foresees changes to the foundational framework of the European payments market and is likely to have a material impact on the players subject to it, both from a legal and operational perspective.
The reason is straightforward. PSD2, which primarily came into effect in 2018 and partially in 2019 with regulatory technical standards, included a provision mandating the European Commission to evaluate its application and impact in collaboration with other legislative bodies in the region. This assessment was intended to determine whether PSD2 was effective or if modifications were necessary. In October 2021, the European Commission initiated a Call for Advice, seeking input from market players on how PSD2 had been functioning and what changes were needed.
This review process, outlined in the law itself, serves as the trigger for the transition. A similar mechanism is likely to be in place for PSD3 and PSR. After a designated period following the enactment of this legislation, regulators will conduct a review to assess whether there is a need for PSD4 or its equivalent. This process essentially initiated the transition.
During a specified period, various market players, including banks and third parties, had the opportunity to provide feedback on what was working and what needed improvement. Based on the extensive feedback collected, the European Commission introduced proposals for both PSD3 and PSR in June of this year.
The European Commission has concluded that PSD2 was largely successful. It significantly reduced fraud cases, enhanced security, boosted innovation, and saw the successful emergence of Open Banking. However, there was room for improvement, particularly in the Open Banking domain and the need for harmonisation.
To address this, they've divided the regulations into two parts. PSD3 remains a directive, focusing on licensing and the operation of payment service providers. It will continue to be transposed into local legislation. The rest of what was previously under PSD2 is now covered by PSR, which is a regulation, automatically becoming law for all member states. This eliminates local interpretations and ensures a more harmonised approach.
In the Open Banking space, PSR encompasses all the requirements and changes. PSD3 has a limited impact, primarily concerning how regulators license and authenticate third-party providers. PSR is more comprehensive, formalising guidelines and opinions that have accumulated since PSD2's introduction, aiming to clarify the previously unclear parts of the regulations.
The goal is to strike a balance between providing enough detail to reduce the need for numerous opinion papers while avoiding excessive complexity. This change aims to streamline the regulatory landscape and enhance market clarity.
This is a critical question, and the answer isn't entirely clear. PSR initially states unequivocally that there will no longer be a need for fallback mechanisms. However, it later introduces the concept of an alternative solution in case of unavailability. Unavailability is defined as five consecutive API call failures, which is quite broad and could encompass minor disruptions.
The term `alternative solution` raises questions. Does it imply that third parties can screen-scrape banks' online and mobile systems? PSR insists on proper third-party identification, resembling what we used to call a fallback solution - a way for third parties to identify themselves through certificates and use an alternative approach. In essence, while PSR seems to eliminate fallback, it introduces a concept that resembles it. The situation is not entirely clear.
This concept falls into the realm of comparing apples and pears rather than being unclear. Historically, we've always required PSD2 API interfaces to perform at least as well as online and mobile banking interfaces – a logical requirement. However, the challenge lies in comparing these two interfaces. While we can measure their performance, it's important to note that the usage patterns of the PSD2 API interface and the banks' online and mobile interfaces aren't directly comparable; they are fundamentally different.
Let me illustrate with an example. Banks often work with older legacy systems and may not have the most cutting-edge technology in their back-end systems. To maintain system efficiency, we've spent years optimising our user interfaces to prevent excessive calls that could strain the background systems. When using a typical mobile banking interface, a user logs in, sees a list of their accounts (potentially a limited subset for better performance), selects an account to view transactions, and drills down for transaction details. This is a controlled and efficient process.
In contrast, with the PSD2 API interface, a typical use case might involve a third party requesting multiple customers' accounts, all their account transactions, and all the transaction details – all concurrently. Comparing the usage of the PSD2 API interface with the use cases in the bank’s online interfaces is therefore comparing apples to pears because the data volume and usage patterns are inherently different between these two interfaces.
While we can measure the performance of both interfaces, the difference in data request volume remains a challenge. I haven't seen anything in PSR that suggests this comparison will become easier. Therefore, we need to explore ways to ensure fair usage between these distinct interfaces.
PSR does mention standardisation to some extent, but not in the sense of API standardisation that defines specific fields and requirements for each data element. The standardisation mentioned in PSR is more at a high level, suggesting the use of common data formats, which I would interpret as for example using JSON format. However, PSR does not provide detailed guidelines for standardising API formats. In the context of aggregators dealing with multiple banks, it means that each bank may still have its own unique API format.
It's possible that the issue of standardisation could in the future be addressed through industry collaboration or by appointing an industry standardisation initiative to establish a common standard. However, PSR itself does not bring immediate relief to the challenge of dealing with various bank-specific API formats.
Based on my reading of the current proposal, it appears that within the scope of what I would refer to as PSD2 services (AIS and PIS), there won't be room for compensating banks. While there's the potential for contractual agreements between banks and third parties or partners and customers around the so-called premium APIs, this is consistent with the current setup, and I don't foresee significant changes in this regard with PSD3 and PSR.
There has been much debate and discussion surrounding the compensation issue, as both PSD2 and PSD3, along with PSR, impose substantial implementation costs on banks. However, as I understand it, PSR does not seem to support direct compensation to banks. I have a sense that such compensation discussions might pertain more to Open Finance or related regulations that will follow.
The trend is quite clear from our own statistics and usage of our PSD2 APIs. From 2019 to 2021, there was almost exclusive access to personal customer data, with a strong emphasis on aggregation and personal finance tools. However, starting in 2021, we observed a gradual increase in access to our business customers, particularly small and medium enterprises (SMEs). This trend is on the rise, and while it’s still relatively small in comparison to the broader landscape, we are also witnessing some limited traffic related to access to our corporate customers’ accounts. The market is indeed evolving, with a growing focus on business access.
Certainly, account-to-account payments might get a more significant boost with PSD3. The ease of the customer experience plays a pivotal role in the adoption of such payments. The European Commission has recognised existing obstacles for third-party providers in creating a smooth account-to-account payment journey and has outlined improvements and requirements in PSR. Banks that do not offer a seamless user experience will be obligated to address these issues, potentially increasing the usage of account-to-account payments through third parties.
However, when we consider the user experience, even with the obstacles removed, it's important to note that account-to-account payments via PSD2 APIs, no matter how smoothly implemented, will always involve strong customer authentication (SCA) enforced by banks for security reasons, just like in the bank’s own online interfaces. In contrast, services like MobilePay in Denmark offer a highly streamlined experience where a simple swipe inside the app completes the payment. So, while PSD2 APIs will certainly become smoother, and be as smooth as in the bank’s own online interfaces, with fewer steps and improved friction, it may not match the seamless experience of services like MobilePay or Apple Pay. This is primarily because PSD2 aims to enable the third party providers to offer the same services as the bank’s own online interfaces and the regulation does not delegate full SCA responsibility to third parties for payments. Therefore, while account-to-account payments will likely increase, they may not fully compete with the experience offered by dedicated payment apps under this regulation.
Indeed, cross-border payments are an area where we could see more promising developments. Simultaneously, there are other regulations in progress, particularly in the realm of instant payments.
We've always held the perspective that the real magic occurs when instant payments and Open Banking converge. This intersection offers substantial opportunities for innovation. Furthermore, the harmonisation aspect, coupled with fewer local variations and more standardised practices, will be a key driver in smoothing out this landscape, making it more seamless and efficient. Harmonisation is the operative word in this context.
Part two of our insightful interview with Nordea will be featured in our upcoming Open Finance Report 2023. Stay tuned for more!
Sanela is Head of Open Banking at Nordea responsible for both PSD and commercial APIs. She has worked with Open Banking since its beginning in 2016 and is passionate about complex implementations and how to realise them in the most efficient way.
Nordea is a universal bank with a 200-year history of supporting and growing the Nordic economies – enabling dreams and aspirations for a greater good. We are the largest bank in the Nordics with a strong market position. Every day, we work to support our customers’ financial development, delivering best-in-class omnichannel customer experiences and driving sustainable change.
Every day we send out a free e-mail with the most important headlines of the last 24 hours.
Subscribe now