A year ago I wrote a couple of LinkedIn blog posts (here and here) with my opinion that PSD2 access to account (XS2A) was not just a story about publishing a couple of APIs, but was much closer to setting up a scheme. I, and the EBA themselves, warned that the EBA’s “Regulatory Technical Standards” would be Regulatory but would not be Technical and would not be Standards.
I also suggested that there were many things to be thought about beyond the API specifications and that a collaborative approach with some of the characteristics that we see in schemes would be needed.
A year on, there are still massive opportunities to be found in Open Banking, but also large risks that the intentions will be frustrated by fragmentation and lack of clarity. Keeping up with the various discussions can be a full-time job. This article tries to give a snapshot of the state of play.
** Warning – long and fairly dense content to follow. **
This is a snapshot based on the main lines that I have personally observed and simplified to fit into a couple of thousand words. Feel free to add additional thoughts as comments.
Regulatory Activity since April 2016
17th May The UK CMA Report on Open Banking
While not strictly relevant to PSD2, the UK regulator “the Competition and Markets Authority” produced a report that stated: We have provisionally decided to: Make an Order requiring that RBSG, LBG, Barclays, HSBCG, Nationwide, Santander, Danske, BoI and AIBG adopt and maintain common API standards through which they will share data with other providers and third parties.
The CMA mandate set a January 2018 delivery deadline, and gave the UK community the additional challenge of creating a centralised ‘Implementation Entity’ to define API standards, directories, rules, etc with a scope that was similar but different to PSD2. The intention was presumably that this would be a helpful addition to PSD2, rather than a competing initiative, although I think that the banks in the middle of trying to reconcile all of this into one project are having a lot of fun with the challenges. [This is British English for ‘tearing their hair out and crying at their desks’].
12th August Publication of RTS for Consultation
A key event was the publication of the Draft Regulatory Technical Standards on Strong Custom Authentication and common and secure communication, (henceforth “the RTS”). Link
There were strong reactions provoked by the proposed rules concerning “Strong Customer Authentication” (SCA) and their exemptions. SCA is not (only) an XS2A issue, but defines minimum security requirements for all payments – with some exemptions. The proposed SCA rules were criticised for being too strict, and not strict enough, showing that the EBA had achieved their aim of making everybody “equally unhappy”.
For XS2A, it was now clearly written, that AS PSPs (banks) had to provide a dedicated communications interface, with certain characteristics, using E-IDAS certificates for identification. What was not clear was whether TPPs had to use this dedicated communications interface; whether “screen scraping” was still allowed (the definition of which we can argue about another day); and what is meant by “Direct” or “Indirect” access – terms that are mentioned in the recitals of PSD2, but not in the main articles and never defined.
While they were not always clear and not universally agreed, I have to say that the EBA made a good an honest effort at writing some legislative text that was well structured and designed to be understood and implemented by somebody, even if they inherited some of the inconsistencies that came from the primary text (PSD2 itself).
During the consultation phase the EBA received more comments on the RTS than any other EBA consultation ever in the history of the universe. Perhaps because, they had written something that was (relatively) understandable, and perhaps in attempting to clarify some of the inconsistencies of PSD2 they were criticised in going a bit too close to touching the primary legislation. But as this was a consultation, there was always room for improvement in the second version.
February 23rd 2017. Draft RTS published.
Describing the RTS it is probably best to use their own words from the press release:
Following 18 months of intensive policy development work and an unprecedentedly wide number of stakeholders’ views and input, these final draft RTS are the result of difficult trade-offs between the various, at times competing, objectives of the PSD2, such as enhancing security, facilitating customer convenience, ensuring technology and business-model neutrality, contributing to the integration of the European payment markets, protecting consumers, facilitating innovation, and enhancing competition through new payment initiation and account information services.
The RTS press release also explicitly mentioned: “the-interface-that-had-not-been- named” (i.e. screen scraping).
[…]the EBA has decided to maintain the obligation for the ASPSPs to offer at least one interface for AISPs and PISPs to access payment account information. This is linked to the PSD2 no longer allowing the existing practice of third party access without identification (at times referred to as ‘screen scraping’ or, mistakenly, as ‘direct access’) once the transition period provided for in PSD2 has elapsed and the RTS applies.
It was helpful to put it out there, although I think we still have a way to go in our collective journey in understanding what is and what isn’t screen scraping, what is and isn’t allowed in this ‘technology neutral’ technical standards. The nature of the “dedicated interface” is hot topic.
The RTS state that TPP identification will happen using eIDAS certificates and understanding Electronic IDentity And Signature regulation becomes very relevant and creates some interesting links between member state competent authorities (who authorise TPPs to do business) and the member state supervisory bodies (who regulate those who issue the certificates on which we will relay to identify the TPP).
Other EBA RTS for PSD2
I should also mention that the EBA have 9 different mandates for Guidelines and RTS relevant to PSD2. Two of them which are being followed with interest at the moment are:
- Passporting: How does a TPP get to do business outside their country of registration, and how do the different competent authorities organise themselves to make this happen.
- Private Indemnity Insurance: With no Insurance cover, there are no TPPs allowed to do business. How to stipulate the minimum amount of insurance?
Other regulatory activities
In the end, the Parliament has the final say, on what will and what will not go forward and whether the draft RTS will become the final RTS. Currently, the new RTS is being scrutinised, for example at their 27th March scrutiny session.
At the same time, National legislations are “transposing” the PSD2 itself into national law, and various groups are tracking these transpositions to see if differences will emerge at the national level, for example, on the 13th April, the British Financial Conduct Authority (FCA) published their approach document for implementation of PSD2, which weighs in at 277 pages.
Finally, I suspect that there is not sufficient attention paid to the General Data Protection Regulation (GDPR) which comes into force in May 2018, where both AS PSPs and TPPs respect the privacy in new ways with new definitions of consent and new rights and obligations of those holding and using data.
Over this time various players and groups had been getting together to try and solve the perceived problems of PSD2. There is a brief listing below, but the key point is that generally these groups are aware of each other and trying to avoid duplication of effort and fragmentation.
- Open Forum for Open Banking: Euro Banking Association initiated, although run independently. A place to come and discuss the initiatives.
- The Berlin Group: Creating standards for how messages would look.
- ISO: Working on standards for REST-based APIs using ISO20022 building blocks.
- CAPS: Working on standardising PSD2 access to account.
- PRETA: Working on a compliance-driven solution to meet the PSD2’s access-to-account provisions with a central directory and related services.
Finally, these initiatives do not replace the layer of processors and vendors who will deliver API platform, integration platforms, consent management systems, authentication systems, and maybe aggregation services for TPPs and Banks.
In nearly every case, every national association, payments forum has some sort of PSD2 workstream, that is assessing what is the impact within that country, how it fits in with other local initiatives and legislation, and whether to organise a national response, to make sure that they as a country are OK and compliant, even if the rest of Europe doesn’t quite get there.
National engagement is unavoidable, but people in the national groups are often trying to work with the pan-European groups and so information flows backwards and forwards, and there is also a stated willingness to work together.
There is clearly a risk that national discussions will lead to national responses that will fragment instead of uniting payments across Europe, but I think generally this will not be the case, although differences due to national transposition may bring some nasty surprises.
The Euro Retail Payment Board (ERPB)
The ERPB, is a stakeholder body made up of bodies representing consumers, merchants, banks, other financial players and regulators. It has no legislative power but meets every six months to review, assess, raise requirements problems, and generally give everyone a voice in Europe’s payments business. Link.
28th November ERPB Meeting and the ERPB PIS Working Group
The ERPB – at its meeting on the 28th of November highlighted various stakeholder concerns around interoperability and fragmentation decided to create a working group to cover the topic of payment initiation services.
The ERPB gave a mandate to the new working group to “prepare a report for the June 2017 meeting covering the technical, operational and business requirements needed for the provision of efficient and integrated PIS services.”
PRETA, due to its interest and expertise in the matter, was asked to join this ERPB working group. Details of ERPB initiative can be found here under the heading of the Sixth ERPB meeting 28th November 2016.
Timing Going Forward for PSD2 and RTS
PSD2 must be “transposed” into national law at least by January 2018. Countries are not allowed to be late, but a number were late when PSD1 was implemented.
The European Commission has described the timetable a couple of times in public fora, for example at the “Open Forum on Open Banking”, hosted by the Euro Banking Association. To summarize their position:
- From end February, the EC has three months to scrutinise the RTS and then to send them to Parliament (so by end May),
- Parliament then has three months before approving the RTS. Allowing for the summer period, this is more likely to be September than August.
- After approval, they “Enter into Force” with a delay of 18 months. So March/April 2019.
Note that this is the smooth path, the EC and then the Parliament agree with the RTS. There is a space for requests for change, and even complete rejection, which can extend this timeline.
Mind the Gap. Fuzzy Logic.
Those of you who are still with me will be wondering what will happen given that PSD2 (from January 2018) requires that an AS PSP will “communicate securely with payment initiation service providers in accordance with [The RTS]” when the RTS are not in place until Q2 2019.
There also some (but not all) national transpositions that are provisionally interpreting that the identification requirements on AS PSPs and TPPs will enter into force in January 2018, even though the communication requirements will follow RTS timelines.
It was the ancient Greeks who enjoyed pondering paradoxes like – what happens when an unstoppable force hits an immovable object. I don’t think they found an answer, either. We will see.
While this article highlights a lot of problems and uncertainties, I do believe that in the last months quite a lot of progress has been made. The ASPSPs seem aligned on a REST-based API methodology, using ISO20022 components. We understand what the eIDAS requirements are, and while there are some technical issues to be ironed out, I presume that they will be ironed out. The TPP side and the AS PSP is talking with each other through the ERPB work – even if they are not always agreeing. The regulators need to give certainty on the RTS, either by changing something, or by making it clear that the texts so far published are all the help the industry is going to get, and letting them get on with building solution.
A year ago I said, “Divided we fall, united we stand”. I still believe that aligning TPPs and AS PSPs around a common directory (or directories) will be the key to creating not just compliance, but avoiding fragmentation. We have enough elements in our hands to get moving now, and I look forward to seeing what the next few months will bring.