SUP 15C Annex 1D Form: Request for exemption from the obligation to set up a contingency mechanism

D1

Financial Registration Number (FRN):

D2

Interface Name/Id

(ASPSPs submitting a return should provide the name or ID used within the PSP to identify the interface being reported on)

D3

If this is a single request for a dedicated interface operated across different banking brands, subsidiaries or products, please provide the names of the different banking brands, subsidiaries or products

D4

If this is a request for one of a number of dedicated interfaces being operated across different banking brands, subsidiaries or products, please identify the group (e.g. banking group) and the brand, subsidiary or product which is the subject of this request

D5

Contact person name

D6

Contact role within organisation

D7

Contact phone number

D8

Contact email address

Service level, availability and performance (EBA Guideline 2)

Q1

Has the ASPSP defined service level targets for out of hours support, monitoring, contingency plans and maintenance for its dedicated interface that are at least as stringent as those for the interface(s) used by its own payment service users (EBA Guideline 2.1)?

Q2

Has the ASPSP put in place measures to calculate and record performance and availability indicators, in line with EBA Guidelines 2.2 and 2.3?

Publication of statistics (EBA Guideline 3)

Q3

Please set out the plan for the quarterly publication of daily statistics on the availability and performance of the dedicated interface and payment service user interface.

Stress testing (EBA Guideline 4)

Q4

Please provide a summary of the results of stress tests undertaken.

Obstacles (EBA Guideline 5)

Q5

Please describe the method(s) of carrying out the authentication procedure(s) of the payment service user that are supported by the dedicated interface

Redirection

Summary of the authentication procedure

Confirm that supporting evidence has been provided

Explanation of why the methods of carrying out the authentication procedure does not create obstacles

Decoupled

Summary of the authentication procedure

Confirm that supporting evidence has been provided

Explanation of why the methods of carrying out the authentication procedure does not create obstacles

Embedded

Summary of the authentication procedure

Confirm that supporting evidence has been provided

Explanation of why the methods of carrying out the authentication procedure does not create obstacles

Other authentication method

Summary of the authentication procedure

Confirm that supporting evidence has been provided

Explanation of why the methods of carrying out the authentication procedure does not create obstacles

Design and testing to the satisfaction of PSPs (EBA Guideline 6) – also complete Form B

Q6

Please provide information on whether, and, if so, how the ASPSP has engaged with AISPs, PISPs and CBPIIs in the design and testing of the dedicated interface.

Q7

Please provide the date (DD/MM/YYYY) from which the ASPSP has made available, at no charge, upon request, the documentation of the technical specification of the dedicated interface specifying a set of routines, protocols, and tools needed by AISPs, PISPs and CBPIIs to interoperate with the systems of the ASPSP.

Q8

Please provide the date (DD/MM/YYYY) on which the ASPSP published a summary of the technical specification of the dedicated interface on its website and a web link.

Q9

Please provide the date (DD/MM/YYYY) on which the testing facility became available for use by AISP, PISPs, CBPIIs (and those that have applied for the relevant authorisation).

Q10

Please provide the number of different PISPs, CBPIIs, AISPs that have used the testing facility.

AISPs

CBPIIs

PISPs

Q11

Please provide a summary of the results of the testing as required.

Wide usage of the interface (EBA Guideline 7)

Q12

Please provide a description of the usage of the dedicated interface in a three month (or longer) period prior to submission of the exemption request.

Q13

Describe the measures undertaken to ensure wide use of the dedicated interface by AISPs, PISPs, CBPIIs.

Resolution of problems (EBA Guideline 8)

Q14

Please describe the systems or procedures in place for tracking, resolving and closing problems, particularly those reported by AISPs, PISPs, and CBPIIs.

Q15

Please explain any problems, particularly those reported by AISPs, PISPs and CBPIIs, that have not been resolved in accordance with the service level targets defined under EBA Guideline 2.1.

PSD2 Article 67 SCA-RTS Article 30 RTS

Enabling AISPs to access the necessary data from payment accounts accessible online

PSD2 Article 65 & 66 SCA-RTS Article 30

Enabling provision or availability to the PISP, immediately after receipt of the payment order, of all the information on the initiation of the payment transaction and all information accessible to the ASPSP regarding the execution of the payment transaction

SCA-RTS Article 30(3)

Conforming to (widely used) standard(s) of communication issued by international or European standardisation organisations

PSD2 Article 64(2) SCA-RTS Article 30(1)(c)

Allowing the payment service user to authorise and consent to a payment transaction via a PISP

PSD2 Article 66(3)(b) and 67(2)(b)

Enabling PISPs and AISPs to ensure that when they transmit the personalised security credentials issued by the ASPSP, they do so through safe and efficient channels.

PSD2 Article 65(2)(c), 66(2)(d) and 67(2)(c) SCA-RTS Article 30(1)(a) and 34

Enabling the identification of the AISP/PISP/CBPII and support eIDAS for certificates

SCA-RTS Article 10(2)(b)

Allowing for no more than 90 days re-authentication for AISPs

SCA-RTS Article 36(5)

Enabling the ASPSPs and AISPs to count the number of access requests during a given period

SCA-RTS Article 30(4)

Allowing for a change control process

PSD2 Article 64(2) and 80(2) and 80(4)

Allowing for the possibility for an initiated transaction to be cancelled in accordance with PSD2, including recurring transactions

SCA-RTS Article 36(2)

Allowing for error messages explaining the reason for the unexpected event or error

PSD2 Article 19(6)

Supporting access via technology service providers on behalf of authorised actors

PSD2 Article 97(5) and SCA-RTS Article 30(2)

Allowing AISPs and PISPs to rely on all authentication procedures issued by the ASPSP to its customers

PSD2 Article 67(2)(d) and 30 (1)(b) and SCA-RTS Article 36(1)(a)

Enabling the AISP to access the same information as accessible to the payment servicer user in relation to their designated payment accounts and associated payment transactions

SCA-RTS Article 36(1)(c)

Enabling the ASPSP to send, upon request, an immediate confirmation yes/no to the PSP (PISP and CBPII) on whether there are funds available

PSD2 Article 97(2) and SCA-RTS Article 5

Enabling the dynamic linking to a specific amount and payee, including batch payments

SCA-RTS Articles 30(2), 32(3), 18(2)(c)(v) and (vi) and 18(3)

Enabling the ASPSP to apply the same exemptions from SCA for transactions initiated by PISPs as when the PSU interacts directly with the ASPSP

SCA-RTS Article 4

Enabling strong customer authentication composed of two different elements

SCA-RTS Articles 28 & 35

Enabling a secure data exchange between the ASPSP and the PISP, AISP and CBPII mitigating the risk for any misdirection of communication to other parties

PSD2 Article 97(3) SCA-RTS Articles 30(2)(c) and 35

Ensuring security at transport and application level

PSD2 Article 97(3) SCA-RTS Articles 22, 35 and 3

Supporting the needs to mitigate the risk for fraud, have reliable and auditable exchanges and enable providers to monitor payment transactions

SCA-RTS Article 29 SCA RTS Article 29

Allowing for traceability

SCA-RTS Article 32 SCA RTS Article 32

Allowing for the ASPSP’s dedicated interface to provide at least the same availability and performance as the user interface