The views expressed in this article are solely those of the author and should not be attributed to the European Payments Council.
We continue our series of interviews presenting the opinions of various stakeholders on the implementation of the revised Payment Services Directive (PSD2) with the interview of Arturo González Mac Dowell, from Eurobits Technologies and representing the European Third Party Providers (ETPPA) association. Learn more about how Third Party Providers’ (TPPs) view and are handling the market situation after the PSD2 implementation deadline.
Q. First, let’s talk about the implementation of the final Regulatory Technical Standards (RTS) for strong customer authentication (SCA) and common and secure communication (CSC) under PSD2 and their impact on the market. How would you summarise the current status and, in particular, the degree of harmony across the EU?
In our view PSD2 is not fully implemented in any of the EU member states and the parts that have been implemented to date have unfortunately brought diminished competition and customer inconvenience compared to what was available before. Luckily, the European authorities are cognisant of the complexity about the PSD2 implementation and are showing some flexibility vis-a-vis the market and several national competent authorities are putting pressure on Account Servicing Payment Service Provider (ASPSPs) to improve the access-to-account interfaces.
There are a number of reasons for the problems we have seen so far:
- Most banks have opted to publish dedicated interfaces, but none of them are working in a way compatible with TPP business continuity. Very few, if any, have unfortunately taken into account the recommendations that were crafted by the Application Programming Interface (API) Evaluation Group in 2018.
- SCA to access the Payment Service Users (PSU) interface has been implemented in a way that has caused business interruption to many TPPs. User experience is very bad, has not been documented for TPPs, a testing environment has not been provided to TPPs, and the introduction has been partial in many cases. This combined with first point above has caused a significant drop in conversion rates for TPPs.
- In some Member States the regulator and the ASPSPs are receptive to feedback from TPPs and there is clearly an intention to develop good APIs, but in others the regulator and ASPSPs seem to give a very low priority to TPP needs and consequently apply the bare minimum; this will not render good APIs.
- Card-not-present payments have in practical terms been exempted from applying strong customer authentication, creating an unlevel playing field where card payments are favoured vis-a-vis payment initiation services.
Degree of Harmony
The degree of harmony is low, to the extent that there are probably no two countries with an identical approach. There is a country where an extension period has been granted and made public (United Kingdom), a country with an extension period that has not been made public (France), a number of countries where no bank APIs have been exempted, but with unclear implications (Germany, Austria, Sweden). Countries where all or most APIs have been exempted but the exemptions not made public as to not force TPPs to use them (Italy, Spain, Portugal) and a variety of other combinations.
Q. How would you describe customer experience so far after implementation of the RTS?
The customer experience has worsened significantly since September 14. In the first place customers are now required to go through SCA in situations that make no sense, such as when you search for a transaction that is older than ninety days or when you want to see your account balance before making a payment. Then, the uncoordinated introduction of SCA to access the PSU interface has generated panic situations when customers receive SMS from their bank in the middle of the night due to an SCA being generated by access through an Account Information Service Provider (AISP). Furthermore, redirection to the ASPSP creates a much worse user experience and takes away the possibility for TPPs to offer a good consumer-facing interfaces or even the ability to provide some PIS use cases. And finally, APIs do not ensure that TPPs have the information they need to offer a good service, also in the case of payment initiation services vis-a-vis the merchant.
Q. Have the key objectives of PSD2 been achieved and if not, what would be the remaining challenges?
A key objective of PSD2 was to increase competition and transparency in financial services through innovation, subject to an increased level of security. Two objectives which are not easy to reconcile.
However, we can say that in the current situation, security has only been increased partially, as there has been a supervisory flexibility granted to card-not-present card payments which is precisely the payments space where the fraud rates were the highest by far. Whilst competition has been diminished, as TPPs, which are typically smaller companies, have been forced to go through a long and expensive licensing process. They have been forced to spend a very significant amount of money and resources to onboard APIs that are not working. They have been forced to deal with ambiguous regulation incurring in tremendous uncertainty costs with heterogeneous implementation throughout the different member states. Lastly and most significantly, they have not been given the same supervisory flexibility as the incumbent payment systems, which creates a competitive asymmetry that is impossible to reconcile with the objectives of PSD2. The bottom line is the services provided by TPPs have deteriorated since September 14. However, the situation would improve significantly, if the limited outstanding issues where solved, as suggested by Vice-President V. Dombrovskis.
Q. How do you see the future evolution of APIs both in the context of and beyond PSD2? What are likely future developments to address e.g. further standardisation or business needs?
TPPs have many genuine reasons for preferring APIs over accessing the user interfaces directly, because they are much more efficient. We believe that APIs will evolve and mature to solve actual business needs of end users. At the minimum, they should be able to provide enough information and functionality as to guarantee that there is no deterioration relative to what was available before PSD2. Then they should probably evolve to include non-payments information and valued added services that are not available to the end user through the PSU interface. In terms of standardization, it is up to the market to decide what is the correct approach, but the part that is more likely to be standardized first is the security layer between the TPP and the ASPSP.
Q. Finally, would you already see a need for revising the RTS and if so, why?
Yes, the outstanding issues are well known and all of them have been addressed in the API Evaluation Group recommendations. These recommendations were crafted after a very significant amount of work put in by all sides of the market and lays out “what good looks like” as it comes to APIs. If these recommendations are not implemented, obstacles to the provision of PIS and AIS are erected. The RTS should be amended accordingly. The key outstanding issues are the following:
- Ninety day renewal SCA, when required, should be able to be performed by AISPs without the need for bilateral arrangements
- SCA to access transactions older than ninety days should be eliminated. This is a requirement that the majority of stakeholders do not see as adequate, so it should be relatively easy to have it changed.
- Full clarity on something quite obvious - that redirection is an obstacle for TPPs that want to offer its own user interface (as of now some National Competition Authorities (NCAs) and ASPSPs seem to dispute this).
- Clarify further what is a payment account and what is a related payment transaction
- Information pushed to AISPs in real time, to ensure information is available to all parties at the same time and to reduce the computing burden to both parties
- In general, use a clearer language that is not so open to interpretation
If you would like to comment on this article, please identify yourself with your first and last name. Your name will appear next to your comment. Email addresses will not be published. Please note that by accessing or contributing to the discussion you agree to abide by the EPC website conditions of use.