Are eIDAS certificates the answer to PSD2 open banking TPP verification?

Brendan Jones, Konsentus

The second Payment Services Directive (PSD2) came into force across the European Union on 12 January 2016, and was passed into law by EU’s member states on 13 January 2018.

PSD2 states that account servicing payment service providers (ASPSPs) that offer online payments accounts shall allow payment service users (PSUs) to access accounts via regulated third party providers (TPPs) to:

• initiate payments;
• get account information;
• confirm available funds.

And that communications between the ASPSPs and the TPPs will be secure, and in compliance with the European Banking Authority (EBA) regulatory technical standards (RTS), subsequently transposed into Commission Delegated Regulation (EU) 2018/389 of 27 November 2017, supplementing Directive (EU) 2015/2366 of the European Parliament and of the Council with regard to regulatory technical standards for strong customer authentication and common and secure open standards of communication.

The RTS states that all interfaces will use eIDAS certificates for identification and that the application programming interfaces (APIs), provided by the ASPSPs, must be available for TPPs to go live by 14 September 2019.

Not only do ASPSPs have the obligation to allow access to regulated TPPs but they must also block access to unregulated entities. Failure by the ASPSPs to properly identify and authenticate TPPs and verify the consents, provided by the PSU, could lead to the risk of unauthorised transactions and subsequent claims under PSD2, or unauthorised data sharing and subsequent claims under the General Data Protection Regulation (GDPR).

eIDAS (Regulation (EU) 910/2014) came into effect on 1 July 2016 with the goal of providing a predictable regulatory environment for electronic identification (eID) and electronic trust services (eTS). The regulation replaces the earlier eSignatures Directive and removes any inconsistencies in digital signature laws across Europe, for which the UK has currently opted out. However, the UK PSD2 stakeholder group, managed by the New Payment System Operator (NPSO) has written to the Department of Business, Energy and Industrial Strategy (BEIS) on 20 March 2018 stating that the UK needs to create qualified trust service providers (QTSPs) that will issue qualified certificates to comply with EU law post-2019 and thus will issue eIDAS certificates to UK approved/registered companies.

eIDAS defines advanced electronic signatures (AdES), qualified electronic signatures (QES) and electronic seals. Both AdES and QES prove identity of the signer and are the equivalent of a wet ink signature. The only difference being that AdES can be accepted by other EU member states, but QES must be accepted. Electronic seals are like signatures but apply only to legal persons and corporate entities. This enables organisations to sign documents instead of having to have individuals as authorised signers.

PSD2 specifies the use of two types of qualified certificates:

• qualified website certificates (QWACs): EU 910/2014 (eIDAS) Annex IV;
• qualified certificates for seals (QCSEALs) EU 910/2014 (eIDAS) Annex III.

To meet the RTS these certificates must contain the following PSD2 data:

• the authorisation number of the TPP;
  • Available in the public registers of the national competent authorities;
• the role of the TPP, which may be one or more of the following:

1. account servicing;
2. payment initiation;
3. account information;
4. issuing of card-based payment instruments;

• the name of competent authorities where the TPP is registered.

As well as the usual qualified certificate information such as:

• name of certificate owner;
• name of the qualified trust service provider (QTSP);
• validity period, start and end dates.

QTSPs issuing qualified certificates must follow the policy requirements defined by EN 319 411‐2, namely:

• security of TSP operations;
• registration and issuance of certificates;
• revocation in case of certificate compromise including:
  • compromise of certificate subject’s key;
  • revocation of certified attributes.

And Certificate Profile requirements defined by EN 319 412:

1. overview;
2. certificates issued to natural persons [for signatures];
3. certificates issued to legal persons [for seals];
4. website certificates;
5. qualified certificate statements.

In addition, when issuing qualified certificates for PSD2, the QTSP must check the PSD2 attributes from the public register of the appropriate national competent authority.

The use of qualified certificates in PSD2 ensures independent, government assured trust in the identity of the communicating parties; enables a secure channel to be established between the authenticated parties; and provides legally assured evidence of transaction data

ASPSPs and TPPs will use eIDAS qualified website certificates for mutual identification and authentication during the process of establishing a secure communications channel using transaction layer security (TLS).

ASPSPs and TPPs will use eIDAS qualified certificates for seals to ensure the integrity and proof of origin of PSU account and payment initiation data. The confidentiality of the data is provide by the encrypted TLS session.

Although qualified certificates and seals provide some of the security mechanisms required by the RTS they do not provide all the security and assurance that ASPSPs need to authorise a PSD2 transaction with a TPP across its API. ASPSPs need to know, in real-time, that:

• a TPP is still regulated by its national competent authority;
• it is still approved to perform the role which is consistent with its API request;
• the consents it received from the PSU are still valid, and have not been revoked by the PSU.

Since there is no obligation under PSD2 or the RTS for a national competent authority to notify the QTSP when a TPP has its regulated status revoked or its role changed, the ASPSP cannot rely solely on the PSD2 information held in the qualified certificate. The ASPSP needs to refer to the public registers of the national competent authorities to validate the roles and regulated status of a TPP. The ASPSP will also need to refer to its own records, especially if it provides PSUs with the means to actively manage the consents that have been granted.

So in summary:

• eIDAS certificates prove who a TPP is, but not if they are still approved by the National Competent Authority, at the time of usage;
• also PSD2 scheme regulatory databases offer lists of approved TPPs, but TPPs do not have to register on them (e.g. UK’s open banking);
• national competent authorities hold lists of approved and registered TPPs, but often not in a machine-readable form.

By Brendan Jones, CCO  and co-founder of Konsentus Ltd