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

SUP 15C Annex 1D

1Form: Request for exemption from the obligation to set up a contingency mechanism

Where a group of account servicing payment service providers (ASPSPs) operates the same dedicated interface across different banking brands, subsidiaries or products, we require a single request for that dedicated interface.

Where a group of ASPSPs or a single ASPSP operates a number of different dedicated interfaces, e.g. in respect of different banking brands, subsidiaries or products, we require separate requests in respect of each different dedicated interface for which an ASPSP is seeking an exemption.

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

Guidance on completing the form can be found in the Payment Services and Electronic Money Approach Document, Chapter 17.

[Note: see https://www.fca.org.uk/publication/finalised-guidance/fca-approach-payment-services-electronic-money-2017.pdf.]

ASPSPs completing the form should also apply2 the Guidelines on the conditions 2to benefit from an exemption from the2 contingency mechanism2 under article 33(6) of Regulation (EU) 2018/389 (RTS on SCA & CSC) (EBA Guidelines). 2

Form A: exemption criteria

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.

1Form B: (EBA Guideline 6) design of the dedicated interface

Column A

Column B

Column C

Article

Requirement

Description of the functional and technical specifications that the ASPSP has implemented to meet this requirement.

[Where relevant, also reference to the specific market initiative API specification used to meet this requirement and the results of conformance testing attesting compliance with the market initiative standard]

Summary of how the implementation of these specifications fulfils the requirements of the Payment Services Regulations, SCA-RTS and FCA Guidelines2

[Where relevant, any deviation from the specific market initiative API specification which has been designed to meet this requirement]

If not in place at the time of submission of the exemption request, when will the functionality be implemented to meet the requirement (must be before 14 September 2019).

Has a plan for meeting the relevant requirements been submitted to the FCA alongside this form?

Regulation 70 Payment Services Regulations SCA RTS Article 30 2

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

Regulations 68 and 69 Payment Services Regulations SCA RTS Article 30 2

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)2

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

Regulation 67(2) Payment Services Regulations SCA RTS Article 30(1)(c) 2

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

Regulations 69(3)(b) and 70(3)(b) of the Payment Services Regulations2

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.

Regulations 68(3)(c), 69(3)(d) and 70(3)(c) Payment Services Regulations SCA RTS Article 30(1)(a) and 342

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

SCA RTS Article 10(2)(b)2

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

SCA RTS Article 36(5)2

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

SCA RTS Article 30(4)2

Allowing for a change control process

Regulations 67(2), 83(2) and 83(4) Payment Services Regulations2

Allowing for the possibility for an initiated transaction to be cancelled in accordance with the Payment Services Regulations, 2 including recurring transactions

SCA RTS Article 36(2)2

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

Regulation 25(1) Payment Services Regulations 2

Supporting access via technology service providers on behalf of authorised actors

Regulation 100(4) Payment Services Regulations and SCA RTS Article 30(2)2

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

Regulation 70(3)(d) Payment Services Regulations SCA RTS Article 36(1)(a) and 30(1)(b)2

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)2

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

Regulation 100(2) Payment Services Regulations and SCA RTS Article 52

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)2

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 42

Enabling strong customer authentication composed of two different elements

SCA RTS Articles 28 & 352

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

Regulation 100(3) Payment Services Regulations SCA RTS Articles 30(2)(c) and 352

Ensuring security at transport and application level

Regulation 100(3) Payment Services Regulations SCA RTS Articles 22, 35 and 32

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

SCA RTS Article 292

Allowing for traceability

SCA RTS Article 322

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