Inteca developed APILogic TPP Validator and other APILogic solutions in response to market API integration requirements.

APILogic TPP Validator
BUSINESS CONTEXT

The Second Payment Services Directive (PSD2) allows third parties to provide payment services that were previously restricted exclusively to banks. The directive and regulatory standards require all transactions to be handled through secure channels and all data to be protected in terms of authenticity and integrity.

Qualified certificates supporting PSD2

To meet the security requirements, ASPSP and PSD2 service providers will use qualified certificates for websites and qualified certificates for electronic seals. These certificates will be issued by qualified trust service providers (QTSP) based on the new technical standard ETSI TS 119 495, which was published in May 2018. Qualified certificates enable a third party to identify and verify a payment institution. The identification will be based on the organization’s legal name, registration number and main role (roles) within the scope of payments.

Authorization by the payment service provider

Each service provider and ASPSP is authorized in the country of origin by the competent financial supervisory authority to provide services listed in the PSD2 Directive. Information on this subject is published in a public register and this register is the main source of information. To enable automation of communication and data exchange, qualified certificates supporting PSD2 will contain information on the payment service provider’s authorization number, its competent supervisory authority in the home country and its roles. This information is verified by QTSP in the process of applying for a certificate, and then this information will be included in the certificate for identification by others.

Certificates

There are two types of certificates directly supporting PSD2.

  • A qualified website authentication certificate (QWAC) that allows both parties (banks and service providers) to identify each other and build a secure channel for transactions. At the time of initiation, both parties to the transaction use certificates and appropriate private keys to confirm their identity and establish secure SSL communication. In this initialization process, the validity of the qualified certificate is confirmed, including the status of the qualified trust service provider that issued the certificate. A secure channel protects confidentiality and authenticity.
  • A qualified certificate for electronic seal (QSealC) that makes it possible to stamp all evidence, including all data and transaction requests and confirmations. This makes it possible to seal all relevant information in communication, which in turn protects the authenticity and integrity of the data. With this method, if the exchange of information is needed as evidence for any dispute, the relying party can confirm who the creator was and that the information has not changed since its creation.

​​

Register of payment institutions

Although qualified certificates and seals provide the security mechanisms required by RTS, they do not provide full security and certainty. ASPSPs must know in real time that the TPP:

  • is still authorized by the competent national authority;
  • is still approved to perform a role that matches its API request;
  • has a “passporting” for performing services in a given country.

Verification of the above requirements is possible by confirming the actual status in the registers kept by the competent national authority. In case of Poland, it is a register kept by the PFSA (The Polish Financial Supervision Authority).  Another option is to query the payment institutions register EBA, which under provisions of PSD2 must be updated by the competent national authority on an ongoing basis.

Register of credit institutions

Under the PSD2 directive, all credit institutions (Banks) can provide services listed in the PSD2 directive, i.e. they can actually act as payment institutions. The register of payment institutions maintained by the EBA will not contain information about credit institutions. The EBA register shall keep a separate register of credit institutions in accordance with Article 20 of Directive 2013/36. This register only contains information about the name of the credit institution and does not allow automatic integration methods.


APILogic TPP Validator
CHALLENGES IN THE IMPLEMENTATION OF PSD2 REQUIREMENTS

Challenges in the implementation of PSD2 requirements

The business context described above indicates the requirements that the ASPSP should follow to meet the RTS requirements under Article 34. In conclusion, among these requirements are:

  • Real-time validation of the qualified website authentication certificate QWAC.
  • Real-time validation of the qualified certificate for electronic seal (QSealC).
  • Real-time validation of the actual status of the license/entry in the register with the competent supervisory authority.

ASPSPs often have experience related to integration with external entities. As part of this integration, the SSL certificate is used (in the MATLS context) and the signing of exchanged messages. The bank and the third-party exchange certificates and can securely establish communication sessions and sign messages.  Both requirements are usually implemented using a hardware gateway such as Netscaler or F5. It seems natural to meet the requirements of RTSs based on the above approach.

However, this is not possible. The validation of an EIDAS qualified certificate brings additional challenges that are not recognized when integrating with known third parties. Among these we can include:

  1. Not known a priori list of all PSP. Thanks to passporting, PSP can come from any EU country.
  2. The number of PSPs varies over time.
  3. Trust Service Providers (QTSPs) issuing qualified PSP certificates come from many countries. Currently there are over a hundred of them.
  4. The number of certificates used by QSTP for issuing PSP certificates is constantly changing.
  5. The technical requirements for EIDAS certificates make it possible to create certificates that will not be recognized by hardware solutions. An example is the EIDAS certificate for which the CRL list is not covered by the certificate.

The following is the validation process of an EIDAS qualified certificate along with elements that are implemented by APILogic TPP Validator and which are not implemented by hardware solutions:

  1. Validation of the PSP certificate
    1. Is the certificate valid?
    1. Has the certificate been revoked? Here, APILogic TPP Validator extends the possibilities of hardware solutions by checking CRL (or OSCP) lists on TSL lists in accordance with EIDAS requirements.
  2. Validation of the QTSP certificate
    1. Is the QTSP trusted? (APILogic TPP Validator only)
    1. Can QTSP provide a trusted certificate issuing service? (APILogic TPP Validator only)
    1. Is the QTSP certificate valid? (APILogic TPP Validator only)

