SUP 15C Annex 1D Form: Request for exemption from the obligation to set up a contingency mechanism
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 comply with the Guidelines on the conditions to be met to benefit from an exemption from contingency measures under article 33(6) of Regulation (EU) 2018/389 (RTS on SCA & CSC) (EBA Guidelines).
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 PSD2, SCA-RTS and FCA Guidelines [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? |
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 |
Allowing for traceability |
|||
SCA-RTS Article 32 |
Allowing for the ASPSP’s dedicated interface to provide at least the same availability and performance as the user interface |