Form: 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 apply the Guidelines on the conditions to benefit from an exemption from the contingency mechanism 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. | ||||
Form 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 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? |
| Regulation 70 Payment Services Regulations SCA RTS Article 30 | Enabling AISPs to access the necessary data from payment accounts accessible online | |||
| Regulations 68 and 69 Payment Services Regulations 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 | |||
| Regulation 67(2) Payment Services Regulations SCA RTS Article 30(1)(c) | 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 Regulations | 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 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 | |||
| Regulations 67(2), 83(2) and 83(4) Payment Services Regulations | Allowing for the possibility for an initiated transaction to be cancelled in accordance with the Payment Services Regulations, including recurring transactions | |||
| SCA RTS Article 36(2) | Allowing for error messages explaining the reason for the unexpected event or error | |||
| Regulation 25(1) Payment Services Regulations | Supporting access via technology service providers on behalf of authorised actors | |||
| Regulation 100(4) Payment Services Regulations and SCA RTS Article 30(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) | 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 | |||
| Regulation 100(2) Payment Services Regulations 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 | |||
| Regulation 100(3) Payment Services Regulations SCA RTS Articles 30(2)(c) and 35 | Ensuring security at transport and application level | |||
| Regulation 100(3) Payment Services Regulations 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 |