If a system breakdown or unexpected unavailability of the PSD2 APIs occurs, the contingency measures are:
- communication of the openness of the contingency measures through mailing,
- openness of the fallback mechanism.
The fallback mechanism is based on the standard web application of the bank, with a specific login procedure, described below.
The URL of the bank web applications to use are:
- Crédit Mutuel de Bretagne : https://mon.cmb.fr
- Crédit Mutuel du Sud-Ouest : https://mon.cmso.com
- Fortuneo : https://mabanque.fortuneo.fr/
- Arkéa Banque Privée : https://m.arkeabanqueprivee.fr
- Arkéa Banque Entreprises et Institutionnels : https://mabanque.arkea-banque-ei.com
- Arkéa Banking Services : https://www.arkea-banking-services.com
- BPE : https://comptes.bpe.fr
- Allianz Banque : https://www.allianzbanque.fr
- Axa Banque : https://banque.axa.fr
When the PSD2 API availability is restored, the fallback mechanism is closed.
Login procedure for the fallback mechanism
This login procedure is based on the STET proposal which is basically explained here after. For the bank, the aim is to identify the TPP who access to the PSU accounts.
Technically, the procedure consists to call the usual login request to the web application, in which the TPP adds supplementary headers to identify itself.
These extra-headers are:
- tpp-signature-timestamp, containing the date in format ISO 8601 (see also RFC 3339)
- digest containing the signature of the body as described in the RFC 3230
- tpp-etsi-authorization-number, containing the TPP unique identifier as expressed in eIDAS documentation ETSI TS 119 495
- signature, as specified by the draft http-signature with following specificities:
the signed headers are the extra http headers: tpp-signature-timestamp, digest and tpp-etsi-authorization-number
the algorithm is RSA-SHA256
the QSealC of the TPP is used to sign
the key-id is the url of the public certificate of this QSealC (as described in the STET PSD2 API documentation - chapter 3.5)
A supplementary header is mandatory, named arkea-psd2-clientid. It must contain the client-id used by the TPP.
How to test this login procedure?
An URL permits to test if the login procedure. This sandbox is common to the Arkea group. The request must contain the headers presented before.
POST https://api.arkea.com/psd2-fallback-sandbox/<any path> tpp-signature-timestamp: <time> tpp-etsi-authorization-number: <tpp id> digest: <hash of the body> signature: keyId="...",headers="<list of signed headers...>",algorithm="rsa-sha256",signature="<signature...>" arkea-psd2-clientid: <client_id> <body of the request>
As the login method depends on the targeted bank web application, the sandbox supports any path and any content. The path and the content (normally the PSU credentials) are not checked.
This endpoint controls the presence of the extra-http headers, get the public certificate thanks to the QSealC URL, checks the signature.
The body of the response contains the result of the fallback signature control.
Note: there is no real access token returned by this endpoint.
How to test this login procedure without eIDAS certificates?
An URL permits to test if the login procedure without the eIDAS certificates control, but other controls are done. You have just to use "/easytest" as below:
POST https://api.arkea.com/psd2-fallback-sandbox/easytest tpp-signature-timestamp: <time> tpp-etsi-authorization-number: <tpp id> digest: <hash of the body> signature: keyId="...",headers="<list of signed headers...>",algorithm="rsa-sha256",signature="<signature...>" arkea-psd2-clientid: <client_id> <body of the request>
Login and SCA processes for fallback and web applications
Detailed information on these login and SCA processes will be available on demand from 25 July 2019. Regarding the level of sensitivity of these data, the access to the document is restricted to the regulated entities (AISP, PISP, CBPII). The regulated entities could ask for the document through the contact form.