How to address PSD2’s contingency mechanism

How to address PSD2’s contingency mechanism

The RTS, (EU) 2018/389 deadline for account servicing payment service providers (ASPSPs) to be in production is September 14, 2019. ASPSPs includes banks, card issuers and Electronic Money Institutions (EMIs) that provide payment account services.

The RTS defines the requirements for strong customer authentication (SCA) and common and secure open standards of communication (CSC). While much has been written about SCA, one particular article related to CSC has so far received little attention — Article 33, “Contingency measures for a dedicated interface”.

Per Article 33, ASPSPs must provide a contingency mechanism for TPPs to access payment accounts if the requirements for a dedicated interface aren't met by June 14, 2019. Those requirements are then specified in Article 32.

This basically means that ASPSPs must provide a backup interface for TPPs, should the primary, dedicated interface be unavailable. Fortunately, the RTS states that ASPSPs may be exempted by their local Competent Authority from providing a contingency mechanism if the following requirements are met:


  • has a dedicated interface that offers the same level of availability and performance, including support, as the online (web) interface.
  • Has defined transparent key performance indicators and service level targets, at least as stringent as the online (web) interface.
  • monitors the availability and performance of the dedicated interface and publish on their website quarterly statistics on the availability and performance of the dedicated interface and of the online interface (for comparison).
  • has a testing facility, including support, for connection and functional testing to enable authorised PISPs, CBPIIs and AISPs to test. This testing facility should have been made available no later than March 13, 2019.
  • has provided wide usage for at least 3 months (meaning start on June 14, 2019) by PSPs to offer AIS, PIS and for CBPIIs to check confirmation on the availability of funds.
  • accepts supports TPPs eIDAS certificates.
  • have resolved any problems related to the dedicated interface without undue delay.


The observant reader of the RTS will note that Article 33 also states that for contingency purposes, PSPs shall be allowed to access the ASPSPs online (web) interface, assuming they can identify themselves properly. Not only does this create a problem in EU Member States where screen scraping has been banned (e.g. Finland), but allowing PSPs to connect through an online (web) interface is a really bad idea from a security perspective. If a PSP is connecting to an ASPSP through screen scraping, the ASPSPs customers will be sharing login credentials with a third party over which the ASPSP has no control. Since ASPSPs are ultimately liable for customer authentication, the loss of customer credentials could be catastrophic.

A safer, faster and lower cost alternative to provide a contingency mechanism is to utilise a trusted third party that can provide PSD2-as-a-Service.

Check out Token PSD2 to learn how Token can help your ASPSP meet the contingency requirement in time for September 14, 2019.

By Marten Nelson, co-founder & CMO