A heated debate has been going on for years as to whether account information services providers (AISP) and payment initiation services providers (PISP) and card based payment instrument issuers (CBPII) may use screen scraping as a means of accessing the payment user’s account at their payment account service provider (ASPSP). With PSD2 and more specifically, the Regulatory Technical Standards on Strong Customer Authentication and Common and Secure Communication (RTS on SCA and CSC), the demise of screen scraping seemed to be here. However, recently the EBA published Guidelines on the exemption from the contingency mechanism under Art. 33 (6) RTS on SCA & CSC, which allow screen scraping as a fallback option.
What’s Screen Scraping?
Screen Scraping is a method to make automated use of a website by impersonating a web browser to perform tasks on that website that are usually manually performed by a user. It allows a different user interface for the user than the original website. One example in the context of PSD2 is that a PISP may use the credentials provided by a payment user to automatically access the ASPSP’s banking system by “pretending” to be the user in order to initiate a payment from the user’s account.
Desired end state: dedicated interface
If and when an ASPSP is providing a dedicated interface to AISPs, PISPs and CBPIIs, it may limit access to its account to the dedicated interface only if it is able to prove to have met all regulatory requirements. If these requirements are not met, the ASPSP has to allow screen scraping as a fallback option.
There is one notable difference to the screen scraping as described above, though. AISPs, PISPs and CBPIIs need to identify themselves vis-à-vis the ASPSP, they may not impersonate the payment user but need to employ eIDAS compliant certificates to identify themselves. For this purpose, the EBA has issued some more guidance on the use of eIDAS certificates in the context of PSD2.
Exemption from the fallback option
If an ASPSP does not want to allow screen scraping as a fallback option, it needs to meet all requirements pursuant to Article 33 (6) RTS on SCA and CSC.
Firstly, this means defining and keeping transparent key performance indicators and service levels. The Guidelines now issued by the EBA set out some of the key performance indicators like uptimes, downtimes, response times, and out of hours support and ways to calculate them.
Secondly, this means that the ASPSP has to stress test its dedicated interface. The stress testing needs to include access by multiple AISPs, PISPs and CBPIIs, as well as high volumes of requests and high volumes of data. While the RTS on SCA and CSC generally do not take effect prior to 14 September 2019, the requirement to carry out testing for at least 6 months effectively moves the deadline for ASPSPs to 14 March 2019 to have their dedicated interface ready.
Thirdly, the ASPSP needs to prove wide usage of the interface for a period of 3 months. This means that the ASPSP should offer its interface to AISPs, PISPs and CBPIIs by means of appropriate communication such as website, social media, conferences etc. However, if in a certain market there are no or only few AISPs, PISPs or CBPIIs active, the widely used requirement may be reduced considerably.
Finally, the ASPSP is required to offer and report on problem resolution mechanisms to deal with any problems reported by AISPs, PISPs and CBPIIs and to prove that it has already resolved issues during the testing phase.
Irrespective of whether an ASPSP only offers a dedicated interface or not, it has to prove to its competent regulator that the method of authentication (irrespective of interface, redirection, embedded or other) does not pose an obstacle to the payment service user’s choice to employ the services of a AISP, PISP or CBPII. This means inter alia that APSPS may not request additional authorizations nor check the consent given by the payment service user.
All in all, this seems to be a green light for AISPs, PISPs and CBPIIs but it remains to be seen if and when such services will pick up and become more popular with payment service users because so far there has been a lot of theory around open banking but only very few practical applications.
Cover picture: Copyright © fotolia /trendobjects