Response to consultation on 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)
Go back
UK Finance is a trade association representing nearly 300 of the leading firms providing finance, banking, markets and payments-related services in or from the UK. UK Finance has been created by combining the activities of the Asset Based Finance Association, the British Bankers’ Association, the Council of Mortgage Lenders, Financial Fraud Action UK, Payments UK and the UK Cards Association.
Our members are large and small, national and regional, domestic and international, corporate and mutual, retail and wholesale, physical and virtual, banks and non-banks. Our members' customers are individuals, corporates, charities, clubs, associations and government bodies, based in the UK and overseas, served domestically and cross-border. These customers access a wide range of financial and advisory products and services, essential to their day-to-day activities, from our members. The interests of our members’ customers are at the heart of our work.
UK Finance welcome the clarity the EBA is giving on availability and performance of dedicated interfaces.
Overall, our members are clear that they will designate their dedicated interface as a critical business process as they already do for the customer interface/proprietary channel. Therefore, the dedicated interface will be subject to the same high standards of uptime and availability as an online banking interface. Key Performance Indicators (KPIs) to monitor the performance of the dedicated interface will not necessarily match with the KPIs currently in use to monitor the availability and performance of Payment Service User (PSU) channels (eg online banking) as provided by an ASPSP. Comparison of availability and performance should be at channel level i.e. the channel chosen by the client, as it is not appropriate to compare API availability and performance with the best performing PSU interface.
This is because, for instance, mobile banking interfaces may have limited options compared with the full range available via online banking, and as such are vastly different products. Furthermore, loading a mobile app page versus sharing several months’ worth of data with an AISP is not a fair comparison. For commercial clients, service levels and availabilities differ in relation to their individual agreement with the provider.
We agree with the EBA’s rationale that uptime and downtime is a metric that is directly comparable (at least in most cases) between the dedicated and PSU interfaces and also agree that the transparency on the functioning of the dedicated interface.
As a result, whilst the two should be separated and monitored separately, we propose that this is taken into account in the monitoring approach adopted by ASPSPs. This will allow ASPSPs to achieve comparable performances between the dedicated interface and PSU channels but only after a considerable usage period of the dedicated interface. Each ASPSP channel/segment has its own SLA/KPI, therefore the comparison of the API performance can be done only with the specific channel/segment which should be selected by the ASPSP based on the brand/channel.
If the EBA would like to specify high-level metrics which could be applies across the industry, UK Finance suggest the following:
• Number of critical impacts and incidents, (outage based on a monthly figure) underpinned by a series of service levels including serviceability (unplanned disruption), availability (planned service disruption), the service support
• Number of critical impacts longer than 120 minutes
• Total outage time as regards incidents
• Mean recovery time as regards incidents
• Performance service levels such as page load time targets, sign off/sign on targets.
We are of the view that the fact that the maximum number of seconds (as defined in the KPI) has been reached or exceeded, can not in itself be seen as a confirmation that the ASPSP’s dedicated interface is down. There is a key link between the volume of requests and the ability to cater to those requests in a short period of time. We are therefore of the view that performance of the API should then be considered in context of traffic volume and variability over time (noting that Article 33(7) calls for performance conditions to be in default for more than 2 consecutive calendar weeks before revoking an exemption). To put it another way, response time does not always guarantee performance. The performance of the dedicated interface should be averaged over time.
Linked to the above point, an ASPSP can only start counting the seconds (in relation to the down time i.e. 5 times 30 seconds), as soon as it has received a request and hence network transit time or related issues should be excluded from this downtime calculation as ASPSPs cannot measure a request that it has not yet received. Moreover, it should be noted that good functioning of the ASPSP API cannot be confirmed in the following cases:
• Problems with internet connection (ISP) via the third party or the ASPSP.
• Any issues related to a technical service provider (TSP) in the chain, in other words, where there is a fourth party involved.
We are of the view that uptime and downtime for the purposes of measuring the dedicated interface should not include planned maintenance periods, provided that planned maintenance periods are not overly onerous and happen at pre-notified times. We strongly suggest reformulating Guidelines 2.3 a. & b. to cover for the response time per request, as the process might require multiple steps/requests to receive all information (e.g. account information for large amount of accounts).
Regarding availability of services (uptime) we suggest distinguishing primetime (06.00-01.00) from non-primetime (01.00 – 06.00). Availability during primetime is considered much more important to the market in terms of user experience and overall business value, and therefore more critical than it is during non-primetime hours.
By making this distinction an ASPSP must be able to prove that at least during primetime the calculation of uptime and downtime is similar for the dedicated interface compared to the PSU interface. In non-primetime an ASPSP should be able to explain why maintenance potentially has – in some cases – led to different uptime and downtime. This approach then also eliminates the need for a distinction between planned and unplanned downtime.
The Guidelines indicate that the service level information should be published. We would stress strongly that this data should not be publicly available, due to the commercial sensitivities. This is particularly in light of some of the broad definitions used for “downtime”, which could lead to ASPSPs being compared when their metrics are not identical. This information should be held by the NCAs, in confidence.
Finally, the EBA should take into account that most ASPSPs will be operating multiple interfaces or channels (e.g. one entity operating with corporate, retail and commercial channels) at the same time, depending on brand, and some ASPSPs will be operating tens of interfaces concurrently. We therefore think it is unreasonable for ASPSPs to provide daily figures regarding their uptime, and instead suggest that quarterly figures and averages would provide for a better measure of uptime and downtime and give more information to the ASPSP performance over a period, rather than relying on short term metrics. These averages should be calculated for each interface separately, in the case of multiple interfaces, and mobile banking should be considered as separate. Moreover, we believe the RTS on SCA and CSC (article 32 (4)) does not require the reporting of daily statistics.
When stress testing to gain an exemption, UK Finance thinks it is reasonable for an ASPSP to use their own forecasts regarding take up of the dedicated interface. We believe that the measure of performance should be based on averages to allow for a tolerance for peak and off-peak responses.
UK Finance would welcome some further guidance from the EBA on stress testing to ensure that there is a similar test applied across Europe to ensure as many ASPSPs as possible are encouraged to seek an exemption and will therefore build good dedicated interfaces. We also request guidance on whether exemptions issued to PSPs apply across the EEA or are specific to each Member State (i.e. can an exemption granted by the FCA be used by the same organisation for their activities in Italy). UK Finance believe that ASPSPs who implement one dedicated interface across PSU interfaces in multiple Member States will only have to apply for the exemptions for that dedicated interface once with the NCA in the Member State where it has its registered head office. It is only the case that ASPSPs are required to seek an exemption in more than one Member State if it has implemented a different API, or if the legal entity is different (e.g. a subsidiary rather than a branch).
Guideline 5.1 a. refers to ‘method of access’ to address what the EBA opinion of 13 June refers instead to ‘authentication procedure’ as per the ‘methods of carrying out authentication procedure of the PSU trough a dedicated interface, and API in particular, namely redirection, embedded approach, and decoupled approach’. We suggest aligning the wording of the two texts to ensure legal certainty. Any further interpretation of such provisions should be left to Competent Authorities.
The EBA states that where the ASPSP has put in place only one method of access, they must provide an explanation of the reasons why this method of access is not an obstacle as referred to in Article 32(3) RTS and how this method of access supports all authentication methods provided by the ASPSP to the PSU. Can the EBA clarify if this means that this explanation doesn’t need to be provided to an NCA if more than one method of access is provided e.g. redirection and decoupled.
Further detail on ASPSPs considering customer experience would be appreciated.
The EBA has clarified that the provision of a Yes/No answer must be provided to PISPs. This has not been explicitly stated in the RTS (mentions ‘payment service providers’) and hasn’t been mandated in PSD2 as Article 65 only covers ‘payment service provider issuing card-based payment instruments’. Providing the Yes/No answer is subject to the PSU having given consent to the ASPSP before the first request is received from a specific CBPII. Could the EBA clarify whether a different consent mechanism would apply for PISPs requesting a yes/no answer or whether prior confirmation from the PSU to the ASPSPs also extends to PISPs.
We would welcome further detail on what is considered as an additional check on consent. UK Finance are of the view that re-presenting scopes and duration to the PSU is not a check on consent as this happens in a normal scenario where the customer confirms their normal amount and payee or that they would like information being shared. We believe that consent is a matter for the AISP and PISP and it is the responsibility of the third party to agree explicit and GDPR-compliant consent with the PSU. This being said, the ASPSP has a duty of care to confirm what is being shared or executed before handing over data or initiating a payment.
The process of conformance testing will allow for firms to either self-test against forecast criteria, or for independent firms to review them. UK Finance believe that this form of testing would provide the best solution, and that with industry collaboration, API initiatives should and will be able to provide the tools for such testing to be undertaken. The firm could then provide their results to their NCA, as a basis for an exemption.
We are of the strong view that the requirements around design and testing are sufficiently met if the specifications (i.e. the design) meets these functional requirements (by the associated dates) that design satisfaction would be met. In other words, we see that “design” satisfaction is met if a given ASPSP meets the agreed API specification (e.g. the Open Banking standards).
We assume that testing requirements are not deemed to be a ‘live environment’, in that there will be no real customer data used However, for those already operating in a live system, such as those under the CMA9 market remedies order (i.e. UK Open Banking), may be testing in that live context and in a mixed form of live data and test data; we assume that in the case of live testing with live data, this is permissible, instead of requiring implementation of a mandatory sandbox test, where live transactions are already common. Clarity on this would be appreciated.
In relation to Guideline 7.2 (communication efforts launched by ASPSPs to inform the market on the availability of the testing facilities), UK Finance would suggest that the evidence the ASPSP are requested to provide is limited to publications on the ASPSPs’ websites or channels. In addition, we are of the view that it would be useful to have a unique EU registry / EBA website where PISP / AISP / CBPIIs could easily identify at European level all ASPSPs that are available for testing.
We further believe that some guidance to NCA’s would be helpful to ensure there is a consistent approach across Member States. This should focus both on what constitutes “widely available” or widely publicised, and regarding what information ASPSPs need to provide to their NCA.
We believe that an ASPSP can appeal their NCA’s decision regarding an exemption if an exemption request is rejected. This is normal practice for supervisory processes and we believe that the process should also allow for a continuing conversation between the NCA and ASPSP should they not meet the full requirements in July 2019, in this case, the ASPSP wouldn’t be required to implement the contingency mechanism, provided that the exemption is attainable within a reasonable period of time (e.g. six months).
This process needs to be practical and take into account, for example if an ASPSP has implemented a well-functioning API for the majority of PSD2 requirements, but that certain functionality still needs to be implemented, for example, non-SEPA international payments (e.g. SWIFT payments) or if a particular brand in a group has not implemented on time, but the rest of the group has.
It would be beneficial for the EBA to give further consideration for how some ASPSPs could gain an exemption in future. If this is a newly created ASPSP or an ASPSP who was not aware of their regulatory and legal requirements under PSD2. If a firm applies for an exemption (either as a new PSP or one unaware of their obligations), we strongly feel these firms should still be able to seek an exemption without the need to implement a ‘customer interface with identification’.
As a further point, the EBA consultation refers to Guidelines on the conditions to be met to benefit from an exemption from contingency measures under RTS Article 33(6). UK Finance are of the view, this could be misleading as there is a clear distinction between:
i. The obligation for ASPSPs to have in place ‘contingency measures’ (such as a strategy and communication plans) in line with RTS Articles 33(1) and (2) and
ii. Exemption from having to provide the ‘contingency mechanism’ referred to in RTS Articles 33(4), (5) and (6).
Being granted an exemption means the ASPSP doesn’t need to build the contingency mechanism but the ASPSP must still have in place the contingency measures. We do not believe that contingency measures are an ‘interface’, as this is a separate requirement.
Question 1: Do you agree with the EBA’s assessments on KPIs and the calculation of uptime and downtime and the ASPSP submission of a plan to publishing statistics, the options that EBA considered and progressed or discarded, and the requirements proposed in Guideline 2 and 3? If not, please provide detail on other KPIs or calculation methods that you consider more suitable and your reasoning for doing so.
UK Finance welcome the opportunity to comment on the EBA’s consultation on draft 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) which relates to PSD2.UK Finance is a trade association representing nearly 300 of the leading firms providing finance, banking, markets and payments-related services in or from the UK. UK Finance has been created by combining the activities of the Asset Based Finance Association, the British Bankers’ Association, the Council of Mortgage Lenders, Financial Fraud Action UK, Payments UK and the UK Cards Association.
Our members are large and small, national and regional, domestic and international, corporate and mutual, retail and wholesale, physical and virtual, banks and non-banks. Our members' customers are individuals, corporates, charities, clubs, associations and government bodies, based in the UK and overseas, served domestically and cross-border. These customers access a wide range of financial and advisory products and services, essential to their day-to-day activities, from our members. The interests of our members’ customers are at the heart of our work.
UK Finance welcome the clarity the EBA is giving on availability and performance of dedicated interfaces.
Overall, our members are clear that they will designate their dedicated interface as a critical business process as they already do for the customer interface/proprietary channel. Therefore, the dedicated interface will be subject to the same high standards of uptime and availability as an online banking interface. Key Performance Indicators (KPIs) to monitor the performance of the dedicated interface will not necessarily match with the KPIs currently in use to monitor the availability and performance of Payment Service User (PSU) channels (eg online banking) as provided by an ASPSP. Comparison of availability and performance should be at channel level i.e. the channel chosen by the client, as it is not appropriate to compare API availability and performance with the best performing PSU interface.
This is because, for instance, mobile banking interfaces may have limited options compared with the full range available via online banking, and as such are vastly different products. Furthermore, loading a mobile app page versus sharing several months’ worth of data with an AISP is not a fair comparison. For commercial clients, service levels and availabilities differ in relation to their individual agreement with the provider.
We agree with the EBA’s rationale that uptime and downtime is a metric that is directly comparable (at least in most cases) between the dedicated and PSU interfaces and also agree that the transparency on the functioning of the dedicated interface.
As a result, whilst the two should be separated and monitored separately, we propose that this is taken into account in the monitoring approach adopted by ASPSPs. This will allow ASPSPs to achieve comparable performances between the dedicated interface and PSU channels but only after a considerable usage period of the dedicated interface. Each ASPSP channel/segment has its own SLA/KPI, therefore the comparison of the API performance can be done only with the specific channel/segment which should be selected by the ASPSP based on the brand/channel.
If the EBA would like to specify high-level metrics which could be applies across the industry, UK Finance suggest the following:
• Number of critical impacts and incidents, (outage based on a monthly figure) underpinned by a series of service levels including serviceability (unplanned disruption), availability (planned service disruption), the service support
• Number of critical impacts longer than 120 minutes
• Total outage time as regards incidents
• Mean recovery time as regards incidents
• Performance service levels such as page load time targets, sign off/sign on targets.
We are of the view that the fact that the maximum number of seconds (as defined in the KPI) has been reached or exceeded, can not in itself be seen as a confirmation that the ASPSP’s dedicated interface is down. There is a key link between the volume of requests and the ability to cater to those requests in a short period of time. We are therefore of the view that performance of the API should then be considered in context of traffic volume and variability over time (noting that Article 33(7) calls for performance conditions to be in default for more than 2 consecutive calendar weeks before revoking an exemption). To put it another way, response time does not always guarantee performance. The performance of the dedicated interface should be averaged over time.
Linked to the above point, an ASPSP can only start counting the seconds (in relation to the down time i.e. 5 times 30 seconds), as soon as it has received a request and hence network transit time or related issues should be excluded from this downtime calculation as ASPSPs cannot measure a request that it has not yet received. Moreover, it should be noted that good functioning of the ASPSP API cannot be confirmed in the following cases:
• Problems with internet connection (ISP) via the third party or the ASPSP.
• Any issues related to a technical service provider (TSP) in the chain, in other words, where there is a fourth party involved.
We are of the view that uptime and downtime for the purposes of measuring the dedicated interface should not include planned maintenance periods, provided that planned maintenance periods are not overly onerous and happen at pre-notified times. We strongly suggest reformulating Guidelines 2.3 a. & b. to cover for the response time per request, as the process might require multiple steps/requests to receive all information (e.g. account information for large amount of accounts).
Regarding availability of services (uptime) we suggest distinguishing primetime (06.00-01.00) from non-primetime (01.00 – 06.00). Availability during primetime is considered much more important to the market in terms of user experience and overall business value, and therefore more critical than it is during non-primetime hours.
By making this distinction an ASPSP must be able to prove that at least during primetime the calculation of uptime and downtime is similar for the dedicated interface compared to the PSU interface. In non-primetime an ASPSP should be able to explain why maintenance potentially has – in some cases – led to different uptime and downtime. This approach then also eliminates the need for a distinction between planned and unplanned downtime.
The Guidelines indicate that the service level information should be published. We would stress strongly that this data should not be publicly available, due to the commercial sensitivities. This is particularly in light of some of the broad definitions used for “downtime”, which could lead to ASPSPs being compared when their metrics are not identical. This information should be held by the NCAs, in confidence.
Finally, the EBA should take into account that most ASPSPs will be operating multiple interfaces or channels (e.g. one entity operating with corporate, retail and commercial channels) at the same time, depending on brand, and some ASPSPs will be operating tens of interfaces concurrently. We therefore think it is unreasonable for ASPSPs to provide daily figures regarding their uptime, and instead suggest that quarterly figures and averages would provide for a better measure of uptime and downtime and give more information to the ASPSP performance over a period, rather than relying on short term metrics. These averages should be calculated for each interface separately, in the case of multiple interfaces, and mobile banking should be considered as separate. Moreover, we believe the RTS on SCA and CSC (article 32 (4)) does not require the reporting of daily statistics.
Question 2: Do you agree with the EBA’s assessments on stress testing and the options it considered and progressed or discarded, and the requirements proposed in Guideline 4? If not, please provide your reasoning.
UK Finance welcomes the EBA proposal around stress testing, although it would be beneficial to get further clarification on whether there are specific requests for the execution of stress tests. We would welcome clarification on the format and content of the required testing results documentation and how this should be submitted and/or made available. We agree with the EBA that stress tests should be performed by the ASPSP and we also believe that this should only be conducted by the ASPSP to obtain an exemption or to reactivate it in case it was revoked.When stress testing to gain an exemption, UK Finance thinks it is reasonable for an ASPSP to use their own forecasts regarding take up of the dedicated interface. We believe that the measure of performance should be based on averages to allow for a tolerance for peak and off-peak responses.
UK Finance would welcome some further guidance from the EBA on stress testing to ensure that there is a similar test applied across Europe to ensure as many ASPSPs as possible are encouraged to seek an exemption and will therefore build good dedicated interfaces. We also request guidance on whether exemptions issued to PSPs apply across the EEA or are specific to each Member State (i.e. can an exemption granted by the FCA be used by the same organisation for their activities in Italy). UK Finance believe that ASPSPs who implement one dedicated interface across PSU interfaces in multiple Member States will only have to apply for the exemptions for that dedicated interface once with the NCA in the Member State where it has its registered head office. It is only the case that ASPSPs are required to seek an exemption in more than one Member State if it has implemented a different API, or if the legal entity is different (e.g. a subsidiary rather than a branch).
Question 3: Do you agree with the EBA’s assessments on monitoring? If not, please provide your reasoning.
UK Finance welcomes the EBA’s approach to assessments and monitoring.Question 4: Do you agree with the EBA’s assessments on obstacles, the options it considered and progressed or discarded, and the requirements proposed in Guideline 5? If not, please provide your reasoning.
UK Finance support the EBA’s assessments on obstacles. In particular UK Finance strongly agree with the EBA that ‘redirection’ is not in itself an obstacle. We are of the strong view that a well implemented dedicated interface which makes use of redirection is best for the customer, the ASPSP and the best way to encourage new market entrants to create AIS and PIS services. We understand that the EBA does not wish to be overly prescriptive to allow for market solutions and a ‘common sense’ approach, which we support, but some added clarity on what type of redirection is permissible would benefit both ASPSPs and AISPs/PISPs.Guideline 5.1 a. refers to ‘method of access’ to address what the EBA opinion of 13 June refers instead to ‘authentication procedure’ as per the ‘methods of carrying out authentication procedure of the PSU trough a dedicated interface, and API in particular, namely redirection, embedded approach, and decoupled approach’. We suggest aligning the wording of the two texts to ensure legal certainty. Any further interpretation of such provisions should be left to Competent Authorities.
The EBA states that where the ASPSP has put in place only one method of access, they must provide an explanation of the reasons why this method of access is not an obstacle as referred to in Article 32(3) RTS and how this method of access supports all authentication methods provided by the ASPSP to the PSU. Can the EBA clarify if this means that this explanation doesn’t need to be provided to an NCA if more than one method of access is provided e.g. redirection and decoupled.
Further detail on ASPSPs considering customer experience would be appreciated.
The EBA has clarified that the provision of a Yes/No answer must be provided to PISPs. This has not been explicitly stated in the RTS (mentions ‘payment service providers’) and hasn’t been mandated in PSD2 as Article 65 only covers ‘payment service provider issuing card-based payment instruments’. Providing the Yes/No answer is subject to the PSU having given consent to the ASPSP before the first request is received from a specific CBPII. Could the EBA clarify whether a different consent mechanism would apply for PISPs requesting a yes/no answer or whether prior confirmation from the PSU to the ASPSPs also extends to PISPs.
We would welcome further detail on what is considered as an additional check on consent. UK Finance are of the view that re-presenting scopes and duration to the PSU is not a check on consent as this happens in a normal scenario where the customer confirms their normal amount and payee or that they would like information being shared. We believe that consent is a matter for the AISP and PISP and it is the responsibility of the third party to agree explicit and GDPR-compliant consent with the PSU. This being said, the ASPSP has a duty of care to confirm what is being shared or executed before handing over data or initiating a payment.
Question 5: Do you agree with the EBA’s assessments for design and testing, the options it considered and progressed or discarded, and the requirements proposed Guideline 6? If not, please provide your reasoning.
UK Finance broadly agree with and support the EBA’s assessments for design and testing. However, we strongly believe that the testing environment should be based on ‘conformance testing’ (also known as compliance testing). This process verifies that a product performs in line with specific and pre-set standards, the pre-set standards should be based on an ASPSP’s own measures and forecasts regarding take up of the dedicated interface. We also believe that the measure of performance should be based on averages to allow for a tolerance for peak and off-peak responses. This conformance testing should then determine whether the named process, product or service complies with the ASPSPs legal and own set of requirements (whether technical standard, regulation etc)The process of conformance testing will allow for firms to either self-test against forecast criteria, or for independent firms to review them. UK Finance believe that this form of testing would provide the best solution, and that with industry collaboration, API initiatives should and will be able to provide the tools for such testing to be undertaken. The firm could then provide their results to their NCA, as a basis for an exemption.
We are of the strong view that the requirements around design and testing are sufficiently met if the specifications (i.e. the design) meets these functional requirements (by the associated dates) that design satisfaction would be met. In other words, we see that “design” satisfaction is met if a given ASPSP meets the agreed API specification (e.g. the Open Banking standards).
We assume that testing requirements are not deemed to be a ‘live environment’, in that there will be no real customer data used However, for those already operating in a live system, such as those under the CMA9 market remedies order (i.e. UK Open Banking), may be testing in that live context and in a mixed form of live data and test data; we assume that in the case of live testing with live data, this is permissible, instead of requiring implementation of a mandatory sandbox test, where live transactions are already common. Clarity on this would be appreciated.
Question 6: Do you agree with the EBA’s assessment for ‘widely used’, the options it considered and discarded, and the requirements proposed Guideline 7? If not, please provide your reasoning.
UK Finance broadly support the EBA’s assessment for what is considered ‘widely used’. However, we would request more clarity on how “wide adoption” is defined and the requirements to meet such a standard; we would advise that ‘wide availability’ (where ASPSP have taken reasonable and appropriate steps to encourage uptake by TPPs) would meet such a standard. In addition, it would be helpful to have confirmation that if the APIs are available for functional testing within the test facility, then the criteria for Guideline 7 will be met.In relation to Guideline 7.2 (communication efforts launched by ASPSPs to inform the market on the availability of the testing facilities), UK Finance would suggest that the evidence the ASPSP are requested to provide is limited to publications on the ASPSPs’ websites or channels. In addition, we are of the view that it would be useful to have a unique EU registry / EBA website where PISP / AISP / CBPIIs could easily identify at European level all ASPSPs that are available for testing.
We further believe that some guidance to NCA’s would be helpful to ensure there is a consistent approach across Member States. This should focus both on what constitutes “widely available” or widely publicised, and regarding what information ASPSPs need to provide to their NCA.
Question 7: Do you agree with the EBAs assessment to use the service level targets and statistical data for the assessment of resolving problems without undue delay, the options it discarded, and the requirements proposed Guideline 8? If not, please provide your reasoning.
UK Finance agrees with the EBA’s assessment.Question 8: Do you agree with the proposed Guideline 9 and the information submitted to the EBA in the Assessment Form in the Annex? If not, please provide your reasoning.
UK Finance agrees with the EBA’s proposed guideline and believe it is proportionate given the short timeline for implementation.We believe that an ASPSP can appeal their NCA’s decision regarding an exemption if an exemption request is rejected. This is normal practice for supervisory processes and we believe that the process should also allow for a continuing conversation between the NCA and ASPSP should they not meet the full requirements in July 2019, in this case, the ASPSP wouldn’t be required to implement the contingency mechanism, provided that the exemption is attainable within a reasonable period of time (e.g. six months).
This process needs to be practical and take into account, for example if an ASPSP has implemented a well-functioning API for the majority of PSD2 requirements, but that certain functionality still needs to be implemented, for example, non-SEPA international payments (e.g. SWIFT payments) or if a particular brand in a group has not implemented on time, but the rest of the group has.
It would be beneficial for the EBA to give further consideration for how some ASPSPs could gain an exemption in future. If this is a newly created ASPSP or an ASPSP who was not aware of their regulatory and legal requirements under PSD2. If a firm applies for an exemption (either as a new PSP or one unaware of their obligations), we strongly feel these firms should still be able to seek an exemption without the need to implement a ‘customer interface with identification’.
As a further point, the EBA consultation refers to Guidelines on the conditions to be met to benefit from an exemption from contingency measures under RTS Article 33(6). UK Finance are of the view, this could be misleading as there is a clear distinction between:
i. The obligation for ASPSPs to have in place ‘contingency measures’ (such as a strategy and communication plans) in line with RTS Articles 33(1) and (2) and
ii. Exemption from having to provide the ‘contingency mechanism’ referred to in RTS Articles 33(4), (5) and (6).
Being granted an exemption means the ASPSP doesn’t need to build the contingency mechanism but the ASPSP must still have in place the contingency measures. We do not believe that contingency measures are an ‘interface’, as this is a separate requirement.