As far as the determination of the actual status of the PSP license is considered, its status in the native registry for the PSP or in the central PSP register maintained by the EBA should be checked. In accordance with the assumptions of technological standards, the EBA register shall be refreshed by the competent authorities of all Member States. It shall also provide the option of automatically downloading current information.

All of the above validations require continuous (online) access to many external repositories:

  • Certificate validation – 32 repositories.
  • License validation – 1 repository.

APILogic TPP Validator is a solution that fulfills all of the above requirements.


APILogic TPP Validator
SOLUTION DESCRIPTION

APILogic TPP Validator is software for checking certificates and the status of licenses / entries in the register of payment institutions. APILogic Validator performs the above functionalities in accordance with European legislation. In particular, it supports the eIDAS regulation, the PSD2 directive and related standards.

Architecture and functionality of the solution

The solution provides functionality through the following REST services:

  • validatePSD2certificate
  • validatePSD2license

The first service (validatePSD2certificate) at the input accepts the TPP certificate and validates it in accordance with the requirements of the EIDAS Regulation and the requirements of the EBA. The service responds with information about:

  • certificate status
  • PSD2 roles in which TPP can occur (AISP, PISP)
  • TPP license number
  • certificate type:  QWAC, QSealC

The other service (validatePSD2license) at the input assumes the TPP license number and returns information about:

  • license status
  • PSD2 roles assigned to TPP
  • passporting status

APILogic TPP Validator can be deployed as a standalone solution or as a container on the Kubernetes/Openshift platform. The deployment can take place in the DMZ or a secure network.

The solution requires access to the Internet in order to communicate with:

  • Register of payment Institutions EBA
  • TSL trust lists that are published by the relevant supervisory authorities in all European Union countries.

The data stored by the component are not sensitive data. The solution does not have a database. All information needed for certificate and license validation is stored in memory. Due to the requirement of constant data updating, the solution synchronizes with external registers at fixed intervals.

The time to complete the certificate validation requests (SLA) ranges from 50 ms to 250 ms (gross). In turn, the processing time for requests checking the license status ranges from 40ms to 100ms (gross).

All functionalities available from the level of REST services have their equivalent in the administrator console. The administrator console can be used to manually check the certificate and license. Below is the screen of the qualified certificate validation result and the screen showing current trust lists that have been synchronized by the offered solution.

Mode of operation

Each request made by the TPP before being served by the ASPSP must be checked to ensure the security of the transaction. Below is a list of steps and places where APILogic TPP Validator provides its functionalities:

  1. Establishing an SSL session between TPP and ASPSP
    • Gateway/HTTP Proxy transfers the website certificate to APILogic TPP Validator. Based on the result of EIDAS and EBA validation, a session is established or rejected.
  2. Sending a message by the TPP to the ASPSP after establishing the session
    • Gateway/HTTP Proxy transfers a seal certificate to APILogic TPP Validator. Based on EIDAS and EBA validation, the transaction is carried out or rejected.

Emergency interface

In accordance with Art. 33 point 5 of RTS, ASPSP is required to identify the Paying Authority (TPP) that uses the emergency interface. Usually, the emergency interface is offered by ASPSP as a “stripped down” version of the end-user interface (eBank). APILogic TPP Validator has a proxy module that validates the certificate before forwarding the request to the emergency interface. Thus, it ensures fulfillment of the requirements of Article 33 point 5 of the RTS standard. Below is presented a general functional diagram.

​​

Register of credit institutions

As part of the proposed solution, we do not assume integration with the central register of EBA credit institutions. It is not easily parsed. QTSP at the time of issuing the certificate is required to check the status of the credit institution in the native registries. In the certificate, these institutions are marked with a special attribute (PSP_AS). Based on this attribute, APILogic TPP Validator will mark that the license belongs to the ASPSP and will consider it valid. New EBA Opinion (https://eba.europa.eu/documents/10180/2137845/EBA+Opinion+on+the+use+of+eIDAS+certificates+under+the+RTS+on+SCACSC.pdf) describes a certificate revocation method that minimizes the risk of frauds related to PSP certificates.


APILogic TPP Validator
SELECTED SCREENS


APILogic TPP Validator selected
USE CASES

CLIENT: One of the 3 largest banks in Poland

SOLUTIONS USED:​ APILogic TPP Validator

The implementation of APILogic TPP Validator at the customer / bank allowed the organization to adapt to the requirements of the PSD2 directive and to fully automate certificate validation. The application provided automatic recognition of all certificates across the European Union and full validation of certificates in accordance with eIDAS and PSD2 attributes: AIS, PIS, COF. Additionally, APILogic TPP Validator validates certificates in the EBA PIS Registry. Since validation is a service the bank could choose to deploy it in API gateway or in Fallback.
The certificate validation for fallback and for API was implemented using integration with Software AG webMethods API Gateway.

CLIENT: One of the 10 largest banks in Poland

SOLUTIONS USED:​ APILogic TPP Validator

The implementation of APILogic TPP Validator at the customer / bank allowed the organization to adapt to the requirements of the PSD2 directive and to fully automate certificate validation. The application provided automatic recognition of all certificates across the European Union and full validation of certificates in accordance with eIDAS and PSD2 attributes: AIS, PIS, COF. Additionally, APILogic TPP Validator validates certificates in the EBA PIS Registry. Since validation is a service the bank could choose to deploy it in API gateway or in Fallback.
The certificate validation for fallback and for API was implemented using integration with NetScaler.