RTS on SCA & CSC: Unravelling EBA’s view on screen scraping

  • Mounaim Cortet Vincent Jansen
  • ArticleAPIPSD2English contentOpen BankingXS2ACommunication InterfaceScreen ScrapingRTS

Let’s first start with explaining a couple of abbreviations. The European Banking Authority (EBA) published on 23 February its long-anticipated and much debated “Final Draft Regulatory Technical Standards (RTS) on Strong Customer Authentication (SCA) and common and secure communication (CSC)”. These RTS are the result of a challenging process where the EBA had to strike a balance between the PSD2 objectives of enhanced security of digital transactions, while stimulating competition and innovation by incumbents and new entrants.

Innopay’s PSD2 experts, Vincent Jansen (Partner) and Mounaim Cortet (Manager Strategy), recently shared their views on the RTS in a webinar which attracted broad industry attention. The webinar addressed the 1) strategically important balance between PSD2/RTS compliance and innovation potential of Account Servicing PSPs (AS-PSPs), 2) the key changes introduced in the Final Draft RTS and 3) the relevant business, operational, functional and technical implications for banks.

Several attendants of the webinar were interested to learn more about the RTS requirements regarding the communication interface and particularly on the future of “screen scraping” considering the final draft RTS. As such, in this article, we will further elaborate on the presented views regarding the communication interface and screen scraping for the purpose of third party provider (TPP) access to accounts (XS2A).

1. EBA's view on screen scraping

In the context of third party access to accounts, (screen/data/web) scraping today is one widely used tool to share/access online banking information with various third party applications for account information (e.g. Yodlee, Mint) and payment initiation (e.g. Sofort, Trustly, PPRO). Proponents of this approach argue it is a valuable supplement to direct data feeds that may be incomplete, out-of-date or difficult to access otherwise. However, the existing practice of screen scraping also raises (data protection) concerns, as there is no proper identification of the third party towards the bank. Put simply, the bank may not be able to determine if a legitimate third party or a malicious man in the middle accesses the account.

In the Final Draft RTS the EBA clarified, after consulting with the European Commission on the interpretation of PSD2, that accessing accounts through the existing practice of screen scraping (mistakenly referred to as ‘direct access’) will no longer be allowed, once the transitional period under PSD2 Art. 115 has elapsed and the RTS apply (i.e. November 2018 earliest). The argumentation of the EBA’s decision is based on several PSD2 provisions (cf. PSD2 Art. 66, 67, 97) that are related to:

  • TPP identification towards AS-PSPs
  • Secure communication by ASPSP and TPPs
  • Restrictions on TPPs in accessing information from designated payment accounts and associated payment transactions
  • Risks for the customer related to “not seeing what he/she signs”

In the Final Draft RTS the EBA clarified its requirements for the communication interface to counter the drawbacks of existing screen scraping practices and to satisfy the PSD2 requirements on TPP access to accounts. These requirements are elaborated in the section below.

2. EBA’ view on the communication interface

Article 27(1) of the Final Draft RTS states: “Account servicing payment service providers (AS-PSPs) that offer to a payer a payment account that is accessible online shall have in place at least one interface”.

Article 27(2) continues: “Account servicing payment service providers shall establish the interface(s) … by means of a dedicated interface or by allowing use … of the interface used for authentication and communication with the account servicing payment service provider’s payment services users.

The resulting two options available to AS-PSPs to meet the RTS requirement for the communication interface are described below and depicted in the visual:

  • Option 1 - Online banking: allow access for TPPs via the (existing) interface AS-PSPs provide to their customers for authentication and communication
  • Option 2 - Dedicated interface: most commonly referred to as “API” and is specifically established for the access of TPPs to payment accounts of customers held by AS-PSPs

Screen scraping1Figure 1: Two options for AS-PSPs to meet XS2A communication interface requirements under the RTS on SCA and CSC

The specific RTS requirements pertaining to these two options are defined in respectively article 27 and article 28 of the Final Draft RTS.

Both options will have to be supplemented by a means for PSP (both TPP and AS-PSP) identification. The EBA clarifies in article 29 of the Final Draft RTS that qualified eIDAS certificates for electronic seals or for website authentication shall be relied upon for this purpose.

It is our understanding that under the RTS screen scraping as implemented today (i.e. without proper identification) is outlawed. However, article 27(2) of the RTS explicitly states that using the existing web interface (thus “screen scraping”) is still allowed if the AS-PSP chooses to allow it. How this could work in a secure and RTS compliant manner is elaborated in the next section.

3. Innopay’s view on PSD2/RTS compliant communication interface

Under the RTS for SCA and CSC the AS-PSP still has two options to implement an interface that meets the requirements of XS2A. This is depicted in the visual below.

Screen scraping2Figure 2: High-level view on XS2A communication interface options for AS-PSPs

The first option in figure 2 depicts (high-level) how screen scraping can be set-up with TPP identification and authentication through what is commonly referred to as mutually authenticated Transport Layer Security (TLS). In this set-up, the AS-PSP hosts a dedicated entry point to its online banking where both client (TPP) and server (AS-PSP) authenticate during the TLS ‘handshake’ with an eIDAS qualified certificate for website authentication. This allows the AS-PSP to authenticate and authorise every TPP before granting XS2A and at the same time to reject all suspicious (man in the middle) traffic that is not properly authenticated.

For an API based dedicated interface the AS-PSP could implement the security mechanism of the first option. A more common option, shown as the second option in figure 2, is that only server side TLS is used for setting up a secure communication channel. In this example, for TPP identification purposes all requests to the server should be sealed (signed) with an eIDAS qualified electronic seal. This provides the AS-PSP with non-repudiation of TPP messages, providing for supporting evidence for the AS-PSP position when it comes to disputes. An AS-PSP could choose to add a signature to all response messages as well, providing more of a guarantee on payment result/information.

Note in option 2 as well that it is our understanding that the use of API keys is not allowed since this would contradict Article 29(1) of the Final Draft RTS that requires using eIDAS certificates for the purpose of identification. Also, it would introduce a significant entry barrier for TPPs, since obtaining API keys would require a TPP to register with ~4.500+ AS-PSPs individually across the EEA.

In conclusion

The key conclusion resulting from the Final Draft is that AS-PSPs are provided the option to leverage PSD2 XS2A compliance as a catalyst for developing their API strategy. However, AS-PSP do not need to put in place APIs to be compliant and to develop an API strategy if they do not want to.

Indeed, the EBA’s RTS requirements for the communication interface leave the decision for re-using online banking or putting in place a dedicated interface (API) at the discretion of the AS-PSPs. AS-PSPs need to carefully determine their strategic position (what do you want to be to your customers) and act accordingly and consistently.

Banks that are already exploring a strategy based on a more ‘open business model’, benefit from the drive towards openness triggered by PSD2. These banks are developing various services to offer to other service providers to develop more value for their mutual customers. PSD2 compliance is considered as yet another strategic investment that contributes to the establishment of a more open business model in banking. In our previous blog we have discussed four potential strategic options for banks to react to PSD2 XS2A.

Do not hesitate to reach out to us if you would like to discuss your PSD2/RTS compliance strategy or opportunities in Open Banking.

〈  Back to overview