Contingency Mesures for a Dedicated Interface 

Principle

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:

 BBCP fallback UK

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

89C3 API Dev Portal & Sandbox

Live

Deployment

89C3 Live API Gateway

v1.0

     Fallback (*)

Not applicable End of Septembre 2019

(*) Main features :

  • Use the same API dedicated interface endpoint as described in the "Limits" 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.

 

 

Example

  1. If PSD2 API are not available due to unplanned unavailability or systems breakdown (see RTS Art. 33), TPP should use the following request :

           POST https://www.12579.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.

 

 

épingleFor more details about POST request, see 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 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. PISP could NOT propose this feature in fallback mode.
  • The user of payment services (PSU) must be connected to the PSP app. So no AISP batch (4 x / day) process is possible.
  • PSD2 also imposes a reinforcement of strong customer authentication (SCA) for accessing direct online banking services. Therefore this 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).