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.
5. For this purpose, account servicing payment service providers 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. Where the payment service providers referred to in Article 30(1) make use of the interface referred to in paragraph 4 they 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;
- 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;
- inform the account servicing payment service provider accordingly.
The following section describes the Societe Generale Corporate platform fallback solution.
How to use our fallback solution?¶
Access by submitting first an access to a guestbook¶
Societe Generale Fallback approach uses a guestbook to register accessing TPPs. A TPP needs to register successfully in a guestbook by providing their certificate before he accesses the Societe Generale’s Corporate platform fallback system. The access can be created via the Societe Generale fallback API. Logging of the fallback access is the TPP responsibility. This fallback solution will be based on the TPP Qwac certificate.
The following figure gives a high-level description of the infrastructure.
The provided infrastructure, allows to prove the TPP’s identity by providing the requisite certificates during the guestbook entry. TPP will have to follow this specific process each time a fallback access is requested, namely when Societe Generale Corporate API are not available or do not perform as they should (as requested by PSD2 and EBA RTS).
For related transactions, the TPP will store in the guestbook details allowing to identify each of them.
At least a daily entry in the guestbook is expected from the TPP.
Rules to use the fallback solution¶
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 66(2)(c) PSD2 requires AISPs to identify themselves towards the ASPSP “for each communication session”. That is why the Fallback API must be called before each client session opened by the TPP
You must also indicate the PSU identity (known by the PSU) and the service required (AISP, PISP, PIISP) in each call
To maximize traceability, you must keep your usual User Agent and your IP address
Strong Customer Authentication in our fallback¶
Secure access
3S Key
