As Europe moves towards a true digital economy, we can make more from all the opportunities offered by data and data-driven innovation in the financial sector. More sharing of personal data, while retaining full control over it, will allow people to access tailored products and services that suit their needs, and also create room for the financial industry to innovate. Today’s proposals set strict conditions on rights and obligations for open data-sharing to protect privacy, and to give full control to customers over access to their data and how it is used. The same principles apply to new data technology developments in payment services, where we intend to reinforce consumer protection - including by improving fraud prevention - and make sure that consumers are offered the best and cheapest payment service.
Valdis Dombrovskis, Executive Vice-President for an Economy that Works for People
In PSD2…
Today, Application Programming Interfaces (APIs) are the main method of accessing payment accounts for open Banking services, but they are not the only one. To ensure business continuity if APIs are not working, most banks are also required to have a fallback mechanism in place that TPPs (third-party providers) can use to connect to their customers’ accounts.
The fallback mechanism allows screen scraping to be used as an access method on an ongoing basis, rather than as initially intended: just when the API is not working.
This has been a distraction which has held back open banking APIs, as ASPSPs could delay proper implementation of the main interface in the knowledge that TPPs theoretically had the fallback interface to rely on. In practice, the majority of European TPPs connect via APIs and do not have the technical capability to use screen scraping - which is a more costly and less versatile access method.
What does PSR say?
The PSR removes the requirement to have a fallback interface that can be used to screen scrape. Instead, ASPSPs are required to maintain high quality APIs, and access by using the user interface to screen scrape is only allowed in exceptional circumstances, when the API is completely unavailable.
Some banks can apply for exemptions from having APIs at all, in some extremely limited cases e.g. the bank is very small and will not see open banking traffic.
The PSR also creates a `latency parity` by requiring the response time for dedicated interfaces to not be longer than that of the online banking interface. It also requires ASPSPs to provide slightly more detailed statistics than today on the functioning of their APIs on their own websites.
What does it mean for open banking?
These changes would mark the move to a more mature stage of open banking in Europe, one where the focus is on achieving excellent APIs.
The changes should lead to more market entry and a higher quality overall of open banking APIs.
It is important that the PSR defines clear minimum availability, performance, and support benchmarks for APIs. Parity with the user interface could lead to a downgrade in cases where the user interface performs poorly and lacks support. Exemptions from having APIs in place should also be limited to exceptional cases.
While PSD2 allows TPPs to connect to bank APIs in order to access payment account data or initiate payments via APIs, it did not set out detailed requirements for AIS or PIS functionality.
Instead, PSD2 applied the `parity principle`, according to which the levels of availability, performance, functionality, and support for open banking APIs are meant to be the same as for the online or mobile banking interfaces. This principle was meant to bring basic open banking functionality at the same level as online banking portals for initiating payments & accessing basic data.
While the principle has been a good starting point for open banking, the practical experience of the past several years has highlighted some of its shortcomings. Being interpreted differently has led to fragmentation and inconsistent implementation. For example, many banks do not return the name of the account holder to TPPs, making it more difficult to verify the identity of the payer. While the European Banking Authority (EBA) clarified that this is not sensitive information and should be provided in cases where the name is available in the online banking interface, many ASPSPs continue to withhold this piece of information.
The parity principle also results in a poor Open Bank experience in those cases where the consumer’s online banking experience is itself poor.
The PSR establishes a minimum functionality requirement for open banking payments. This baseline is to be independent of the parity principle.
In the case of PIS, baseline functionality will include being able to initiate single immediate payments, future-dated payments, payments to multiple beneficiaries, standing orders & direct debits. PISPs will also be able to retrieve and verify the account holder's name before initiating a payment.
The parity principle still exists in PSR: ASPSPs are required to provide at least the same level of information for both AIS and PIS as they make available to their customers directly via online banking portals, independently of the baseline.
In addition, PSR is significantly more prescriptive than PSD2 when it comes to prohibiting obstacles to the provision of open banking services and the EBA is tasked to create Regulatory Technical Standards that ensure security, safety of funds and data, fair competition, and user-friendliness.
Defining a baseline for payment initiation service, independently of the online banking portal, is an important and positive change which will lead to better and more consistent payment services. The baseline sets a floor for functionality. This, together with parity, should lead to better consumer outcomes.
There should however also be a baseline for account information services. Such an AIS baseline is omitted from the PSR. The sole reliance on parity means that the current fragmentation will remain contrary to the intention of the legislation and EBA clarification.
A baseline improves the consumer experience, which together with the welcome focus on prohibiting obstacles (a list which should be non-exhaustive) and tasking the EBA to include user-friendliness considerations in drafting technical standards, will improve user experience and help build consumer trust.
A long-standing complaint under PSD2 has been the lack of effective supervision and enforcement in respect of lax open banking implementation or disregard for the known requirements. This together with the fragmentation of implementation has resulted in requests for a suitably empowered centralised body to oversee the implementation of open banking standards across the EU.
There is no mandate in the PSR for a centralised body but there is a focus on increased supervision and a more prescriptive approach to the implementation of the Regulation generally, and of open banking rules specifically, with Article 48 setting out the role of competent authorities and the necessary action to be taken. We also welcome the mandate to convene industry meetings to help mitigate foreseeable problems and foster a collaborative open banking ecosystem.
The success of open banking in the UK, when compared to uptake in the EU, can be partly attributed to having a central authority that coordinated implementation - the Open Banking Implementation Entity (OBIE). A central authority whilst desirable is of course more challenging to introduce, as it would require consensus and budget. Even if an EU-level agreement was there, it would also place a significant funding burden on the market. The enhancements to supervision and enforcement are welcome, but national authorities will need to demonstrate they are active and willing to ensure the new open banking baseline and other PSR provisions are properly implemented.
It is also important that the EBA, through Regulatory Technical Standards to be drafted after the PSR is finalised, define clear good practice open banking SCA journeys which national authorities then ensure are implemented correctly.
At the foundation of PSD2’s open banking is the `prohibition of contracts`, meaning that banks are not allowed to charge TPPs to access their customer’s accounts with their consent. This has encouraged market entry and allowed open banking services to develop, with a low-cost base which translates into savings for merchants - which can be passed down to consumers. However, this model has created some confusion in the short term for incumbent banks, which saw open banking as a compliance exercise and did not see any monetisation opportunities.
The PSR maintains the PSD2 model of free access, rightly recognising that it improves competition, and a reversal of this position would severely disrupt the market.
At the same time, the Regulation acknowledges that ASPSPs and TPPs may establish contractual relationships with the possibility of compensation for the provision of open banking services “other than those required by this Regulation”, such as value-added services such as variable recurring payments (recital 56). This compensation needs to be aligned with the principles detailed in the Data Act and be fair and reasonable.
Maintaining the free to access model while at the same time defining a minimum baseline creates more opportunities for the industry. It ensures a clear understanding for all of what is compliance, making it easier to implement APIs with the same level of performance, support, and functionality across the EU. At the same time, it signals that everything beyond this level can be offered against cost. This will stimulate the creation of new, premium open banking services, resulting in a return on investment for ASPSPs.
Industry initiatives such as the SEPA Payment Account Access Scheme (SPAA) are already well underway to deliver the first generation of multilateral premium open banking services, including dynamic recurring payments (the equivalent of VRP in the UK).
It is early days in the journey to the Regulation being adopted, there will be lots of changes to the package, and we are still a few years away from these provisions becoming reality. It is imperative that we focus on proposals to remove barriers and lay the groundwork for well-functioning APIs to deliver a best-in-class user experience that promotes and builds trust in open banking and ultimately Open Finance services across the Union.
About Nilixa Devlukia
Nilixa is the Chair of the Open Finance Association and founder of Payments Solved, a regulatory consultancy advising on the regulatory framework for CBDC, crypto assets, open banking, and payment services both in the UK, EU and globally. Nilixa is a member of the ECB Digital Euro Market Advisory Group, the European Payment Systems Market Expert Group and the European Data Expert Group. Nilixa works with regulators, legislators and industry to drive changes in the financial services ecosystem for outcomes that support secure, transparent, and inclusive financial services. Nilixa is also a well-known public speaker and a contributing member of the Digital Euro Association and the Digital Pound Foundation.
About Andrei Cazacu
Andrei leads EU government affairs for TrueLayer, the open banking payments network. His previous experience includes EU and UK public policy, most recently with the US Chamber of Commerce affiliate in London, where he focused on UK-US financial regulatory dialogues, data protection, and cross-border data transfers.
Every day we send out a free e-mail with the most important headlines of the last 24 hours.
Subscribe now