January 2019 saw the European Banking Authority (“EBA”) establish a Working Group on application programme interfaces (“APIs”) under the second payment services directive (“PSD2”). The aim of such group was to prepare the industry for the Regulatory Technical Standards (“RTS”) on Strong Customer Authentication and Common and Secure Communication. The group is also asked to propose solutions on how the identified issues could be addressed, which the EBA and national authorities will then consider when providing clarifications in response to the issues raised.
Throughout the year, the EBA published clarification notes to the first four sets of issues that had been raised by the working group. On the 14th of August 2019, the European Banking Authority (EBA) published a clarifying note to a fifth set of issues which were raised on the following points:
Machine readability
The EBA has clarified that data fields of the machine-readable file paired with the information in the central register will allow for a better interpretation of information contained in the register. In this aspect, the EBA has also published a document with the specification of the data properties of the JavaScript Object Notation file with the content of the central register of the EBA under PSD2.
Measurement of response times of the dedicated interface
The EBA Guidelines on the conditions to benefit from an exemption from the contingency mechanism have clarified that the response time includes “ the interval between the point in time when a request is received by the ASPSP[1] from a PISP[2], AISP[3] or CBPII[4] and the point in time when all the information requested (or where relevant the yes/no confirmation) has been sent back by the ASPSP).”
It is further clarified under the same guidelines that the response time includes the time it takes to check the authorisation/registration of Third-Party Payment Systems (“TPPS”) in particular the TPP’s eIDAs[5] certificate.
Contingency mechanism in terms of Article 33(4)-RTS
1.Identification of TPPs through “guestbooks”
The EBA has clarified that identification of TPPs towards the ASPSP should be based on the use of qualified certificates for electronic seals (QSealCs) and/or qualified certificates for website authentication (QWACs). It has also been clarified that the requirements in Article 33(5) RTS regarding identification of TPPS when using contingency mechanism apply for identification of TPPs with QSealCs/QWACs apply irrespective of whether the TPPs are accessing the PSU[6]s’ payment accounts via the dedicated interface or via the PSU interface as a primary access method.
With respect to the guestbook identification, the EBA is of the view that such identification method does not meet the requirements in Article 34(1) and Article 33(5) RTS, as it does not allow ASPSPs to rely on the eIDAS certificates for the identification of TPPs. In addition, such guestbook entry would not be compliant with the PSD2 because the ASPSP would not be able to check whether the TPP has identified itself at the time the access takes place.
In this aspect, the PSD2 holds that PISP’s should identify themselves “every time a payment is initiated”. Furthermore, AISPs are required to identify themselves towards the ASPSP “for each communication session”.
2. Data that can be accessed
Article 35(5) of the RTS holds that ASPSPs should ensure that TPPs “can be identified” meaning that TPPs are able to identify themselves towards the ASPSP using eIDAS certificates in accordance with Article 34(1) RTS, and that TPPs can rely on the authentication procedures provided by the ASPSP to its PSUs.
Furthermore, the contingency mechanism should also enable TPPs to perform the following actions:
With respect to the scope of data that can be accessed by TPPs through the contingency access the PSD2 and the RTS do not provide any obligation for the ASPSP to limit the data that TPPs can see when accessing through the PSU interface.
The only situation where the RTS require ASPSPs to restrict access to certain data is the one referred to in Article 36.1(a) RTS, according to which ASPSPs “shall provide [AISPs] with the same information from designated payment accounts made available to the payment service user when directly requesting access to the account information, provided that this information does not include sensitive payment data. “
“Sensitive payment data” is defined in Article 4(32) PSD2 as “data, including personalised security credentials which can be used to carry out fraud. For the activities of payment initiation service providers and account information service providers, the name of the account owner an and the account number do not constitute sensitive payment data.”
This is without prejudice to any other obligations that ASPSPs may have under the GDPR Regulation.
3. Documentation of Contingency Mechanism
In accordance with Article 33(1) and (2) ASPSPs shall set out a strategy and plans for the contingency measures and communications plans to inform TPPs of the “immediately available alternative options” through which they can continue providing their services while the API is restored. Such strategy and communication plans must be provided also in relation to the use of the contingency mechanism in Article 33(4) of the RTS. To this end, ASPSPs that do not receive an exemption in accordance with Article 33(6), or whose exemption has been revoked by a national competent authority should include in such strategy and communication plans a description of the contingency mechanism and of the authentication procedures on which TPPs can rely.
4. Availability of, and reliance on, Eidas certificates under Article 34 RTS from qualified trust service providers.
The EBA has clarified that “authorisation number” in terms of Article 34 (2) RTS includes “all forms of national identification numbers that are used by NCA[7]s under PSD2 and allow the unequivocal identification of the payment service providers (PSPs) in the national registers under PSD2 and CRDIV[8] as well as in the EBA PSD2 and credit institution registers.” Further guidance has also been given in a document tabled by the EBA entitled “EBA Opinion on the use of eIDAS certificates under the RTS on SCA&CSC (EBAOp-2018-7).”
The EBA is expected to release further guiding notes in the coming month prior to the application date of the RTS on 14 September 2019.
Article written by Dr Luke Mizzi.
For more information on the Payment Services Directive and related guidelines please contact Dr Ian Gauci on igauci@gtgadvocates.com Dr Cherise Abela Grech on cabelagrech@gtgadvocates.com and Dr Luke Mizzi on lmizzi@gtgadvocates.com
Disclaimer:
This article is not intended to impart legal advice and readers are asked to
seek verification of statements made before acting on them.
[1] Refers to any financial institution that offers a payment account with online access
[2] Payment Initiation Service Provider
[3] Account Information Service Provider
[4] Card Based Payment Instrument Issuer
[5] Electronic identification and trust
[6] Payment Service User
[7] National Competent Authorities
[8] The Fourth Capital Requirements Directive