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
We recognise that data needs to be carefully treated so as not to invite fraud attempts however presenting aggregate information such as percentage of total transactions SCA challenged when customers access via ASPSP interface vs. TPP interface would ensure we can monitor parity without being useful to fraudsters.
There are existing examples of API/platform availability reporting: https://developers.facebook.com/status, this could serve as a guide into what “good” looks like.
Noting the above we would expect to see more decoupled and embedded authentication solutions whose success can be evaluated by comparing percentage successful logins vs. offered between customers going directly via the banks own portal vs. going via the TPPs portal. It needs to be ensured that TPPs are not discriminated against.
Ultimately though a level playing field will only be achieved if a TPP can apply their own SCA/exemptions (accepting the liability) so that they may create unique, differentiated customer experiences
As the EBA made clear in its opinion on the RTS on SCA and CSC, delegated authentication is not an option unless the ASPSP chooses to enter into a contractual relationship with the TPP; this means that the TPP authentication experience is solely dependent on the quality of the ASPSP authentication experience. As such conversion rates should be possible across ASPSPs so that those ASPSPs who offer poor service have to provide a better experience.
We would also have concerns if the NCA does not have visibility of the aggregate type and timely handling of complaint we could lose the opportunity to identify systemic problems. If a TPP and ASPSP are only corresponding bilaterally how do we identify that multiple TPPs also have the same problem and therefore the scale of the issue and hence priority for resolution should be higher?
TPP representatives in our community are very concerned that the ASPSP community’s approach, runs counter to the intent of PSD2 and will eventually m avoid the aims of effective competition as it basically disregards whether or not the dedicated interfaces work well for all participants, including TPPs and the end-customers Credible APIs are more cost effective to integrate to than other direct access methods and as such it makes commercial sense for a TPP to use an API access method, given that it provides the functionality needed to offer the TPP services in a way that is not automatically inferior to the customer experience ASPSPs offer to their customers. A legal mandate to use an API should not be necessary.
We currently envisage two scenarios either no banks being granted a fall-back exemption as none of the current standards qualify, especially if seriously taking into account the criterion “to the satisfaction of the TPP”. Alternatively, exemptions being erroneously granted that remove functionality from existing TPP services currently in the market. Our recommendation would therefore be to encourage CAs to make thoughtful decisions when deciding whether or not to grant an exemption as no current standard is adequate to fulfil the aims of PSD2. Exemptions cannot be granted on the basis of limited time. ASPSPs should therefore build the fall back, unless the API undoubtfully meets all requirements and therefore qualifies for an exemption or delay the ban on screen scraping until such time as ASPSPs are ready to meet the aims of the regulation.
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.
As referenced in clause 17, “RTS requires the dedicated interface to have the same level of availability and performance as the PSU interface”. We consider access to the API an essential element of service availability and as such would like to see metrics on application of SCA for customers directly accessing an ASPSP user interface versus those accessing an ASPSP via a TPP interface. The data should be published so that it is possible to independently verify if an ASPSP is providing SCA exemptions without prejudice. Since SCA exemptions are a key element in ensuring positive user experiences, customers should be able to benefit from SCA exemptions, regardless of whether they choose to initiate a payment via a TPP or the ASPSP directly.We recognise that data needs to be carefully treated so as not to invite fraud attempts however presenting aggregate information such as percentage of total transactions SCA challenged when customers access via ASPSP interface vs. TPP interface would ensure we can monitor parity without being useful to fraudsters.
There are existing examples of API/platform availability reporting: https://developers.facebook.com/status, this could serve as a guide into what “good” looks like.
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.
No comment.Question 3: Do you agree with the EBA’s assessments on monitoring? If not, please provide your reasoning.
Yes, the CA should play a role in monitoring. As well as ASPSPs publishing data on their own sites, I would like to see CA also provide an aggregate view of availability so from a central source developers can find the data they need rather than try and maintain links to each of the ASPSPs.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.
See note above on application of SCA, exemptions and reporting. We need to drive objective measurements on something that until now has been a subjective debate, that way regardless of the method we can see if a level playing field has been applied. The guiding principle should therefore be equivalence of service. A TPP that relies on ASPSP issued credentials they should also be able to use the authentication methods that an ASPSP uses to authenticate their own customers. Very few ASPSPs redirect their customers today, EPIF is therefore of the view that redirect is an obstacle in almost every scenario as it deprives the TPP of the ability to design a customer journey that can compete with an ASPSP journey.Noting the above we would expect to see more decoupled and embedded authentication solutions whose success can be evaluated by comparing percentage successful logins vs. offered between customers going directly via the banks own portal vs. going via the TPPs portal. It needs to be ensured that TPPs are not discriminated against.
Ultimately though a level playing field will only be achieved if a TPP can apply their own SCA/exemptions (accepting the liability) so that they may create unique, differentiated customer experiences
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.
We think more could be done here. To begin with we should ensure that any interface offered to a TPP provides parity of experience that an ASPSP is offering to customers accessing their interface directly. This can be objectively measured by monitoring conversion rates (number of successful authentications/total authentication attempts).As the EBA made clear in its opinion on the RTS on SCA and CSC, delegated authentication is not an option unless the ASPSP chooses to enter into a contractual relationship with the TPP; this means that the TPP authentication experience is solely dependent on the quality of the ASPSP authentication experience. As such conversion rates should be possible across ASPSPs so that those ASPSPs who offer poor service have to provide a better experience.
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.
I believe the EBA should have a target for the percentage of AISPs who have live services vs total registered per market. Same measure for PISPs. What we have seen in the UK is that there are a number of licensed PISPs but very few testing services as the APIs are not fit for purpose.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.
We disagree with the EBAs assessment. Service level targets and statistical data will identify if there is a problem with general API availability but will not give an indication if a specific problem has been resolved in a timely manner. For example, if as a TPP we identify that we are not being granted exemptions that are otherwise being granted to customers accessing via an ASPSPs online interface, how can be ensured that this is resolved in a timely manner?We would also have concerns if the NCA does not have visibility of the aggregate type and timely handling of complaint we could lose the opportunity to identify systemic problems. If a TPP and ASPSP are only corresponding bilaterally how do we identify that multiple TPPs also have the same problem and therefore the scale of the issue and hence priority for resolution should be higher?
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.
No. The start of the process is the most important part so granting exemptions without alignment is not a sound strategy. A more reasonable one is to permit accessing via the customer’s interface until such time as the EBA, CA and an ASPSP have had sufficient time to align on what constitutes a valid exemption across all markets. Failure to do so risks penalising TPPs that are already in the market offering services by turning off functionality and not providing a reasonable alternative.Question 9: Do you have any particular concerns regarding the envisaged timelines for ASPSPs to meet the requirements set out in these Guidelines prior to the September 2019 deadline, including providing the technical specifications and testing facilities in advance of the March 2019 deadline?
We are aware that ASPSPs are struggling to meet the requirements that have thus far been specified. We also note the disappointing approach of parts of the ASPSP side in the API EG to only focus on what is the bear minimum of legally required functionality to gain a fall-back exemption regardless of whether the aims of PSD2 are met. Unfortunately, experience has now shown that the fall-back exemption is encouraging negative behaviour aimed at the removal of functionality () rather than the development of performant APIs to stimulate competition.TPP representatives in our community are very concerned that the ASPSP community’s approach, runs counter to the intent of PSD2 and will eventually m avoid the aims of effective competition as it basically disregards whether or not the dedicated interfaces work well for all participants, including TPPs and the end-customers Credible APIs are more cost effective to integrate to than other direct access methods and as such it makes commercial sense for a TPP to use an API access method, given that it provides the functionality needed to offer the TPP services in a way that is not automatically inferior to the customer experience ASPSPs offer to their customers. A legal mandate to use an API should not be necessary.
We currently envisage two scenarios either no banks being granted a fall-back exemption as none of the current standards qualify, especially if seriously taking into account the criterion “to the satisfaction of the TPP”. Alternatively, exemptions being erroneously granted that remove functionality from existing TPP services currently in the market. Our recommendation would therefore be to encourage CAs to make thoughtful decisions when deciding whether or not to grant an exemption as no current standard is adequate to fulfil the aims of PSD2. Exemptions cannot be granted on the basis of limited time. ASPSPs should therefore build the fall back, unless the API undoubtfully meets all requirements and therefore qualifies for an exemption or delay the ban on screen scraping until such time as ASPSPs are ready to meet the aims of the regulation.