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
Barclays is supportive of an API-led approach to PSD2 and the industry-wide adoption of the relevant agreed API specifications (e.g. the Open Banking Standards). However, we note that there are currently a number of areas in the Guidelines where additional clarity would be welcome. This is due to different interpretations being taken with respect to what compliance looks like (due to uncertainty) which we are concerned could potentially result in some actors going above and beyond the EBA’s requirements. This in turn could reduce the incentive for ASPSPs to build a dedicated interface, which we believe holds the most promise for making a success of the intent of PSD2, which ultimately will be measured in terms of customer adoption. As such, we would encourage further clarity where possible.
Furthermore, Barclays would suggest that each National Competent Authority’s (NCA’s) decision regarding whether to award an exemption should be restricted to the RTS requirements (including clarification of areas of where questions remain), and not seek to impose additional conditions unless this is deemed absolutely necessary.
Response to Question One
Barclays is broadly supportive of the EBA’s proposals, and in particular the recommendation for the EBA to not set specific numeric availability and performance targets for each KPI within the Guidelines, to allow for each NCA to set appropriate parameters.
We would emphasise that specificity and consistency of calculations and measurements will be of paramount importance, to allow for fair and accurate comparisons to be made. We note that NCAs will need to account for the fact that ASPSPs have and will utilise a variety of different solutions, and that these differences need to be accounted for in the approach undertaken. Given these variations in approaches, and the consequent implications in terms of making potentially inaccurate comparisons between ASPSPs, we would suggest that results need only be published to the relevant NCA.
We would suggest that the availability expected of an ASPSP should be compared against the targeted level, as opposed to the actual level, to avoid comparisons being impacted by comparative good performance in the main channel. For example, if our PSU Mobile Interface experiences no issues in a given quarter, and therefore achieves 100% availability against a target of 99% availability, we should not be expected to achieve 100% availability for the dedicated interface during this period.
Regarding Guideline 2.1, we would note that ASPSPs will never achieve the same monitoring plans, given that the technology that underpins online channels is different to that underpinning the dedicated interface. We would therefore recommend that this Guideline is amended to allow for differences – provided that the outcome is the same.
Regarding Guideline 2.2, we would be grateful if you could confirm our assumption that where you refer to “the uptime of all interfaces” you are referring to the API end-points that are accessed by a third party provider using our dedicated interface.
Finally, as a contextual point, we would note that new services will often take a period of time to “bed in”, and as such would suggest that NCAs adopt a pragmatic approach when initially assessing services.
We agree with Paragraph 27 of the EBA Consultation which states that the purpose of the stress testing is to determine software and hardware robustness, availability, and reliability under extreme conditions and we believe that the ASPSP is best placed to make this determination, based on in depth knowledge of its internal systems and processes and familiarity with “normal usage” for comparison purposes.
We agree with the approach to stress testing proposed by the EBA and support the EBA’s decision not to impose specific parameters or benchmark certain elements of the stress test. Imposing more prescriptive requirements could have the effect of skewing representative results, due to the difficulties in comparing requests from PSUs to TPPs (e.g. AISPs attempting to access data on a corporate PSU at year end).
Lastly, we welcome the recognition by the EBA that a careful balance is needed in not imposing requirements on ASPSPs which are too onerous, as this would have the effect of discouraging ASPSPs from building dedicated interfaces. We believe that the approach proposed by the EBA does achieve the right balance in this respect, and we believe that this should encourage ASPSPs to build dedicated interfaces to the requisite high standard.
For these reasons, it is necessary for ASPSPs to replay the payment and account information to the PSU before the PSU provides authentication. We believe that this can be justified on the basis that this is in the best interests of the customer and that this should not be viewed as “additional checks on consent” and so considered to be an obstacle. It would be helpful if the EBA could confirm this.
We note that where an 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 and how this method of access supports all authentication methods provided by the ASPSP to the PSU. It would be helpful if the EBA could clarify whether ASPSPs would still be required to provide this explanation where they provide redirection and decoupled (i.e. multiple) methods of access?
In terms of enabling testing to be carried out, we would be grateful if the EBA could confirm our understanding that connection and functional testing can be enabled through the provision of a simple sandbox which allows testing through stubbed-APIs only.
We would be grateful if the EBA could confirm our interpretation of the Guidelines as stating that (and subject to making an acceptable form of testing available from March 2019) ASPSPs have the ability to “go-live” with live testing from June 2019 – or potentially September 2019 – noting that if this route were pursued it would potentially impact on the granting of an exemption.
We would also be grateful for clarity as to whether NCAs can rely on evidence from similar payment types and similar account information requests (i.e. if single and immediate payments have been delivered within the same framework, whether this would constitute evidence for comparable payment types).
In relation to Guideline 7.2, if ASPSPs are not able to demonstrate wide usage and so are required to provide evidence of adequate communication of testing availability to their Competent Authority, then it should be sufficient for ASPSPs to have communicated this through either their own website or a central website (e.g. in the UK, the Open Banking website). We suggest that if a central website is made available, then it should be sufficient for ASPSPs to display the availability of their testing facilities on such central website and that this will evidence the communication publicly of the availability of the testing facilities.
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.
General responseBarclays is supportive of an API-led approach to PSD2 and the industry-wide adoption of the relevant agreed API specifications (e.g. the Open Banking Standards). However, we note that there are currently a number of areas in the Guidelines where additional clarity would be welcome. This is due to different interpretations being taken with respect to what compliance looks like (due to uncertainty) which we are concerned could potentially result in some actors going above and beyond the EBA’s requirements. This in turn could reduce the incentive for ASPSPs to build a dedicated interface, which we believe holds the most promise for making a success of the intent of PSD2, which ultimately will be measured in terms of customer adoption. As such, we would encourage further clarity where possible.
Furthermore, Barclays would suggest that each National Competent Authority’s (NCA’s) decision regarding whether to award an exemption should be restricted to the RTS requirements (including clarification of areas of where questions remain), and not seek to impose additional conditions unless this is deemed absolutely necessary.
Response to Question One
Barclays is broadly supportive of the EBA’s proposals, and in particular the recommendation for the EBA to not set specific numeric availability and performance targets for each KPI within the Guidelines, to allow for each NCA to set appropriate parameters.
We would emphasise that specificity and consistency of calculations and measurements will be of paramount importance, to allow for fair and accurate comparisons to be made. We note that NCAs will need to account for the fact that ASPSPs have and will utilise a variety of different solutions, and that these differences need to be accounted for in the approach undertaken. Given these variations in approaches, and the consequent implications in terms of making potentially inaccurate comparisons between ASPSPs, we would suggest that results need only be published to the relevant NCA.
We would suggest that the availability expected of an ASPSP should be compared against the targeted level, as opposed to the actual level, to avoid comparisons being impacted by comparative good performance in the main channel. For example, if our PSU Mobile Interface experiences no issues in a given quarter, and therefore achieves 100% availability against a target of 99% availability, we should not be expected to achieve 100% availability for the dedicated interface during this period.
Regarding Guideline 2.1, we would note that ASPSPs will never achieve the same monitoring plans, given that the technology that underpins online channels is different to that underpinning the dedicated interface. We would therefore recommend that this Guideline is amended to allow for differences – provided that the outcome is the same.
Regarding Guideline 2.2, we would be grateful if you could confirm our assumption that where you refer to “the uptime of all interfaces” you are referring to the API end-points that are accessed by a third party provider using our dedicated interface.
Finally, as a contextual point, we would note that new services will often take a period of time to “bed in”, and as such would suggest that NCAs adopt a pragmatic approach when initially assessing services.
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.
Barclays agrees with the EBA that stress tests should be performed by the ASPSP and that this is in line with Article 32(2) of the RTS. For the purposes of obtaining the exemption, only the ASPSP should conduct the stress testing. We do not believe that it is practical or effective for NCAs to be required to undertake this task. We would further note that we undertake such stress testing in a live environment as part of our normal “go-live” testing, and as such would suggest that dispensation could be granted for this activity in such situations (as has been done with respect to penetration testing).We agree with Paragraph 27 of the EBA Consultation which states that the purpose of the stress testing is to determine software and hardware robustness, availability, and reliability under extreme conditions and we believe that the ASPSP is best placed to make this determination, based on in depth knowledge of its internal systems and processes and familiarity with “normal usage” for comparison purposes.
We agree with the approach to stress testing proposed by the EBA and support the EBA’s decision not to impose specific parameters or benchmark certain elements of the stress test. Imposing more prescriptive requirements could have the effect of skewing representative results, due to the difficulties in comparing requests from PSUs to TPPs (e.g. AISPs attempting to access data on a corporate PSU at year end).
Lastly, we welcome the recognition by the EBA that a careful balance is needed in not imposing requirements on ASPSPs which are too onerous, as this would have the effect of discouraging ASPSPs from building dedicated interfaces. We believe that the approach proposed by the EBA does achieve the right balance in this respect, and we believe that this should encourage ASPSPs to build dedicated interfaces to the requisite high standard.
Question 3: Do you agree with the EBA’s assessments on monitoring? If not, please provide your reasoning.
Barclays would suggest that, with respect to the EBA’s approach to assessments and monitoring, there would be merit in considering aligning the monitoring period with that applicable to normal online channels to avoid creating a barrier to provision.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.
Barclays strongly agrees with the EBA’s expressed view that the assessment referred to in the EBA Guidelines has to address compliance with the underlying regulatory requirements as opposed to assessment against any particular use case, given the multitude of use cases available. Barclays’ strong view is that whichever authentication method is made available by an ASPSP, the fundamental consideration has to be empowering the PSU to make an informed decision as to who should provide the PSU with the service and what that service should be. Barclays believes that an authentication journey which makes use of redirection (provided through a well implemented dedicated interface) serves this fundamental purpose and is in the best interests of the customer.For these reasons, it is necessary for ASPSPs to replay the payment and account information to the PSU before the PSU provides authentication. We believe that this can be justified on the basis that this is in the best interests of the customer and that this should not be viewed as “additional checks on consent” and so considered to be an obstacle. It would be helpful if the EBA could confirm this.
We note that where an 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 and how this method of access supports all authentication methods provided by the ASPSP to the PSU. It would be helpful if the EBA could clarify whether ASPSPs would still be required to provide this explanation where they provide redirection and decoupled (i.e. multiple) methods of access?
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.
Barclays is supportive of the EBA’s assessments for design and testing. Barclays is of the strong view that if the dedicated interface meets the API requirements (e.g. the UK Open Banking Standards), then the design requirements should be considered to be met. As the API specifications will have been subject to consultation with and input from industry participants, it follows that the design and testing should be “to the satisfaction of” the payment service providers. Barclays agrees with the view statements made by the EBA at the Public Hearing that the assessment of design and testing must reflect the applicable legal requirements only.In terms of enabling testing to be carried out, we would be grateful if the EBA could confirm our understanding that connection and functional testing can be enabled through the provision of a simple sandbox which allows testing through stubbed-APIs only.
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.
Barclays is broadly supportive of the EBA’s assessment of what is considered “widely used”. We welcome the acknowledgement by the EBA that there may be difficulties in assessing wide usage and are supportive of an approach which would allow ASPSPs to be granted an exemption even where the number of TPPs which have made use of the testing facility (or are using an ASPSP’s dedicated interface) could be considered to be comparatively low. This is on the basis that “wide usage” is out of the control of ASPSPs and the level of TPP usage bears no correlation to whether the ASPSP dedicated interface meets the requisite API standards).We would be grateful if the EBA could confirm our interpretation of the Guidelines as stating that (and subject to making an acceptable form of testing available from March 2019) ASPSPs have the ability to “go-live” with live testing from June 2019 – or potentially September 2019 – noting that if this route were pursued it would potentially impact on the granting of an exemption.
We would also be grateful for clarity as to whether NCAs can rely on evidence from similar payment types and similar account information requests (i.e. if single and immediate payments have been delivered within the same framework, whether this would constitute evidence for comparable payment types).
In relation to Guideline 7.2, if ASPSPs are not able to demonstrate wide usage and so are required to provide evidence of adequate communication of testing availability to their Competent Authority, then it should be sufficient for ASPSPs to have communicated this through either their own website or a central website (e.g. in the UK, the Open Banking website). We suggest that if a central website is made available, then it should be sufficient for ASPSPs to display the availability of their testing facilities on such central website and that this will evidence the communication publicly of the availability of the testing facilities.