According to Article 33 – “Contingency measures for a dedicated interface”, the ASPSP’s shall include a contingency mechanism (or fall-back solution) in case the dedicated API service becomes unavailable or is not working properly. In this instance, the fall-back solution would essentially mean banks have to make their customer interface (such as internet banking or mobile banking app) available for screen scraping with the ability to identify TPPs, until the API service is restored.
Unplanned unavailability or a systems breakdown may be presumed to have arisen when five consecutive requests for access to information for the provision of payment initiation services or account information services are not replied to within 30 seconds.
Contingency measures shall include communication plans to inform payment service providers making use of the dedicated interface of measures to restore the system and a description of the immediately available alternative options payment service providers may have during this time.
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.
ASPSP’s shall ensure that the payment service providers referred to in Article 30(1) can be identified and can rely on the authentication procedures provided by the account servicing payment service provider to the payment service user.
The PSP is obligated to:
(a) 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;
(b) continue to comply with the obligations following from Article 66(3) and Article 67(2) of Directive (EU) 2015/2366 respectively;
(c) 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;
(d) 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;
(e) inform the account servicing payment service provider accordingly.
Crosskey provides a solution which makes ASPSP compliant as specified in
Article 33. The Crosskey solution offers:
- A Proxy based solution which validates the TPP’s and their certificates (QWAC and QSealC).
PRETA validation is also available if needed.
- “Plug-n-Play”, uses existing interfaces (mobile api, internetbank, etc.).
- TPP’s which already have reversed engineered the system interfaces can continue using their solutions without any development/adaption needed.
- The TPP’s only need to change the URL to point to a different address and add the necessary certificates.
- The solution can be available 24/7 or can be initiated by the ASPSP’s at their request.
For more information please contact email@example.com