This question in isolation is difficult to answer. One of the most important points to consider is whether the checking needs to be done in real-time, at the time of a transaction taking place. If this is the case, this then becomes a more complex question than simply validating the identity (eIDAS certificate) of a TPP. A TPP may hold a valid eIDAS Certificate, but how can a Financial Institution (ASPSP) know if indeed a TPP is still regulated to provide the services for which it is attempting to access the Payment Service User’s (PSU) account(s)?
It is very difficult therefore to treat the identity checking status of a TPP in isolation. It goes hand in hand with verifying a TPP’s current regulatory authorisation status. To do one without the other would be negligent and leave ASPSPs open to fraudulent attacks, financial loss and the associated reputational risks.
Therefore, the questions that need to be asked are: ‘who is the TPP that is trying to access my API’ and ‘what services are they authorised to perform’? We could also include a third question which is: ‘is the TPP authorised to provide the services in the country that it is requesting account access?’ (the right of passporting).
It’s only once all these questions can be answered satisfactorily that any conclusion can be drawn as to whether using a directory service presents an obstacle.
Indeed, as the “Opinion of the European Banking Authority on obstacles under Article 32(3) of the RTS on SCA and CSC”, EBA/OP/2020/10, issued: 4 June 2020, states in paragraph 49, the intention is for any secure communication to be processed in a “timely manner” and not creating “unnecessary friction in the customer journey”.
The first question and piece of the puzzle is ‘Who is the TPP that is trying to access my API’?
Article 34(1) of the EBA RTS for SCA & CSC states, “For the purpose of identification, as referred to in Article 30(1)(a), payment service providers shall rely on qualified certificates for electronic seals [QSealC] as referred to in Article 3(30) of Regulation (EU) No 910/2014 or for website authentication [QWAC] as referred to in Article 3(39) of that Regulation.”
This means that eIDAS qualified public key certificates (QWACs or QSealCs) must be used to identify TPPs. On the basis that an eIDAS Certificate can have up to a two-year validity period, in which time changes may have been made to its regulatory authorisation status by its home Member State National Competent Authority (NCA), introduces significant risk to the ASPSP decisioning process.
eIDAS certificates do not contain all the information on which markets a TPP is authorised to provide services. The legal source of this information is held on the TPP’s home NCA Credit Institution and Payment Service Provider (PSP) registers. These registers hold information on the payment services a TPP is authorised to provide in its home Member State. They also hold information on the services that a TPP can provide in other host Member States, under the EU passporting rules which is the third question raised above and is important to consider when determining what is strictly necessary to ensure “secure access to payment accounts” as also discussed in the EBA’s recent opinion paper.
We still however need to address the second question: ‘What services is the TPP authorised to provide and, how can this be done in a way that does not present an obstacle?
According to PDS2, for the regulatory checking to be done in a frictionless way, means that it must be as performant as the on-line interface provided by the Financial Institution to its customers.
Accessing the information from all these registers in real-time, may indeed present an obstacle for ASPSPs. This would mean connecting in real-time to the 31 NCAs and being able to interrogate in real-time over 115 separate registers.
However, with a directory service such as Konsentus Verify, these obstacles are removed. The current regulatory data held within the NCA registers is consolidated in an up-to-date central database which can be accessed by ASPSPs via a RESTful API. Providing all the information on a TPP’s regulatory status, at the time of a transaction, from both its home NCA registers but also the services a TPP can provide in the host Member State.
TPP identity checking, as we’ve said before, if conducted in isolation exposes an ASPSP to unnecessary fraud and risk. Therefore, it’s imperative to be able to verify the authorisation status of the TPP at the same time the eIDAS identity check is taking place.
Konsentus Verify checks the TPP’s eIDAS certificate and authorisation status at the time a transaction request is made, verifying the eIDAS certificate and the status of the issuing QTSP as well as the authorisation status of the TPP in its home and host Member States. The results are presented back to the ASPSP in less than 200 milliseconds enabling informed risk management decisions to be made in real-time.
As liability for granting a TPP access to a customer’s account rests with the ASPSP, they must be sure, at the time of the transaction, that the TPP is positively identified, legitimate and regulated to provide the services in the country for which it is attempting to access the account(s).
Article 68 (5) of PSD2 states that a Financial Institution “may deny an account information service provider or a payment initiation service provider access to a payment account for objectively justified and duly evidenced reasons relating to unauthorised or fraudulent access to the payment account by that account information service provider or that payment initiation service provider”.
This means that a Financial Institution must be able to answer all three questions set out at the beginning of this article to present evidenced reason for denying a TPP account access. If these questions can be answered in real-time without adding unnecessary friction in the customer journey, then using a directory service has to be obstacle-free.
