Introduction

This article is the first in series dealing with the issue of the eIDAS Regulation and qualified certificates in the context of the PSD2 directive. We will present the PSD2 requirements for the automatic verification of TPP’s identity by ASPSP when using the “special interface” (usually API, e.g. PolishAPI) and the “emergency interface” (usually electronic banking).

PSD2 requirements in the context of TPP authentication

The Payment Services Directive 2 (PSD2) allows third parties (TPPs) to provide payment services that were previously restricted only to banks (ASPSP). Technically, in order to process these services, TPPs can access an account maintained by the bank using two types of interfaces:

  • “Special interface”
  • “Emergency interface”.

PSD2 forces banks to provide both interfaces for TPP use. In addition, regulatory standards (RTS) broadly describe the technical requirements for these interfaces. In our considerations, we will focus on one requirement that is authentication / identification of the TPP towards the ASPSP. This requirement for a “special interface” is described in RTS article 30 paragraph 1, point a), and for the “emergency interface” in art. 33 paragraph 5.

Typically, in IT, the technical implementation of the identity verification process is realized by means of the public key infrastructure (PKI). It is quite similar in PSD2 regulation and the RTS in art. 34 section 1, indicates the need to rely on an electronic seal certificate or a website authentication certificate.

However, there are given additional details here. In RTS it is explicitly told that it is about qualified certificates in accordance with the eIDAS regulation. However, the requirement to use one or another type of certificate may be misleading. One must remember that for the purpose of identification while establishing a connection, website authentication certificate should be used instead of a seal certificate. Fortunately, the EBA explains the situation in a published opinion. EBA indicates that the best approach it is to use a website authentication certificate to establish a secure connection (meeting the RTS requirement described article 35, section 1). The seal certificate should be used for stamping / signing messages.

However, we are left with the question: why exactly eIDAS qualified certificates should be used? The answers can be found in RTS art. 32 section 3, that describes requirement prohibiting “creating obstacles” in services providing process by TPP, including additional registrations, additional license requirements, etc.

Standard implementation of PKI requires “trust” to the issuer of certificate from all parties entering into relationships. The eIDAS certificates for TPPs are issued by qualified trust service providers (QTSPs), that are completely independent of TPP and ASPSP and supervised by the relevant authorities.For example iIn Poland there are several companies with QTSP status like: Center, KIR, etc. Relying on eIDAS certificates guarantees both parties TPP and ASPSP, the possibility of mutual identification fully automatically. Both parties do not have to enter into any relationship: register, sign contracts or issue certificates. It is not necessary,

and even forbidden. RTS in article 32 (3) highlights that the ASPSP may not require from the TPP to register on its websites if the TPP presents a valid eIDAS certificate. The derogation from the lack of registration requirement can be used for test environments (“sandbox”), because these environments should be made available to companies applying for TPP status (companies that are not yet certified).

Finally, in PSD2 we have the following situation. TPP and ASPSP apply for a seal certificate and website authentication certificate at QTSP. With such certificates, the TPP initiates connection with the ASPSP and a secure connection is established. Both parties trust each other because the certificates they presented during the connection were issued by trusted QTSP. At this point, TPP may start performing the Account Information Service (AIS), Payment Initiation Service (PIS), Confirmation of Funds (Cof) services, or use the “emergency interface”. The process seems standard. However, at this point of our considerations a few questions arise:

  • Where to get the issuer certificate (QTSP certificate) in order to verify qualified TPP certificates?
  • How to validate qualified TPP certificates?
  • Does eIDAS and PSD2 impose additional requirements related to certificate validation?
  • How many trust service providers (QTSPs) there are in Europe? Can they all issue qualified TPP certificates?
  • Do QTSP certificates change and how often?
  • Does the TPP’s possession of the seal and certificate mean that TPP can automatically perform AIS and PIS services? What about the need of a valid license and entry in the register?
  • How to manage QTSP certificates? Can I use standard PKI mechanisms / devices for this?
  • What about TPP passporting?

We will answer these and other questions in the following articles from this series.

psd2 directive tpp