Screen Scraping

Both TPPs and ASPSPs have choices during their implementation of PSD2. Depending on circumstances, an ASPSP may have to support both an API route and a “screen-scraping” route for TPPs to access customer account data or initiate payments.  Konsentus enables ASPSPs to carry out essential identity and regulatory checks on TPPs in both cases.

TPPs must identify themselves to the ASPSP in the same way regardless of whether they are using the API or “screen-scraping” via the user interface.

ASPSPs and TPPs must also ensure that, when exchanging data by means of the internet, secure encryption is applied between the communicating parties throughout the respective communication session in order to safeguard the confidentiality and the integrity of the data.

eIDAS web authentication certificates will be used to identify the communicating parties and establish a TLS session between them.

The required strong customer authentication enables the ASPSP to validate the account holder’s intention, but does not validate the regulatory status of the TPP.

The TPP must identify themselves to the FI and this must be the same as the TPP would use via the API.

Screen-scraping services will not use eIDAS certificates, meaning the FI will not be able to automatically verify the identity of the TPP.  This presents a problem to the FI and a potential risk.

The required strong customer authentication will enable the FI to validate the account holder’s intention, but will not validate the regulatory status of the TPP.

Konsentus will receive (from the FI) the identity supplied by the TPP.

The Konsentus platform provides the following services:

  • Verify the TPPs regulated status, every time the TPP accesses the PSU account data, on the EBA Electronic Central Register repository and National Competent Authority daily bulletins.
  • Verify the TPP against the FI’s relevant scheme (e.g. UK Open Banking, STET etc.) to determine the TPP’s status, where appropriate.
  • Issue a secure access token to the TPP, via the FI, for access to the PSUs account(s) once verification and checking are satisfactorily completed.
  • Verify that the access token presented to access the PSUs account is valid and holds the correct “explicit consents” granted by the PSU.
  • Check the PSU has not revoked the TPPs access through the FI’s online banking application.
  • Reissue access tokens to TPPs when existing tokens have expired.
  • Konsentus will return the results to the FI.

 “Screen scraping” is allowed, but…

  1. “Screen scraping” may be the primary interface – TPPs may wish to utilise “screen scraping” or ASPSPs may want to avoid investing in an API. However, the TPP must identify themselves:
    • The regulations impose a requirement that TPPs identify themselves to ASPSPs when carrying out “screen scraping” and they must do this by using the exact same identification mechanism, as the one required for a dedicated API interface (as noted in Article 30.1(a)).
  1. “Screen scraping” may be used as the fall-back mechanism – An ASPSP has to provide a contingency route in the event that the ASPSP’s API is temporarily unavailable. The ASPSP does not have to provide a “screen scraping” contingency mechanism if:
    • The API meets the conditions (as noted in Article 30.6) and the ASPSP has been granted an exemption, from the obligation to set up the contingency mechanism, by their National Competent Authority.

The following extracts from the PSD2 Regulatory Technical Specification issued by the European Banking Authority are the source data for the  key points outlined above.  The points in bold are the key aspects to note:

(27) To improve user confidence and ensure strong customer authentication, the use of electronic identification means and trust services as set out in Regulation (EU) No 910/2014 (eIDAS) of the European Parliament and of the Council3 should be taken into account, in particular with regard to notified electronic identification schemes

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 (TPPs) are able to identify themselves towards the account servicing payment service provider; (b) account information service providers are able to communicate securely to request and receive information on one or more designated payment accounts and associated payment transactions;  (c) payment initiation service providers are able to communicate securely to initiate a payment order from the payer’s payment account and receive all information on the initiation of the payment transaction and all information accessible to the account servicing payment service providers regarding the execution of the payment transaction.

Article 31 Access interface options Account servicing payment service providers shall establish the interface(s) referred to in Article 30 by means of a dedicated interface or by allowing the use by the payment service providers referred to in Article 30(1) of the interfaces used for authentication and communication with the account servicing payment service provider’s payment services users.

Article 33 Contingency measures for a dedicated interface 1. Account servicing payment service providers shall include, in the design of the dedicated interface, a strategy and plans for contingency measures for the event that the interface does not perform in compliance with Article 32, that there is unplanned unavailability of the interface and that there is a systems breakdown. Unplanned unavailability or a systems breakdown may be presumed to have arisen when five consecutive requests for access to information for the provision of payment initiation services or account information services are not replied to within 30 seconds.

As part of a contingency mechanism, payment service providers referred to in Article 30(1) (TPPs) shall be allowed to make use of the interfaces made available to the payment service users for the authentication and communication with their account servicing payment service provider, until the dedicated interface is restored to the level of availability and performance provided for in Article 32.

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 of the European Parliament and of the Council or for website authentication as referred to in Article 3(39) of that Regulation.

Article 35 Security of communication session 1. Account servicing payment service providers, payment service providers issuing card-based payment instruments, account information service providers and payment initiation service providers shall ensure that, when exchanging data by means of the internet, secure encryption is applied between the communicating parties throughout the respective communication session in order to safeguard the confidentiality and the integrity of the data, using strong and widely recognised encryption techniques.