Before entry into force of PSD2, this method was largely used by payment service providers to give users information about their account balances at various banks in order to expedite the process of evaluating their credit capacity. But delivery of these services required the providers to obtain access to information about users’ payment accounts. Anyone who sought to use such services thus had to provide login data to their bank account to an entirely alien entity, which would then enter the system and obtain the information by pretending to be the user.

Screen scraping thus essentially enabled payment service providers other than the user’s bank to obtain access to any data in the possession of the bank involving the specific customer. For example, these providers could determine the user’s exact earnings, his spending history, and indirectly even his purchasing preferences and life situation. This could lead to infringements of personal data, unwanted profiling, and threats associated with the cybersecurity of the payment service providers’ IT systems. (A similar position on the dangers of screen scraping has been consistently presented by the European Banking Federation.)

Primarily for these reasons, the screen scraping method has been found by the Polish Financial Supervision Authority (KNF) to be highly risky, or even illegal (e.g. KNF communiqué on the risk from providing another bank with login data to a bank account and Recommendation on the security of payment transactions). Consequently, the overwhelming majority of banks and other institutions in Poland operating payment accounts attempted to block the use of this method. This directly impacted the operations of many entities from the FinTech sector, which could no longer provide payment services based on screen scraping.

The situation changed with adoption of PSD2, which sets forth rules regulating the delivery of services requiring access to the user’s account. To this end, the directive introduced new types of payment services: payment initiation services, account information services, and the service of confirmation of the availability of funds in a payment account. The directive requires “account servicing payment service providers” (such as banks) to ensure access and prepare an interface for providers of these new payment services. This will allow providers of the new types of payment services to obtain data about users (to the extent necessary to deliver those services). The technical conditions for access by these entities are defined in Commission Delegated Regulation (EU) 2018/389 on regulatory technical standards for strong customer authentication and common and secure open standards of communication (known as RTS).

Screen scraping and the RTS Regulation

The RTS Regulation states that in order to ensure other payment service providers access to the data of their users, account servicing payment service providers may either create a dedicated application programming interface (API) or modify their existing interface (originally intended for authenticating and communicating with their own users). However, the modified user interface must enable these payment service providers to identify themselves to the provider operating the account. For purposes of identification, payment service providers are to rely on instruments established by the eIDAS Regulation (910/2014), i.e. qualified certificates for electronic seals and qualified certificates for website authentication.

Providing access to existing user interfaces offers a backdoor enabling the use of screen scraping in a new, modified form. Because the earlier method of screen scraping must be appropriately modified and equipped with new functions (the obligation for authentication of the provider), the new version allowed by the RTS Regulation is often referred to as “screen scraping plus.”

The additional requirements established for this method are intended to eliminate the defects that previously disqualified this method in the view of regulators. In particular, the current regulation should prevent an external service provider from pretending to be the account holder, ensure the security of the user’s data, and protect the user against unwanted profiling.

The selection between the two interface methods is left to the account servicing payment service providers. However, in its communiqué of 12 January 2018, KNF clearly indicated that from the point of view of ensuring effective oversight over the accessed data, the safer solution is to create a dedicated API. If the operator of the account opts to use an API, external payment service providers cannot demand access based on screen scraping plus.

But even when deciding on a dedicated API (which may be harder and more costly than adapting its existing interface), the account servicing payment service provider must additionally ensure appropriate measures for emergency access.

Screen scraping plus in contingency measures for dedicated API

Under the RTS Regulation, an account operator using a dedicated interface is required, in the event of unplanned unavailability or system breakdown, to promptly provide contingency measures which other providers may use during the outage. A contingency measure in this situation is an interface available to users for authenticating them and for communicating with the provider. For these purposes, it must be appropriately modified, including measures limiting access to data, identifying third parties, and registering the data they have accessed. This offers another backdoor for use of screen scraping plus.

The RTS Regulation does provide however for an exemption from the obligation to provide contingency measures, which can be obtained upon approval of the KNF Office (which will consult on the exemption with the European Banking Authority) and fulfilment of additional conditions for the dedicated interface, which primarily includes proper implementation and operation for a period of at least three months preceding submission of the application.

When must compliance with these requirements be achieved?

Although according to the KNF communiqué of 12 January 2018 the interface preferred by the Polish regulator for communication between payment service providers is a dedicated API (Polish work on preparation of common technological standards for this solution can be tracked here), under the applicable regulations it is also permissible to use the second method, based on a modified user interface. The question does arise, however, whether in its already announced oversight measures KNF will treat preferentially the communication solutions based on a dedicated API.

Key dates

Regardless of the choice of interface, the first obligations under the RTS Regulation were supposed to be fulfilled by 14 March 2019. By that date, account servicing payment service providers were to ensure that their interfaces complied with the communication standards published by European or international standards bodies, prepare the documentation for communication systems needed for other providers, and provide a summary of the documentation on their website. From that date, account servicing payment service providers should enable access to the community for testing of connections and functionalities, in order to allow other providers to examine the software and test the applications they use to deliver payment services.

The final date from which all the obligations under the RTS Regulation are to be enforced (e.g. the provisions on strong customer authentication) has been set for 14 September 2019. But KNF’s position is that the regulator expects account servicing payment service providers to have interfaces in place meeting the requirements of the RTS Regulation as soon as possible.

Adam Polanowski, Przemysław Gruchała