Bank of Thessaly “Contingency (Fallback) Mechanism"

In case the dedicated PSD2 APIs you wish to consume are not yet available, we offer connectivity to a “Contingency (Fallback) Mechanism”. This is only made available to third party service providers which are authorized or registered with a national competent authority.

As implemented , the “Contingency (Fallback) Mechanism” fulfills two objectives:

1. Secure and reliable authentication of the calling TPP, so that access to PSU data is granted only to authorized entities
2. Enabling TPP access to use the same client facing interface, as the PSU

For the “Contingency (Fallback) Mechanism” we offer the reuse of our client facing interface (e-banking) https://www.e-thesbank.gr. In order to access “Contingency (Fallback) Mechanism” prior to get access to our client facing interface, the following URL should be used :

https://tpp.bankofthessaly.gr

In order to use the fallback mechanism, the TPP will need to have in their possession a valid Qualified Website Authentication Certificate (QWAC).

In order to use the fallback mechanism, the TPP will need to follow one of the 2 methodologies described below:

• Integrate the eIDAS QWAC certificate in all upcoming calls Client Certificate, either through browser tools or API testing tools (e.g)
• Include the eIDAS QWAC certificate in all REST calls to the above url, via the Header parameter tpp-qwac-certificate

In case the TPP's eIDAS certificate is valid, the identity, as well the PSD2 roles (AISP, PISP, PIISP or ASPSP) of the TPP are checked. Once done, the following procedure takes place:

1. With a valid eIDAS certificate, the TPP is redirected to the Bank's dedicated fallback interface, which provides the same functionality for access to PSU accounts, as the web interface (e-banking). When redirected, the TPP is presented with a dedicated login page, where the PSU's authentication credentials are expected, in the same manner as solutions that utilize screen scraping mechanisms.
2. The TPP enters the PSU's credentials in order to perform authentication. The dedicated fallback interface is integrated with the Bank's infrastructure via secure APIs, and the provided credentials are validated against the Bank's database of users
3. If the PSU's login credentials are valid, the TPP receives a JSON response from the dedicated fallback interface, containing all necessary account information for the authenticated PSU, as well as direct links that can be used to retrieve specific account information or execute a payment (transfer)

In this respect, Article 66(3)(d) of PSD2 provides that PISPs should identify themselves towards the ASPSP “every time a payment is initiated”. Similarly, Article 67(2)(c) PSD2 requires AISPs to identify themselves towards the ASPSP “for each communication session”. That is why the fallback solution must be called before each client session opened by the TPP.

The provided infrastructure, allows to prove the TPP’s identity by providing the requisite certificates. TPP will have to follow this specific process each time a fallback access is requested, namely when Bank of Thessaly Open Banking API are not available or do not perform as they should (as requested by PSD2 and EBA RTS).Similar to the “dedicated interface” you will be authenticated by your QWAC client certificate. Upon successful presentation of a valid QWAC certificate, you will be redirected to the client facing interface.

Note as that as per Art. 33(5) of RTS TPPs, when accessing the client facing interface as a contingency mechanism shall:

• Take the necessary measures to ensure that they do not access, store or process data for purposes other than for the provision of the service as requested by the payment service user.
• Continue to comply with the obligations following from Article 66(3) and Article 67(2) of Directive (EU) 2015/2366 respectively.
• Log the data that are accessed through the interface operated by the account servicing payment service provider for its payment service users, and provide, upon request and without undue delay, the log files to their competent national authority

Fallback regulatory requirements

By the Revised Payment Services Directive, Account Servicing Payment Service Providers (ASPSPs), are required to grant Third Party Payment Services Providers (TPPs) - conditionally on the requirements of the PSD2 and the RTS - access to their customers’ (Payment Service User’s – PSU) bank accounts. For this purpose, ASPSPs implement dedicated interfaces through which TPPs access the ASPSPs systems and, thus, the PSU bank accounts.

The dedicated interface allows the ASPSP not only to identify the accessing TPP by certificates but provides a secure access environment to protect PSU data. With respect to the dedicated interface’s performance and availability, the EBA asks ASPSPs to monitor both and provide contingency (fallback) mechanisms in case the dedicated interface does not function properly or is unavailable. Article 33 (4), (5) of the EBA claims [...] 4. As part of a contingency mechanism, payment service providers referred to in Article 30(1) shall be allowed to make use of the interfaces made available to the payment service users for the authentication and communication with their account servicing payment service provider, until the dedicated interface is restored to the level of availability and performance provided for in Article 32.

The dedicated interface allows the ASPSP not only to identify the accessing TPP by certificates but provides a secure access environment to protect PSU data. With respect to the dedicated interface’s performance and availability, the EBA asks ASPSPs to monitor both and provide contingency (fallback) mechanisms in case the dedicated interface does not function properly or is unavailable. Article 33 (4), (5) of the EBA claims [...] 4. As part of a contingency mechanism, payment service providers referred to in Article 30(1) shall be allowed to make use of the interfaces made available to the payment service users for the authentication and communication with their account servicing payment service provider, until the dedicated interface is restored to the level of availability and performance provided for in Article 32.

1. take the necessary measures to ensure that they do not access, store or process data for purposes other than for the provision of the service as requested by the payment service user.
2. continue to comply with the obligations following from Article 66(3) and Article 67(2) of Directive (EU) 2015/2366 respectively.
3. log the data that are accessed through the interface operated by the account servicing payment service provider for its payment service users, and provide, upon request and without undue delay, the log files to their competent national authority.
4. duly justify to their competent national authority, upon request and without undue delay, the use of the interface made available to the payment service users for directly accessing its payment account online.
5. inform the account servicing payment service provider (ASPSP) accordingly.