Version 4





Change Description

The changes to this version of the calendar are:

  • Clarification around 'documentation of the contingency measures' from the EBA API WG 5th set of clarifications published 14 Aug 2019 and
  • Clarification on ASPSPs implementation of RTS Article 10 SCA Exemption
  • Revision of the 'FAPI Compliant' question in order to provide greater clarity to TPPs.  The 'FAPI Compliant' question has been replaced by 'Security Profile' and 'Security Profile Certification'.

Below is an extract from the EBA Working Group.  For the full set of questions and clarifications, please see

EBA responses to issues XXI to XXVI raised by participants of the EBA Working Group on APIs under PSD2

Published on 14 August 2019

Disclaimer: The information contained in the table below is of an informational nature and has no binding force in law. Only the Court of Justice of the European Union can provide definitive
interpretations of EU legislation. The information may factually reflect a given challenge faced by the industry, reiterate the European Banking Authority’s views that have been previously
published, reflect discussions that have been held on the practical implementation of legal requirements, or may include examples of industry practices. The information is also without prejudice
to any future decisions made or views expressed by the European Banking Authority.

IDTopicDescriptionEBA Response
XXVDocumentation of the contingency mechanism in Art. 33(4) RTS

Several API-WG participants requested clarifications whether ASPSPs are
required to document the contingency access in Art. 33(4), and if so, by when. 

TPPs expressed concerns that many ASPSPs have not yet documented how the
contingency mechanism will be implemented and that they do not have
visibility on how strong customer authentication (SCA) will be carried out by
ASPSPs from 14 September where access is made through the contingency
mechanism in Art. 33(4) RTS. Some TPPs raised concerns that this may lead to a
disruption of TPPs services on 14 September 2019.

Article 33(1) RTS provides that “Account servicing payment service providers shall include, in the design of the dedicated interface, a strategy and plans for contingency measures for the event that the interface does not perform in compliance with Article 32, that there is unplanned unavailability of the interface and that there is a systems breakdown”.

Article 33(2) RTS provides that the “Contingency measures shall include communication plans to inform payment service providers making use of the dedicated interface of measures to restore the system and a description of the immediately available alternative options payment service providers may have during this time”. Furthermore, Art. 33(5) RTS provides, for the purposes of the contingency
mechanism referred to in Article 33(4), that ASPSPs ensure that TPPs can be identified and can rely on the authentication procedures provided by the ASPSP to its PSUs.

The RTS do not provide a deadline by which ASPSPs should document the access through the contingency mechanism. Nevertheless, in accordance with Art. 33(1) and (2) referred to above, ASPSPs shall set out a strategy and plans for the contingency measures and communications plans to inform TPPs of the “immediately available alternative options” through which they can continue providing their services while the API is restored. Such strategy and communication plans must be provided also in relation to the use of the contingency mechanism in Article 33(4) of the RTS, which is one of the contingency measures that ASPSPs are required to put in place. To this end, ASPSPs that do not receive an exemption in accordance with Art. 33(6), or whose exemption has been revoked by the national competent authority (NCAs) in accordance with Art. 33(7) RTS, should include in such strategy and communication plans a
description of the contingency mechanism and of the 6 authentication procedures on which TPPs can rely under Art. 33(5) RTS.

Article 10

RTS Article 10

RTS Article 10 states:

1. Payment service providers shall be allowed not to apply strong customer authentication, subject to compliance with the requirements laid down in Article 2 and to paragraph 2 of this Article and, where a payment service user is limited to accessing either or both of the following items online without disclosure of sensitive payment data:

(a) the balance of one or more designated payment accounts;
(b) the payment transactions executed in the last 90 days through one or more designated payment accounts.

2. For the purpose of paragraph 1, payment service providers shall not be exempted from the application of strong customer authentication where either of the following condition is met:

(a) the payment service user is accessing online the information specified in paragraph 1 for the first time;
(b) more than 90 days have elapsed since the last time the payment service user accessed online the information specified in paragraph 1(b) and strong customer authentication was applied.

Please is How the OBIE Standard can be used in relation to RTS Article 10 for further clarification

Questionnaire SectionQuestionQ&A
PSD2Contingency MeasuresPlease specify the location of the guidance that explains your strategy and plans for when your dedicated interface is unavailable.  This should be a URL to your dev portal or artefact that provides TPPs with the information they require.
PSD2Maximum time period after authentication? (Article 10)

Please specify how long the AISP has from the time when they receive the access token (after PSU authentication).  This is the period the AISP must submit their first request before SCA will be re-applied to endpoints NOT exempt of SCA under Article 10.  ASPSPs should consider that this timeline is consistent with the time limit applied by the ASPSP in the existing online PSU interface (i.e. before the PSU is logged out)

Please specify the time period. (For example, 1 hour) 

PSD2Endpoints exempt of SCA under Article 10

Please specify which AIS endpoints will be exempt from SCA under Article 10. (delete as appropriate): Accounts, Balances, Transactions, Beneficiaries, Direct Debits, Standing Orders, Products, Offers, Parties, Scheduled Payments, Statements

Implementation'FAPI Compliant?' Question removed.
ImplementationSecurity Profile?Please specify where you support the Open Banking Security Profile or OIDC.  Please respond 'Open Banking', 'FAPI' or 'Other'.
ImplementationSecurity Profile Certification?Please specify where you have achieved certification with the Security Profile authority.  Please respond, 'Yes' or 'No'.