Contingency measures for a dedicated interface
In order to comply with PSD2 regulations, banks available on this 89C3 API developer portal have setup contingency measures in case of unplanned unavailability of the dedicated API interface.
The principle of this « fallback » solution is explained below:
This fallback mechanism meets PSD2 regulatory requirements (article 33/RTS). It can be used with the same conditions and prerequisites applicable for the dedicated API interface which are specified in the "Eligibility" use case.
Please do find below our estimated roadmap :
89C3 API Dev Portal & Sandbox
89C3 Live API Gateway
(*) Main features :
- Use the same API dedicated interface endpoint. The list of our banking institutions and the possible values of <bkcode> are specified in the "Limitations" use case ;
- A parameter (header 'fallback:1' present or absent) managed directly by the TPP allows do differentiate any « Fallback » request from dedicated interface PSD2 API requests ;
- Use of same TPP eIDAS certificate (QWAC) to be presented for mutual TLS authentication ;
- Use the same PSU authentication procedure and means for accessing online banking services ;
- This fallback solution is always active, even so the dedicated interface API must be used systematically in first priority. Its usage is subject to strict conditions as described in Article 33 of RTS, and can’t be used as the main access for PSD2 features. It will be monitored as such and every abuse will be automatically reported to our national competent authority.
- If PSD2 API are not available due to unplanned unavailability or systems breakdown (see RTS Art. 33), TPP should use the following request with <codetab>=17515 as an example :
- its live eIDAS QWAC certificate
- fallback:"1" parameter in the header
2. If all checks are successful, the TPP will receive in the header of the response with url online (allowing to access banking login web page) as well as the JWT token.
3. TPP can then apply its proprietary login process using PSU credentials.
For more details about POST request, see STET V18.104.22.168 / Part I / section 22.214.171.124 / page 22 or STET V126.96.36.199 / Part I / section 3.4.3
Please note the following constraints which apply on this fallback mechanism :
- No re-use of the API dedicated interface context, neither any of 90-day validity access token generated for AISP role
- Only online internet banking features are used as a reference (excl'd mobile banking features) and are accessible thru the fallback mode. As an example, online banking doesn’t propose any e-commerce transactions to customers, so PISP could NOT propose this feature in fallback mode
- The user of payment services (PSU) must be connected to the TPP PSP app, so no AISP batch process is possible
- PSD2 also imposes a reinforcement of strong customer authentication (SCA) for accessing direct online banking services. Therefore fallback mechanism leverages on reinforced PSU online banking authentication procedures and means such as (non exhaustive list) :
- Soft token
- OTP SMS
- Physical token (corporate market)