PSD2: EBA rejects Commission's SCA RTS amendments and screen scraping debate continues…

As many of you will know, there has been a great deal of debate and back and forth between the EBA and the European Commission since the EBA's original final draft RTS on strong customer authentication of February 2017.

The latest shot is the EBA's response to the Commission's proposed amendments of 24 May 2017.

In the EBA's response, it made it clear that these changes were not well received and, more specifically, that "the EBA disagrees with three of the four proposed amendments and is of the view that the suggested changes would negatively impact the fine trade-off previously found by the EBA in achieving the various competing objectives of the PSD2."

Key points in the EBA's response

1. The proposal for the audits to be performed by statutory auditors

The EBA proposes that the 'statutory audit' should be replaced with 'an audit performed by an auditor with expertise in IT security and payments and operationally independent within or from the payment service provider.'

The EBA provides the following reasons for this response:

  • The existing use practices and practices of statutory auditors vary greatly within the different EU Member States.
  • The usual purpose of statutory audits in EU regulation is very different to what is required under the RTS, so requesting a statutory audit may result in audits being performed by those who do not have the relevant qualifications and expertise.
  • By imposing this additional requirement on PSPs who are either currently exempt or not required to carry out statutory audits, the EBA argues that it would be disproportionate and very costly to smaller institutions.

2. An additional, standalone exemption to be added for specific types of corporate transactions

The EBA proposes that instead of adding a new exemption, a new category is added under the transaction risk analysis (TRA) exemption for specific payment transactions for payers that are not consumers, without a monetary threshold, provided that the fraud rate is equivalent to or below a specific reference fraud rate. All the other conditions set out in relation to the TRA exemption would apply.

This will be more difficult for corporates, because of the uneven transaction amounts. For instance, the amounts of corporate payments significantly vary, such that one instance of hacking could blow through the fraud rate.

3. Payment service providers to report the outcome of the monitoring and calculation of the fraud rate to the EBA

The EBA argues that while it agrees with the intention behind this amendment, it is concerned the current drafting suggests a new reporting requirement for PSPs, to the EBA as well as to NCAs and that this addition may overlap with other requirements for PSPs under PSD2.

The EBA believes that collecting data only as necessary to fulfil its requirements under Article 36 of the RTS is the more efficient and effective approach. Therefore, the EBA proposes that by reinstating the words 'upon request' and adding the words 'with prior notification to the relevant national authorities' the Commission's objective can be met and would deal with the EBA's concerns above.

4. AISPs and PISPs can access the ASPSP's customer interface as a fall-back in case the dedicated interface is not performing as required under the RTS

The point that has caused the most controversy in the RTS is whether screen scraping will be permitted under PSD2. When the EBA published its final draft report in February, it was clear that screen scraping would no longer be permitted after the RTS came into force. The EBA's position has always been that screen scraping is not compatible with the provisions of PSD2. This led to opposition from a section of TPPs, who claimed that banning screen scraping would threaten the viability of their business models should the bank's interface not operate correctly. As a result, some TPPs have subsequently lobbied hard for an amendment to the RTS.

The European Commission appeared to have come down on this side, by amending the RTS to allow screen scraping as a back-up mechanism in the event of failure of the main dedicated interface.

However, in the EBA's response it has hit back by stating that "the EBA is of the view that imposing such a fall-back requirement would go beyond the legal mandate given to the EBA under Article 97 PSD2…‘screen scraping’, in which the TPP impersonates the consumer and has access to all the consumer’s data, rather than only the data necessary to provide payment services, would not be compliant."

The EBA lists the following negative consequences of providing a fall-back option: cost increases, increased fragmentation compromising the development of application programming interfaces (APIs), competitive disadvantage for new entrants, a lack of improved technical reliability, incompatibility with PSD2’s security requirements, supervisory constraints, and unclear consumer understanding and consent.

Instead the EBA suggests including the following requirements in the RTS:


This response takes the wording back towards the final draft the EBA submitted in February with the addition of measures that the EBA believes will ensure that the information required by TPPs to provide their services is delivered in a reliable and continuous manner without compromising security.

However, the way that the EBA expresses how PSD2 should operate in practice may come as a surprise to many: "ASPSPs will be required by law to ensure that TPPs can access only the data necessary to provide a given service to their customers that TPPs can identify themselves in the process and that TPPs can communicate securely with each other."

The EBA statement seems to suggest that it is up to the ASPSPs to ensure that TPPs can only access the data necessary. Yet this is not consistent with what PSD2 says at Article 66(3)(g) and Article 67(2)(f) that it is up to the TPP to limit its use of the data and "not use, access or store any data for purposes other than for performing" the service. There is no specific corresponding obligation on the ASPSP to limit the data provided to the TPP in PSD2.

If the EBA position described above becomes the required approach, in practice that approach would seem to be incompatible with screen scraping.

It is also not clear what the EBA precisely means by the "ASPSPs will be required by law to ensure that…TPPs can communicate securely with each other." If it means ensure secure communication between different TPPs it is difficult to see why that should be connected with an ASPSP obligation. This is surely an error.

Conclusions and Next Steps

Clearly the debate on screen scraping is continuing and it illustrates just how difficult it is for the EBA and the Commission to balance the competing interests of the banks and the TPPs. TPPs' main concern is the viability of their business models and the banks' main concern is the security of their customer's data.

The result of the most recent amendments appears to be a compromise with an increase in the checks and balances on banks' APIs, without the burden of providing a screen scraping fall back option.

It is now for the Commission to make the final decision on the text of the RTS and to adopt the standards as a delegated Act in the Official Journal of the EU. During the adoption process, the EU Council and EU Parliament have a scrutiny right. Once the RTS have been published in the Official Journal, they will enter into force the following day and will apply 18 months after that date.

Achieving the right trade-off in the implementation of PSD2 is difficult, as the EBA itself admitted. While it is important to get this right, the continuing lack of certainty is not helpful for any of the players in the industry.

Back to main blog

Related blog posts

Loading data