The myth: In September 2019, once PSD2's SCA & CSC RTS enters into force screen scraping will be forbidden. 

The myth on steroids: Furthermore, it will not only be forbidden to access payment accounts via screen scraping, but also to access non payment accounts.

I have heard this many, many times lately and think it requires some serious debunking. First, why do people think this? In some cases it is just due to hearsay, but in others it is due to a misinterpretation of a paragraph in the EBA guidelines, which on page 74 (Ref 89) & page 111 (Ref 160) says the following:

As regards the current methods of access by screen scraping, the EBA has clarified in its final report on the RTS (EBA/RTS/2017/02) and in the EBA Opinion on the transition from PSD1 to PSD2 (EBA/Op/2017/16) that the existing practice of third-parties accessing the PSU data via the customer interface, and without identification, will no longer be allowed once the RTS apply.

Do note the bold part of the above paragraph. What that implies is, that before doing screen scraping, TPPs will have to identify themselves towards the ASPSP in a way recognized by PSD2 and lower level legislation.

First lets debunk the steroid part. PSD2 is only about payment accounts. Nothing in PSD2 regulates non payment accounts including access.

Now lets see what the legislation says about this matter. The need for TPPs to identify themselves towards the ASPSP for the performance of AIS and PIS is ruled in articles 66 (for PIS) and 67 (for AIS) of PSD2.

Article 66 Rules on access to payment account in the case of payment initiation services

3.   The payment initiation service provider shall:

(d) every time a payment is initiated, identify itself towards the account servicing payment service provider of the payer and communicate with the account servicing payment service provider, the payer and the payee in a secure way, in accordance with point (d) of Article 98(1);

Article 67 Rules on access to and use of payment account information in the case of account information services

2.   The account information service provider shall:

(c) for each communication session, identify itself towards the account servicing payment service provider(s) of the payment service user and securely communicate with the account servicing payment service provider(s) and the payment service user, in accordance with point (d) of Article 98(1);

OK, so level 1 legislation requires TPPs to identify themselves towards the ASPSP before performing their services. Furthermore, the SCA & CSC RTS indicates the obligation for PSD2 access interfaces to allow TPPs to identify themselves towards the interface before performing PIS and AIS operations. This is covered in article 30 which says the following about identification:

Article 30 General obligations for access interfaces

1.   Account servicing payment service providers that offer to a payer a payment account that is accessible online shall have in place at least one interface which meets each of the following requirements:

(a) account information service providers, payment initiation service providers and payment service providers issuing card-based payment instruments are able to identify themselves towards the account servicing payment service provider;

So, beside the obligation for the TPPs to identify themselves towards the ASPSP, there is an obligation for the ASPSP to make their PSD2 interfaces suitable for TPP identification. But, how should TPPs identity themselves towards an ASPSP? This is covered in in article 34 of the RTS and it is via the use of qualified eIDAS certificates.

Article 34 Certificates

1.   For the purpose of identification, as referred to in Article 30(1)(a), payment service providers shall rely on qualified certificates for electronic seals as referred to in Article 3(30) of Regulation (EU) No 910/2014 or for website authentication as referred to in Article 3(39) of that Regulation.

The last issue is, are there ways for TPPs to identify themselves towards an ASPSP before accessing a user interface, be it for screen scraping the electronic banking or other means of accessing either the electronic banking or mobile apps? I guess there are various ways of doing that, but a commonly referred to, and used method is the signature of HTTP headers. A draft standard for doing so can be found here. This draft standard is the basis used by the Berlin Group standard to sign messages in their nextgenPSD2 access to accounts framework, as well as in other PSD2 specifications.

It has to be noted, that for the above method to be legally compliant, it is required that QSeal certificates are used instead of QWACS. This is covered in the eIDAS and TPP Identification (PSD2) document that I co-wrote with some of my colleagues from the API Evaluation Group. And which was further elaborated by the EBA in their EBA opinion on the use of eIDAS certificates.

Then let's see how all this adds up. 

1. TPPs are obligued by PSD2 (level 1 legislation) to identify themselves towards an ASPSP before performing PIS or AIS.
2. ASPSPs are obligued by the SCA & CSC RTS to make their PSD2 interfaces in such a way that TPPs can identify themselves towards them.
3. The same SCA & CSC RTS obligues TPPs to do so via the use of eIDAS qualified certificates.
4. There are technical ways for TPPs to identify themselves towards the ASPSP before doing screen scraping without any collaboration from the ASPSP.
5. In the particular case of screen scraping, that identification has to be performed using Qseal certificates as the means of identification is signing messages, which is the purpose of QSeal certficates and not the purpose of QWAC certificates. By the way, what an unfortunate way of naming something that is intended to build trust.

Lastly, there are no obligations in any part of the legislation for ASPSPs to identify TPPs. So the HTTP headers signature mechanism does not require any collaboration from the ASPSP whatsoever. Neither from a technical point of view, nor from a legal perspective.