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).

The existing QWAC and QSealC formats have been modified to support PSD2. The PSD2 QWACs and QSealCs contain the following PSD2 attributes:

  • A unique authorisation number of the PSP
  • The PSD2 roles for which the PSP has been authorised/registered
  • The name of the National Competent Authority (NCA) where the PSP is authorised/registered

As well as the usual organisation identification and validation processes the QTSP performs, as defined in its certificate policy, it now has to perform the following actions before issuing a PSD2 QWAC or QSealC:

  • Identify the NCA where the PSP has been authorised/registered
  • Find the PSP registration record on any one of 31 NCA register websites
  • Identify the correct registration number of the PSP
  • Generate the unique authorisation number for the PSP
  • Identify the payment services the PSP is authorised/registered to provide
  • Translate the payment services into PSD2 roles

Although all NCAs provide publicly accessible registers, via their websites, these registers are not uniform and provide regulatory data in many different languages, 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.