On Monday 27 March 2017 the European Parliament’s Committee on Economic and Monetary Affairs held a Scrutiny Session on the Final Report on Draft Regulatory Technical Standards on Strong Customer Authentication and common and secure communication under Article 98 of Directive 2015/2366 (PSD2). The scrutiny session is an opportunity for Members of the European Parliament (MEPS) to make questions to the representatives of the European Banking Authority (EBA), the European Commission (EC) and the European Central Bank (ECB) regarding the reasoning behind their decisions and to assess whether or not the text complies with PSD 2. 

If you are interested in watching the full debate click here. Although I feel like I should warn you that this will not be the most exciting thing that you’ll ever watch.

After the initial formalities, Andrea Enria, the Chairperson of the EBA delivered his Introductory statement where he addressed the topics of Technological neutrality, Exemptions from Strong Customer Authentication and Access to Payment Accounts.

What I propose to do in this article, is to analyze in greater detail Mr. Enria's words on access to payment accounts and why I believe his reasoning is flawed and based on misconceptions and facts that are not adjusted to reality. I’ll continue to scrutinise Mr Enria comments in upcoming articles.

For the sake of readability, I will reproduce his words in italic followed by my comments.

Mr. Enria on Access to payment accounts

As to the access to payment accounts, you raised concerns with regards to the communication between account servicing payment service providers (ASPSPs, mostly banks), account information service providers (AISPs) and payment initiation service providers (PISPs), and so did several respondents to our Consultation Paper.

Having consulted with the European Commission on the interpretation of the Directive, the EBA has come to the conclusion that once the transition period under the PSD2 has elapsed and the RTS applies, the PSD2 no longer allows the current practice of third party access often referred to as ‘screen scraping’.

I would call the reader’s attention to this brilliant article by Ralf Ohlhausen, where he explains why we should use the term “permitted automated direct access” instead of "screen scraping".

This interpretation is based on a number of requirements in PSD2 that are applicable to PISPs and AISPs, so allow me to make a few legal references. For example, under Articles 66 and 67 of PSD2, account information and payment initiation service providers are required:

• to identify themselves, This is already possible in a number of ways under direct access. And it is so using a number of proven standard technologies. The most appropriate one probably being mutual certificate authentication. That is, the AISP identifies itself to the bank's server that provides the customer facing interface with the digital certificate he will be required to obtain to operate as an AISP. By the way, this is exactly the same way the AISP will identify himself towards the bank using a dedicated interface. This one was easy.
• to communicate securely; The communication between two servers that mutually identify themselves with a digital certificate is as secure as it gets. Furthermore, again, it will be exactly the same security that will be used to identify servers in a "dedicated interface" scenario. This one was even easier.
• NOT to “use, access or store any data for purposes other than for performing the [service] explicitly requested by the payment service user access”. Mr. Enria is right on this one. This is something direct access cannot guarantee. But then again, neither can a dedicated interface. What the AISP does with the data after it has been obtained is out of the scope of a communications interface, whether it is a dedicated interface one or not. This is why PSD 2 requires that AISP have a license to operate and that they are dully supervised. This is the only way to ensure AISP (and any other players, ASPSP included) deal with the data as they are supposed to and as it is expected by the consumers. And if they fail to do so, they will be inspected and lose their license.

In addition, Article 115 of PSD2 provides that these providers have the right to continue to access payment accounts in the way they currently do only for a transitional period between the application date of PSD2 and the application date of the RTS.

I think I might have a reading comprehension problem on this one, but lets see what Article 115 of PSD2 says in that respect:

"5.   Member States shall not forbid legal persons that have performed in their territories, before 12 January 2016, activities of payment initiation service providers and account information service providers within the meaning of this Directive, to continue to perform the same activities in their territories during the transitional period referred to in paragraphs 2 and 4 in accordance with the currently applicable regulatory framework."

Article 115 says the current way of doing things will be protected during the transition period as long as it is in accordance to current regulation. It says nothing about what happens to the current way of doing things after the transition period is over. Actually if Mr. Enria were right, dedicated interfaces could not be used after the transition period, because some banks have this dedicated interfaces already, at least some created them for us and we are using them.

The aggregate effect of these legal provisions leads to the only plausible interpretation of the Directive that the current way of account access will no longer be possible once our RTS apply.

I must admit I might not be very strong at logic, but this is as close to a logical fallacy as I can imagine.

The sole legal avenue available for the EBA that would ensure that banks share data with other providers without the need for a contract was, therefore, to require ASPSPs to offer at least one interface for AISPs and PISPs to access payment account information.

The RTS furthermore provides that ASPSPs may either develop a new dedicated interface or allow the use of an adapted version of the existing interface they are using for the identification and communication with their own customers. In both cases, payment initiation and account information services providers would be able to access the data they need to service their customers.

This is the best part of Mr. Enria's Introductory Statement. He is basically saying that either the directive allows a bank to provide an interface that is in breach of the directive... or an adapted version of the existing interface they are using for the identification and communication with their own customers is compliant with the directive. But it can't be both things at the same time. Which is good news, because it is in sync with what we are proposing.

What we are proposing to the commission is that banks modify their existing interface to admit AISP certificates as a means to identify AISP. In addition, they can develop an optional alternative interface. If this optional alternative interface works well and delivers the same level of information as the customer facing interface, it will be the interface of choice for any AISP that does not like to waste their time and effort. But TPPs need to have choice and not to be at the mercy of the banks. This is exactly what we currently do with banks with which we have reached an agreement on such an interface.

However, in order to address the legitimate concerns raised with us in respect of the smooth and continued access to the dedicated interface, we have added a requirement to the Technical Standards that banks have to provide the same level of availability and performance as the interface offered to, and used by, their own customers, with the same level of contingency measures in case of unplanned unavailability; Who is measuring all this? You guessed it. The banks. and to open the interfaces ahead of release so as to enable PISPs and AISPs to test the interfaces. We have also clarified that the ASPSPs have the obligation to provide an immediate confirmation to the PISP whether funds were available to ensure the PISP is able to process the payment.

All this looks nice in writting, but, but there is a significant difference between a bank's attitude towards the interface offered to their own customers and the dedicated interface. It is in the interest of the banks to provide a good service to their customers, it is not necesarily in their interest to offer a good service to their competitors. In other words banks will have a disincentive to to this well.

This ensures that PISPs and AISPs have access to, and receive, the same information as they currently do. But unlike current practice, they will do so securely and in a way that can be harmonised between providers, to facilitate the key objective of the PSD2 of bringing about an integrated and competitive payments market in the EU. It is also the utmost we were legally able to do, given that the EBA is limited by the wording of the mandate, which does not allow us to consider other options, such as defining details of a fall back option should the dedicated interface fail to work.

So basically what Mr. Enria is saying is that PSD2 leaves no other option than to leave up to the banks the quality of the information received by the TPPs. The same banks that are currently trying to make access to accounts difficult by using anti-aggregation measures. And that the way AISP have been working for more than a decade without a single security breach has to be forbiden. Hey, wasn't the objective of PSD2 to foster innovation and bring competion and transparency to financial services? By giving more control to the banks and forbiding the way AISPs currently operate? I don't believe PSD2 is that badly written.

Stay tuned for more.