Solutions

Konsentus offers three services to Financial Institutions, facilitating their compliance with EU regulation on PSD2 open banking:

  • Third Party Provider (TPP) regulatory status checking
  • eIDAS Seal Certificate Checking
  • Consent and preference management tokenisation services

Konsentus delivers a cloud based (SaaS) RESTful API regulatory checking service.

Konsentus will receive (from the ASPSP) the eIDAS certificate supplied by the TPP.

The Konsentus platform provides the following services:

  • Verify the TPP’s identity and regulated status, every time the TPP accesses the PSU account data or initiates a payment.
  • Issue a secure access token to the TPP, via the ASPSP, for access to the PSU’s account(s) once verification and checking are satisfactorily completed.
  • Verify that the access token presented to access the PSU’s account is valid and holds the correct “explicit consents” granted by the PSU.
  • Check the PSU has not revoked the TPP’s access through the ASPSP’s online banking application.
  • Reissue access tokens to TPPs when existing tokens have expired.
  • Record the details of each interaction with the ASPSP in an immutable log.

 

eIDAS Seal Certificate Checking

Under PSD2 Payment Service Providers (PSPs) will rely on eIDAS Seals and Certificates to provide proof of origin, identity and data integrity services on payment initiation and account access requests. These Qualified Seal Certificates will be issued by Qualified Trust Service Providers (QTSPs) in collaboration with national Competent Authorities who will provide the QTSPs with a unique identification number for the PSP, the PSD2 roles for which the PSP is approved and the identity of national Competent Authority.

The existence of a Seal Certificate is not sufficient to guarantee the integrity of the identity of the owner nor the integrity of the data protected by the certificate. Each time the certificate is used and presented, the recipient must check that the certificate was issued by a QTSP, that the certificate has not expired and that the certificate has not been revoked.

Konsentus will check that the issuer of the certificate is a registered QTSP, that the certificate has not been revoked by checking the QTSP’s Certificate Revocation List (CRL) or On-line Certificate Status Protocol (OCSP) server, that the certificate has not expired and what roles the PSP, identified in the certificate, is registered for.

The information in the certificate will be true at the time of issue but over time the roles for which the TPP is approved may change or be revoked. Therefore the eIDAS certificate cannot solely be relied upon to know the regulated status of a TPP. This is why Konsentus will always check, in real-time, with the identified national Competent Authority what the approved and regulated status of a TPP is at the time of the transaction.

Consent and Preference Management Tokenisation Services

Konsentus provides secure Consent and Preference management access tokenisation services to FIs using open standards (OAuth 2.0, OpenID Connect, ODI FAPI etc.). Konsentus issues the access tokens for Client Credential Grants and Authorisation Code Grantson behalf of the Financial Institution, which passes them to the third-party providers. to present each time they access the open banking application programming interface (API).
Konsentus checks the access tokens that are presented to the FI’s open banking API to ensure that the third-party provider has the appropriate payment service user consent and is a regulated TPP, at the time of the transaction. This may involve Konsentus checking the identity of the TPP using its eIDAS certificate and checking its national competent authority’s database to validate its regulated status and PSD2 roles.

 Article 23 of PSD2 states:

Where access to payment accounts is offered by means of a dedicated interface, in order to ensure the right of payment service users to make use of payment initiation service providers and of services enabling access to account information, as provided for in Directive (EU) 2015/2366, it is necessary to require that dedicated interfaces have the same level of availability and performance as the interface available to the payment service user.

Konsentus will deliver an uptime equal to or greater than the FI’s existing online channels in order to meet the regulatory requirements.

eIDAS Certificates

Under PSD2, ASPSPs will rely on eIDAS Qualified Seal Certificates (QSealCs) and Qualified Web Authentication Certificates (QWACs) to provide proof of origin, identity and data integrity services on payment initiation and account access requests and for Mutually Authenticated Transaction Layer Security (MTLS) and confidentiality for secure communications.

These Qualified Certificates will be issued by Qualified Trust Service Providers (QTSPs) in collaboration with NCAs who will provide the QTSPs with a registration number for the TPP, the PSD2 roles for which the TPP is authorised/registered and the identity of the NCA.

The existence of a Qualified Certificate is not sufficient to guarantee the identity of the owner nor the integrity of the data protected by the certificate. Each time the certificate is used and presented, the recipient must check that the certificate was issued by a QTSP, that the certificate has not expired and that the certificate has not been revoked.

Konsentus will check that the issuer of the certificate is a registered QTSP, that the certificate has not been revoked, by checking the QTSP’s Certificate Revocation List (CRL) or On-line Certificate Status Protocol (OCSP) server, that the certificate has not expired and what roles the TPP, identified in the certificate, is authorised/registered for.

The information in the certificate will be true at the time of issue but over time the roles for which the TPP is approved may change or be revoked. Therefore the eIDAS certificate cannot solely be relied upon to know the regulated status of a TPP.

This is why Konsentus always checks, in real-time, with the identified NCA what the approved and regulated status of a TPP is at the time of the transaction.

When a TPP makes an Account Information Service or a Payment Initiation Service request to an ASPSP, via an API or modified user interface, the ASPSP needs to be certain that the TPP is who they claim to be. This is achieved using eIDAS qualified certificates. These certificates will have been issued to the TPP by a QTSP who will have done a variety of checks on the TPP, including checking their regulated status on their Home NCA register, before issuing qualified certificates (QWAC and QSealC) to them.

QTSP Regulatory Checking

The European Banking Authority (EBA) Regulatory Technical Standard on Strong Customer Authentication and Common and Secure Communication (RTS on SCA and CSC) Article 34.1 requires that, for the purpose of identification, Payment Service Providers (PSPs) rely on eIDAS qualified certificates for website authentication (QWAC) or qualified certificates for electronic seals (QSealC).

A QWAC makes it possible to establish a Transport Layer Security (TLS) channel with the subject of the certificate, which guarantees confidentiality, integrity and authenticity of all data transferred through the channel.

A QSealC allows the relying party to validate the identity of the subject of the certificate, as well as the authenticity and integrity of the sealed data, and also prove it to third parties. Electronic seal provides strong evidence, capable of having legal effect that the data, protected by the eSeal, originated from the legal entity identified in the certificate.

Before a PSD2 eIDAS certificate can be issued to a PSP it must have first been registered by its National Competent Authority (NCA) and all relevant regulatory information needs to be available in the public register.

When a PSP requests an eIDAS certificate from a QTSP the PSP submits a certificate application, providing all the necessary documentation required by the QTSP, including the specific PSD2 attributes.

The QTSP performs identity validation, as required by its certificate policy.

The QTSP validates the PSD2 specific attributes, using information provided by the PSP’s Home NCA public register and generates a unique authorisation number for the PSP.

If all the identity checks and PSD2 regulatory status validations are successful the QTSP issues the eIDAS certificate to the PSP.

A PSP is free to request eIDAS certificates from any QTSP in the EEA. Which means that the QTSPs has to have the means to validate the regulatory status of PSPs via anyone of the 31 NCAs across the EEA.

Although all NCAs provide publicly accessible registers, via their websites, these registers are not uniform and provide regulatory data in many different formats and layouts. It is a complex process to access and extract the relevant information from the NCA registers in an automatic and efficient manner.