Contingency mesures for a dedicate interface 

Principle

In order to comply with PSD2 regulation, ASPSP from Groupe BPCE available on this 89C3 API dev portal have setup contingency measures in case of unplanned unavailability of the dedicated API interface.

The principle of this « fallback » solution is explained below:

  Fallback principle BP

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.

Roadmap

Please do find below our estimated roadmap :

Version

Features

Sandbox

Deployment date

89C3 API Dev Portal & Sandbox

Live

Deployment date

89C3 Live API Gateway
v1.0
  • Fallback (*)
 Not applicable October, 2019

(*) Main features :

  • Use the same API dedicated interface endpoint. The list of our banking institutions and the possible values ​​of <bankcode> are specified in the "Limitations" use case ;
  • A parameter (header 'fallback' present or absent) managed directly by the TPP allows do differentiate a « Fallback » request from a dedicated interface PSD2 API request ; 
  • 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.

 

Example

  1. If PSD2 API are not available due to unplanned unavailability or due to systems breakdown (see RTS Art. 33), TPP should use the following request (example for bank establishment 13807 [BPGO]) :

           POST https://www.13807.live.api.89c3.com/stet/psd2/oauth/token

           with :

  • its live eIDAS QWAC certificate
  • fallback:"1" parameter in the header   

              headr fallback 1

       2. If all checks are successful, the online banking login web page will be displayed.

       3. TPP can then apply its proprietary login process using PSU credentials.

For more details on the data exchanged, see the use case "How to retrieve your OAUTH2 access token?".

épingleSee also STET V1.4.0.47 / Part I / section 3.4.3.2 / page 22 
 

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 banking features will be accessible thru fallback mode. As an example, online banking doesn’t propose any e-commerce transactions to customers. PISP could NOT propose this feature in fallback mode.
  • The user of payment services (PSU) must be connected to PSP app. So no AISP batch process is possible.
  • PSD2 also impose a reinforcement of strong customer authentication (SCA, except exemption use cases) for accessing direct online banking services. Therefore fallback mechanism leverage on reinforced PSU online banking authentication procedures and means such as (non exhaustive list) :   
    • Soft token ;
    • OTP SMS ;
    • Physical token (corporate market).