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
A key KPI that is missing is the monitoring of the data elements provided (RTS Article 32 (2)). For TPPs it is vital that the data provided is the same as what is available in the interface used by the PSU. A practical approach would be that ASPSPs applying for an exemption publish a report comparing which data elements are available in the dedicated interface compared to what is available in the interface used by the PSU. After the exemption is obtained, ASPSPs should periodically publish any changes in the data available in both interfaces, to ensure consistency moving forward.
Data elements available in the dedicated interface should include the identity of the PSU, such as a personal ID number (where applicable) or in lack of that name, address and date of birth. This is needed for the effective provision of PIS and AIS, per the following:
AIS: A typical AIS use case is for a PSU to share his transaction history with a different credit institution in order to get a proposal for e.g. better mortgage terms. If the AISP can no longer get the identity of the PSU from the ASPSP then sharing the transaction history no longer has any value since there is no way for the AISP (or the credit institution looking to provide better terms) to know that the shared transaction history belongs to the PSU and not e.g. a friend of the PSU.
PIS: For ASPSPs without real-time booking it is paramount for PISPs to know the aggregated amount of initiated but not yet executed transactions per each PSU, hence a unique identifier of the PSU is needed for providing PIS and therefore, if it is available to the ASPSP, it shall be made available to the PISP. Since a fraudulent PSU might use multiple ASPSPs, the identifier of the PSU must be the same for all ASPSPs, making the social security/personal ID number and where such does not exist address and date of birth, practical identification elements.
Furthermore, the interfaces made available by the ASPSP to the PSU to which the performance of the dedicated interface shall be compared, shall include all interfaces that the PSU can make use of. In addition to the online and mobile banking interfaces mentioned, that also includes any interfaces used when the PSU uses a payment instrument issued by the ASPSP. As an example, when comparing the performance of PIS and CBPII, the interface used by the PSU when making a credit/debit card transaction should be included.
For the stress testing performed by the ASPSP in GL 4.2, the external network must also be included. It is only the ASPSP that can decide if they connect their dedicated interface to a high bandwidth, redundant, DDoS-protected internet connection or not and since TPPs only can access the dedicated interface through this external network, its performance must be included in the measurements.
And Article 33(6)(a) stipulates that the dedicated interface shall meet Article 32(2), it does not say that it is the ASPSP that shall fulfill it. As such, we don't agree with the reasoning that the monitoring requirement is void, instead it should be read as a requirement applicable to the CA just as Article 33(6) itself is a requirement applicable to the CA.
Hence, ASPSPs should furnish the relevant information to its CA and the CA shall perform the monitoring prior to granting an exemption.
Furthermore, TPPs are the only entities that can monitor the performance of the dedicated interface against the current access methods, and should be consulted by the CA before granting an exemption.
A) ASPSP introduced requirements:
Although GL 5.2(b) prevents ASPSPs from having different rules depending on the license of the TPP, it does allows ASPSPs to introduce new requirements that all TPPs using their interface must comply with. Additional, ASPSP-invented, requirements is in our view an obstacle for PISPs/AISPs, regardless if the same requirement applies equally to ASPSPs themselves (who might have a different agenda and/or financial resources than PISPs/AISPs).
B) The redirection obstacle:
Firstly we regret that EBA has already issued an Opinion according to which redirection is not per se an obstacle to the provision of PIS/AIS. We hope the EBA is still open to take market feedback on this topic into account.
Dedicated interfaces in the context of PSD2
As the European Commission has stated several times, the introduction of PSD2 is a step forward towards open banking and as such, there should be no backward steps in terms of user experience and to what is possible today. Consequently, the benchmark for determining whether an obstacle exists or not must be whether a TPP is hindered from providing as good a service as it can do based on the current method of access via the customer-facing online interfaces of the ASPSP. PSD2 codified that TPPs have the right to determine how to provide as good a service as possible (the TPP could access online banking on a non-discriminatory basis vis-a-vis the PSU directly and access the necessary data elements needed to provide its service). In the context of a dedicated interface however the ASPSP is instead put in control of essential elements of the TPP’s service, including which data elements are available and how access by the TPP should be done. To allow ASPSPs to exploit this by means of e.g. “filtering” data and/or engage in discrimination would worsen the quality of the TPP’s service and distort the spirit and wording of PSD2.
Consequently, particular consideration should be given to the level of effectiveness at which an PISP or AISP can provide services today, using the customer-facing online interfaces of the ASPSP. While we understand and fully acknowledge that TPPs need to make changes in how they provide services (integrating new interfaces, changing internal risk assessment systems etc etc) we fail to see the merit of all these changes if from a PSU point of view the service will be worse compared to what it is today (and what it would be in case the TPP would continue to have direct access to the customer-facing online interfaces).
Interpretation of RTS
We disagree with the interpretation of may". The word “may” in RTS Art. 32 (3) cannot mean that the listed obstacles may or may not be obstacles, it can only mean that the list may not be comprehensive, i.e. that there may be more obstacles than the ones listed. Otherwise, the logic would apply in the same way to the other obstacles listed there, meaning that the dedicated interface:
* may be allowed to prevent the use by TPPs of the credentials issued by account servicing payment service providers to their customers
* may be allowed to require additional authorisation and registration
* may be allowed to require additional checks of consent
Such an interpretation would make the specified list unnecessary. The only reason for including the list of obstacles is to clarify that each of those four obstacles on an individual basis is without any doubt an obstacle and that there “may” be more.
Further, one must differentiate between the terms “use of credentials” and “relying on authentication procedures”; the former meaning that TPPs must be enabled to forward/use the credentials if shared by the PSU, and the latter meaning that TPPs do not have to issue own credentials to PSUs.
The reasoning in rationale 35 “… creates friction, delay or unnecessary steps that would directly or indirectly dissuade PSUs …” must be reflected in GL 5.2 (d), where the key item “unnecessary steps” has been omitted. Redirection to a different website or application is exactly such an unnecessary step, because it can be avoided by the transmission of PSCs via the dedicated interface, rather than bothering and confusing the PSU with different screens and thereby dissuading PSUs from using the service.
The role of TPPs and compatibility of redirect with PSD2
Care must further be taken to consider what the role or “value-add” of a PISP really is. In case a PISP only redirects a PSU to a web page hosted by the ASPSP, the PISP does nothing more than an e-merchant redirecting its customers to e.g. iDEAL in the Netherlands, i.e. the PISP would perform a wholly generic service of merely sending the user to a different website/app and have no possibility to innovate or distinguish itself. This would also mean that there would be no more reason to regulate the PISP compared to regulating an e-merchant that redirects its customers to a payment method like iDEAL since both the PISP and the e-merchant does nothing more than redirecting the PSU to a web page hosted and controlled by the ASPSP.
Today however bank-independent PISPs add much more value to the payment flow and compete with and differentiate from each other in terms of e.g. the user interface provided via-a-vis the payer. As PISPs today forward the credentials of the payer to the ASPSP’s online interface, the PISP can, as long as it transmits the correct user name and credentials to the ASPSP, design completely different user experiences and journeys from the perspective of the paying consumer.
A good historical example of this is when consumers started to use mobile phones. While banks’ customer-facing websites were not adapted to the smaller screens of mobile phones, PISPs were quick to adapt their user interfaces to such screens, to the benefit of the paying consumer. The paying consumer could then have a good user experience also when paying on a device with a small screen, entering the credentials into the interface provided by the PISP, and the PISP would then transmit the credentials to the interface of the ASPSP (which was not adapted to such smaller screens). In other words, while the ASPSP did not have to do any changes or updates or provide a user interface adapted to mobile phones; since PISPs could innovate and offer such interface, the paying consumer could benefit from a fully mobile experience. In case the PISP would have had to redirect the paying consumer to the (non-mobile/small screen-adapted) ASPSPS interface, the user journey would have been broken as suddenly the payer on its mobile phone screen would have seen an interface adapted for desktop (large screens), which is very difficult to see and navigate on smaller screens.
The very same principle continue to apply 100%. Probably the most important means for fintechs to compete is that of the user experience/journey. By giving consumers better and more easily used services, fintechs can differentiate their products from that of competition. In order to do so, fintechs need to be allowed to innovate and design a user interface/journey which is not dependent on the ASPSP, or else it does not matter what kind of interface the fintechs offers the paying consumer as in any event it will be broken by the consumer having to suddenly interact with the ASPSP-provided user interface.
The are many concrete examples of this and how an imposed redirect is wholly incompatible with innovation and the design of TPPs of new and innovative products:
Voice-based payments. A TPP can offer a user interface allowing the consumer to state his user name and credentials into his mobile phone (e.g. “I authorise the payment to merchant X of one hundred euros. My one-time authorisation code sent to me by text message from my bank is YY.”). The TPP would then convert the voice into data, and transmit that (in this case the one-time authorisation code) to the online interface of the bank, which itself would not in any way have to be changed to receive voice-based instructions. The conversion of voice into data would be “value-add” provided by the TPP and a necessity is that the TPP is allowed to forward credentials and not required to redirect the customer to the ASPSP.
Payments at Point of Sale. A TPP can build a terminal (point-of-sale) product where the user would enter its credentials, following which the TPP would transmit them to the online interface of the ASPSP (without the ASPSP having to change its interface). Again, since terminals are not browser-based, TPPs would be blocked from doing so if required to use a redirect.
Payments from a wrist watch. A TPP can build an interface for e.g. a wrist watch, allowing the PSU to enter its credentials there. The TPP would transmit them to the ASPSP which would not have to make any changes at its side in order to adapt to payments from the wrist watch.
The list can go on but the general and crucial point is that redirection is done to a web page or mobile app hosted by the ASPSP and as such it only works when the user is using a web browser or having a compatible smartphone plus the ASPSP’s app. For voice, point of sale, wrist watch, other environments (e.g. “internet of things”) etc the user is not in a browser-based environment nor using a smartphone, but is using another device/technology. As such, redirection is not just an obstacle, but a complete roadblock for TPPs that want to provide services on devices which do not technologically support redirection of the PSU. In other words, a redirect is not technology-neutral and puts in place a direct cap on innovation and as such directly violates criteria (d) and (e) of Article 98(2) PSD2. It is an obvious example of what would constitute an “obstacle” to the provision of PIS/AIS.
It can further be noted that the card industry due to the poor user experience and conversion levels implied by a redirect is doing everything that it can to move away from that technology to a “3DS version 2.0”; see e.g.
https://www.emvco.com/specifications.aspx?id=299 where the rationale is stated as “to reflect current and future market requirements, the payments industry recognised the need to create a new 3-D Secure specification that would support app-based authentication and integration with digital wallets, as well as traditional browser-based e-commerce transactions”. To disallow TPPs do do the same and instead impose redirection, a 10+ year old legacy technology, in our view implies an obvious erection of an obstacle to provide services.
Consumer preference considerations
In some countries, such as the Netherlands, a redirect-based payment solution is very popular, while in other countries services based on the “embedded” authentication method is the most widely used. In this context it must be taken into account that TPPs have, and continue to be, subject to obstructions from ASPSPs in multiple countries and it is our view that there is a clear and intuitive correlation between the amount of obstructions in a country on the one hand and the success of bank-independent PIS based on the embedded method in the same country on the other hand (i.e. the more obstructions, the more difficulty for bank-independent to compete and be successful compared to bank-provided products).
In multiple countries where bank-independent TPPs (i.e. not using redirection) have been subject to relatively few obstructions, they have been very successful and are used by millions of European consumers on a regular basis. To suddenly remove the possibility for these consumers to make payments in the way they are used to, and instead force them through a new user experience which they are not used to and may not understand or appreciate, will put PSUs’ adoption and continued usage of AIS and PIS at significant risk. While redirection gives users who are used to such service the opportunity to continue to do so, the same opportunity must be given to consumers who are used to use an “embedded” service today. To force TPPs to suddenly impose on these users a new and less straightforward payment flow would completely distort the competitive landscape, artificially and unnecessarily remove choice for the merchant and consumer and constitute a clear obstacle to the provision of services of bank-independent TPPs.
Redirect as one (but not the only) alternative
As long as a redirect is not imposed, but the embedded method (as defined in API EG) is also available, ASPSPs should however of course be free to also offer a redirect if they so want. This would promote choice on behalf of the PSU.
Given this, while it should be clear that as per the above in our view a redirect as only alternative is an obvious obstacle in the meaning of Article 32 RTS, we would like to take the opportunity to communicate our view on the top three considerations/criteria to assess whether a redirect is well implemented or not. The criteria are:
a) that PSU interaction with the ASPSP is minimised, allowing the TPP to offer as convenient service as possible to the PSU. In practice, this means the following:
(i) For authentication methods when the credentials are transmitted by the PSU to the ASPSP and the account to be credited is not known beforehand, one step: log-in AND signing. In more detail, ASPSP communicates the amount which is signed and the recipient on one “screen” where the PSU’s credentials are then transmitted. Following this, the PSU is redirected back to the TPP interface to select payment account from which the payment should be made. The TPP communicates the account number to the ASPSP and payment is executed accordingly;
(ii) For authentication method when the credentials are transmitted by the PSU to the ASPSP and the account to be credited is known beforehand (and transmitted by the TPP to the ASPSP together with the initiation request), one step: log-in and signing of the amount to be paid in one authentication step; the ASPSP on one screen states the amount and recipient to the PSU and requests the authentication. The PSU performs the authentication and is then redirected back to the TPP interface.
(iii) For authentication when the credentials are not transmitted by the PSU to the ASPSP (decoupled, e.g. biometrics on mobile phone), and the account to be credited is not known beforehand, one step: log-in and signing of the amount to be paid in one authentication step, following which the selection of account from which the payment should be made is done in the TPP interface which may or may not be at the same device where the authentication is done (e.g. it can be at point of sale or desktop while the authentication is done at a mobile phone). The TPP communicates the account number to the ASPSP and payment is executed accordingly
(iv) For authentication when the credentials are not transmitted by the PSU to the ASPSP (decoupled, e.g. biometrics on mobile phone) and the account to be credited is known beforehand (and transmitted by the TPP to the ASPSP together with the initiation request), one step: authorisation of the specification payment transaction triggered by a push notice by the ASPSP.
In summary, if offered at all, a redirect must ensure a good customer journey requiring no more than one user interaction with the ASPSP.
b) There should be no extra messages, checks of consent, steps and/or questions to confirm the intent of the PSU, but the redirect must be as convenient and simple as possible, merely facilitating the authentication, leaving the account selection and all other steps to the TPP.
c) The speed with which a redirect will be processed by the ASPSP’s IT system must not be slower than the speed with which authentication is processed through the “quickest” customer-facing online interface (in practice typically the mobile bank app API).
Conclusion
In conclusion, redirection is only then not an obstacle (per se) if (and only if) it is an optional, additional method of SCA, but it cannot be the only one offered by ASPSPs. If they were offering one method only, it must be allowing the use of PSCs via their dedicated interface, i.e. the embedded approach.
While CAs know their jobs well, user experience is probably not their main skill set. The idea that CAs should be responsible for assessing the quality of the user experience and what constitutes an acceptable user journey is sub-optimal. Rather, PSUs should be allowed to use both redirect-based services and other services and in normal competition decide which one to use. In particular, PSUs should not be assumed or pre-supposed to have one preference or the other; even in a country where today a redirect-based service (iDEAL) is dominant, users must not be blocked from trying other methods, in particular as redirect-based services are not compatible with a number of new and emerging technologies/devices.
Securing the practice of “forwarding of credentials” was one of the key objectives in revising PSD1 into PSD2 and the reason for regulating and supervising TPPs, adding multi-factor authentication, mandating identification and liability insurance, etc. Consequently, there are numerous clauses in first and second level text, which imply and explicitly assume the TPP’s use of ASPSP-issued credentials and which would expose ASPSPs to claims of anti-competitive behaviour if they tried to prevent this. Therefore, ASPSPs must not be guided in that direction but the opposite should be done, i.e. making clear that mandatory redirection cannot be made compliant, no matter how easy the PSU journey is made in the subjective mind of the ASPSP, let alone being accepted for granting a fall-back exemption."
Article 33(6)(b) consists of two conditions: That the dedicated interface has been designed to the satisfaction of TPPs and that the dedicated interface has been tested to the satisfaction of TPPs. We will in the below address each of these conditions:
Designed to the satisfaction of TPPs:
GL 6.4 assumes that a dedicated interface that is designed based on a market initiative standard satisfies TPPs. This is something we object against. Many market initiatives have had consultations with TPPs but they have also NOT adapted their standards to the feedback received from TPPs and can therefore not be seen as a guarantee that TPPs are satisfied with the design.
And GL 6.5 only requires ASPSPs that design their dedicated interface on their own to describe the engagement with TPPs that has taken place, it does not require ASPSPs to actually take the view of TPPs into account or even describe for the CA which TPP considerations they have chosen to ignore. This obviously does not imply that the dedicated interface has been designed to the satisfaction of TPPs.
A pragmatic guideline to CAs could be to take any feedback sent to them by TPPs into account when deciding on if the design of an ASPSP's dedicated interface satisfies TPPs before allowing it to be exempted.
Tested to the satisfaction of TPPs:
No sensitive information shall be shared through the testing facility according to Article 30(5) but other than that, the testing facility shall enable TPPs to test all functionality needed by the TPP in order to provide their service to PSUs. As such, the list in GL 6.2 should contain all functionality regulated by PSD2 and the RTS on SCA and CSC and would therefore be redundant. (The current list is missing a lot of needed functionality, for example the possibility to test all authentication procedures for both consumer and corporate customers.)
Instead, we propose that GL 6.2 says that TPPs shall be able to test all functionality that the real (live/production) dedicated interface will offer (with any sensitive information removed).
Consequently being widely used" is a key metric when determining if a dedicated interface is good enough for the market as the only reason for not being widely used is the lack of quality of the interface against the current access methods. We strongly disagree with the proposal of replacing this requirement with the term “available for wide use”, which is not at all equivalent - rather the opposite - and would violate the explicit wording of the RTS.
We note that per Article 33 (7) RTS, an ASPSP applying for an exemption must be able to offer the “fallback” within 2 months after a potential revocation. Consequently, the effort required by an ASPSP to put in place the fallback method can at a maximum be two months worth of their time and the benefit of receiving an exemption before the RTS equally applies to those two months of work. The granting of exemptions must not be done at the expense of risking the TPPs’ uninterrupted provision of services. Millions of European consumers and thousands of European merchants rely on existing services and in case of any doubt over the quality, reliability or any other aspect of a dedicated interface being put in place by an ASPSP, it must have the contingency measure in place.
If an ASPSP applies for an exemption in time for when the RTS applies, CA should per RTS Article 30 (6) take into account when granting the exemption if the ASPSP is able to offer the fallback method within two months in case their exemption has to be revoked.
An “exemptions” is per definition not the norm but an exception and allowing a bank to not implement the fall-back can only happen as and when the dedicated interface is certain to be widely used and proven to work properly. Given that the implementation of the fall-back cannot be more than 2 months’ work it is not an unreasonable requirement weighted against the severe negative impact on TPPs if not-widely used and therefore not-thoroughly stable dedicated interfaces would fail without having a fall-back in place.
Therefore, until the dedicated interface has been widely used it shall not be given an exemption from the fallback method for the reason that it is then by definition not battle tested enough for justifying removal of the fallback.
We would also like to clarify that the three-month period referred to in Article 33(6)(c) may only be included within the 6-month testing period referred to in Article 30(5) if the real (live/production) dedicated interface is made available for TTPs to use by 14 June 2019 since it is the real dedicated interface and not the testing facility that shall have been widely used. ASPSPs deciding to launch a dedicated interface after 14 September 2019 must per Article 30(5) provide the testing facility 6 months before launch instead of by the date referred to in Article 38(3) and the 3 months in Article 33(6)(c) can by definition only begin after launch.
In case this argument is not accepted, despite the material impact this can have on a TPP business, an alternative approach would be to say that until a dedicated interface is widely used, no exemption from the contingency measure is to be granted, but in order for ASPSPs to not have to implement the contingency measure during the time it takes for the marked to widely use their dedicated interface, RTS Article 30 (6) in the meanwhile applies."
Any ASPSP applying for an exemption for a dedicated interface launched after 14 September 2019 will already have the fallback mechanism in place since in order to be compliant until they launch their dedicated interface, they will have allowed TPPs to use the interface used by PSUs. Hence an exemption allows those ASPSPs to stop offering the fallback but there is no extra work for those ASPSPs to continue offering it during the three months referred to in Article 33(6)(c) during which Article 33(6)(d) applies.
And nothing prevents ASPSPs that wishes to never implement the fallback mechanism by receiving an exemption in time for 14 September 2019 to launch their real/live dedicated interface before 14 June 2019 in order to get it used for three months during which Article 33(6)(d) applies.
Hence, problems related to the dedicated interface - the real one, not the testing facility - shall have been resolved without undue delay.
We also disagree with the statement that complaints from licensed TPPs are not a reliable indicator of problems with the interface offered to those TPPs. Because, as stated in question 6, TPPs have no incentives not to use properly functioning dedicated interfaces. The TPPs are the only users of the dedicated interface and as such the only parties that are independent from the ASPSP applying for an exemption that has any knowledge of the problems with the dedicated interface.
A better approach would be to say that ASPSPs applying for an exemption shall document which complaints they have received from TPPs and how long it took the ASPSP to resolve (or reject) each complaint. Furthermore, there should be a communications channel between NCAs and TPPs to assess on the quality of the responses from the ASPSPs.
The current guidelines allow ASPSPs to receive an exemption purely on their own assessment of their own dedicated interface, regardless on how well it is working and how usable it is for TPPs; this is not at all acceptable.
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.
Performance of the PSU interface should be measured as it is accessed today by TPPs, not as it is accessed by the PSU directly. In other words, it should not take more time for a TPP to obtain the same information through the dedicated interface compared to what it takes to obtain it through the (quickest) PSU interface. Since TPPs are the only entities that can assess this interface TPPs should be part of the testing to obtain an exemption, in coordination with the NCAs. In addition, TPPs should be allowed to periodically test the direct interface on a limited basis against the PSU interface to make sure the quarterly reports from the ASPSPs accurately reflect the TPP experience.A key KPI that is missing is the monitoring of the data elements provided (RTS Article 32 (2)). For TPPs it is vital that the data provided is the same as what is available in the interface used by the PSU. A practical approach would be that ASPSPs applying for an exemption publish a report comparing which data elements are available in the dedicated interface compared to what is available in the interface used by the PSU. After the exemption is obtained, ASPSPs should periodically publish any changes in the data available in both interfaces, to ensure consistency moving forward.
Data elements available in the dedicated interface should include the identity of the PSU, such as a personal ID number (where applicable) or in lack of that name, address and date of birth. This is needed for the effective provision of PIS and AIS, per the following:
AIS: A typical AIS use case is for a PSU to share his transaction history with a different credit institution in order to get a proposal for e.g. better mortgage terms. If the AISP can no longer get the identity of the PSU from the ASPSP then sharing the transaction history no longer has any value since there is no way for the AISP (or the credit institution looking to provide better terms) to know that the shared transaction history belongs to the PSU and not e.g. a friend of the PSU.
PIS: For ASPSPs without real-time booking it is paramount for PISPs to know the aggregated amount of initiated but not yet executed transactions per each PSU, hence a unique identifier of the PSU is needed for providing PIS and therefore, if it is available to the ASPSP, it shall be made available to the PISP. Since a fraudulent PSU might use multiple ASPSPs, the identifier of the PSU must be the same for all ASPSPs, making the social security/personal ID number and where such does not exist address and date of birth, practical identification elements.
Furthermore, the interfaces made available by the ASPSP to the PSU to which the performance of the dedicated interface shall be compared, shall include all interfaces that the PSU can make use of. In addition to the online and mobile banking interfaces mentioned, that also includes any interfaces used when the PSU uses a payment instrument issued by the ASPSP. As an example, when comparing the performance of PIS and CBPII, the interface used by the PSU when making a credit/debit card transaction should be included.
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.
Many AIS are currently not accessing the PSU interface more than once daily due to the fact that it is causing an impact on the PSU interface. At the very minimum, the dedicated interface should be able to handle the current volume of users four times daily without degradation. Therefore, TPPs should be able to verify the capacity of ASPSPs to handle this load and report to the NCAs if this is not met.For the stress testing performed by the ASPSP in GL 4.2, the external network must also be included. It is only the ASPSP that can decide if they connect their dedicated interface to a high bandwidth, redundant, DDoS-protected internet connection or not and since TPPs only can access the dedicated interface through this external network, its performance must be included in the measurements.
Question 3: Do you agree with the EBA’s assessments on monitoring? If not, please provide your reasoning.
Even if ASPSPs cannot be held responsible for CAs monitoring activities prior to applying for an exemption, they can be held responsible for providing CAs with all material needed by CAs in order for the CA to have a reasonable time of performing the monitoring before granting an exemption.And Article 33(6)(a) stipulates that the dedicated interface shall meet Article 32(2), it does not say that it is the ASPSP that shall fulfill it. As such, we don't agree with the reasoning that the monitoring requirement is void, instead it should be read as a requirement applicable to the CA just as Article 33(6) itself is a requirement applicable to the CA.
Hence, ASPSPs should furnish the relevant information to its CA and the CA shall perform the monitoring prior to granting an exemption.
Furthermore, TPPs are the only entities that can monitor the performance of the dedicated interface against the current access methods, and should be consulted by the CA before granting an exemption.
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.
We agree with all views of the EBA in this section but two: the statement that ASPSPs are allowed to introduce new requirements as long as they apply to all dedicated interface users and the view that redirection is not an obstacle, with which we strongly disagree. We will in the below explain the reasons therefore.A) ASPSP introduced requirements:
Although GL 5.2(b) prevents ASPSPs from having different rules depending on the license of the TPP, it does allows ASPSPs to introduce new requirements that all TPPs using their interface must comply with. Additional, ASPSP-invented, requirements is in our view an obstacle for PISPs/AISPs, regardless if the same requirement applies equally to ASPSPs themselves (who might have a different agenda and/or financial resources than PISPs/AISPs).
B) The redirection obstacle:
Firstly we regret that EBA has already issued an Opinion according to which redirection is not per se an obstacle to the provision of PIS/AIS. We hope the EBA is still open to take market feedback on this topic into account.
Dedicated interfaces in the context of PSD2
As the European Commission has stated several times, the introduction of PSD2 is a step forward towards open banking and as such, there should be no backward steps in terms of user experience and to what is possible today. Consequently, the benchmark for determining whether an obstacle exists or not must be whether a TPP is hindered from providing as good a service as it can do based on the current method of access via the customer-facing online interfaces of the ASPSP. PSD2 codified that TPPs have the right to determine how to provide as good a service as possible (the TPP could access online banking on a non-discriminatory basis vis-a-vis the PSU directly and access the necessary data elements needed to provide its service). In the context of a dedicated interface however the ASPSP is instead put in control of essential elements of the TPP’s service, including which data elements are available and how access by the TPP should be done. To allow ASPSPs to exploit this by means of e.g. “filtering” data and/or engage in discrimination would worsen the quality of the TPP’s service and distort the spirit and wording of PSD2.
Consequently, particular consideration should be given to the level of effectiveness at which an PISP or AISP can provide services today, using the customer-facing online interfaces of the ASPSP. While we understand and fully acknowledge that TPPs need to make changes in how they provide services (integrating new interfaces, changing internal risk assessment systems etc etc) we fail to see the merit of all these changes if from a PSU point of view the service will be worse compared to what it is today (and what it would be in case the TPP would continue to have direct access to the customer-facing online interfaces).
Interpretation of RTS
We disagree with the interpretation of may". The word “may” in RTS Art. 32 (3) cannot mean that the listed obstacles may or may not be obstacles, it can only mean that the list may not be comprehensive, i.e. that there may be more obstacles than the ones listed. Otherwise, the logic would apply in the same way to the other obstacles listed there, meaning that the dedicated interface:
* may be allowed to prevent the use by TPPs of the credentials issued by account servicing payment service providers to their customers
* may be allowed to require additional authorisation and registration
* may be allowed to require additional checks of consent
Such an interpretation would make the specified list unnecessary. The only reason for including the list of obstacles is to clarify that each of those four obstacles on an individual basis is without any doubt an obstacle and that there “may” be more.
Further, one must differentiate between the terms “use of credentials” and “relying on authentication procedures”; the former meaning that TPPs must be enabled to forward/use the credentials if shared by the PSU, and the latter meaning that TPPs do not have to issue own credentials to PSUs.
The reasoning in rationale 35 “… creates friction, delay or unnecessary steps that would directly or indirectly dissuade PSUs …” must be reflected in GL 5.2 (d), where the key item “unnecessary steps” has been omitted. Redirection to a different website or application is exactly such an unnecessary step, because it can be avoided by the transmission of PSCs via the dedicated interface, rather than bothering and confusing the PSU with different screens and thereby dissuading PSUs from using the service.
The role of TPPs and compatibility of redirect with PSD2
Care must further be taken to consider what the role or “value-add” of a PISP really is. In case a PISP only redirects a PSU to a web page hosted by the ASPSP, the PISP does nothing more than an e-merchant redirecting its customers to e.g. iDEAL in the Netherlands, i.e. the PISP would perform a wholly generic service of merely sending the user to a different website/app and have no possibility to innovate or distinguish itself. This would also mean that there would be no more reason to regulate the PISP compared to regulating an e-merchant that redirects its customers to a payment method like iDEAL since both the PISP and the e-merchant does nothing more than redirecting the PSU to a web page hosted and controlled by the ASPSP.
Today however bank-independent PISPs add much more value to the payment flow and compete with and differentiate from each other in terms of e.g. the user interface provided via-a-vis the payer. As PISPs today forward the credentials of the payer to the ASPSP’s online interface, the PISP can, as long as it transmits the correct user name and credentials to the ASPSP, design completely different user experiences and journeys from the perspective of the paying consumer.
A good historical example of this is when consumers started to use mobile phones. While banks’ customer-facing websites were not adapted to the smaller screens of mobile phones, PISPs were quick to adapt their user interfaces to such screens, to the benefit of the paying consumer. The paying consumer could then have a good user experience also when paying on a device with a small screen, entering the credentials into the interface provided by the PISP, and the PISP would then transmit the credentials to the interface of the ASPSP (which was not adapted to such smaller screens). In other words, while the ASPSP did not have to do any changes or updates or provide a user interface adapted to mobile phones; since PISPs could innovate and offer such interface, the paying consumer could benefit from a fully mobile experience. In case the PISP would have had to redirect the paying consumer to the (non-mobile/small screen-adapted) ASPSPS interface, the user journey would have been broken as suddenly the payer on its mobile phone screen would have seen an interface adapted for desktop (large screens), which is very difficult to see and navigate on smaller screens.
The very same principle continue to apply 100%. Probably the most important means for fintechs to compete is that of the user experience/journey. By giving consumers better and more easily used services, fintechs can differentiate their products from that of competition. In order to do so, fintechs need to be allowed to innovate and design a user interface/journey which is not dependent on the ASPSP, or else it does not matter what kind of interface the fintechs offers the paying consumer as in any event it will be broken by the consumer having to suddenly interact with the ASPSP-provided user interface.
The are many concrete examples of this and how an imposed redirect is wholly incompatible with innovation and the design of TPPs of new and innovative products:
Voice-based payments. A TPP can offer a user interface allowing the consumer to state his user name and credentials into his mobile phone (e.g. “I authorise the payment to merchant X of one hundred euros. My one-time authorisation code sent to me by text message from my bank is YY.”). The TPP would then convert the voice into data, and transmit that (in this case the one-time authorisation code) to the online interface of the bank, which itself would not in any way have to be changed to receive voice-based instructions. The conversion of voice into data would be “value-add” provided by the TPP and a necessity is that the TPP is allowed to forward credentials and not required to redirect the customer to the ASPSP.
Payments at Point of Sale. A TPP can build a terminal (point-of-sale) product where the user would enter its credentials, following which the TPP would transmit them to the online interface of the ASPSP (without the ASPSP having to change its interface). Again, since terminals are not browser-based, TPPs would be blocked from doing so if required to use a redirect.
Payments from a wrist watch. A TPP can build an interface for e.g. a wrist watch, allowing the PSU to enter its credentials there. The TPP would transmit them to the ASPSP which would not have to make any changes at its side in order to adapt to payments from the wrist watch.
The list can go on but the general and crucial point is that redirection is done to a web page or mobile app hosted by the ASPSP and as such it only works when the user is using a web browser or having a compatible smartphone plus the ASPSP’s app. For voice, point of sale, wrist watch, other environments (e.g. “internet of things”) etc the user is not in a browser-based environment nor using a smartphone, but is using another device/technology. As such, redirection is not just an obstacle, but a complete roadblock for TPPs that want to provide services on devices which do not technologically support redirection of the PSU. In other words, a redirect is not technology-neutral and puts in place a direct cap on innovation and as such directly violates criteria (d) and (e) of Article 98(2) PSD2. It is an obvious example of what would constitute an “obstacle” to the provision of PIS/AIS.
It can further be noted that the card industry due to the poor user experience and conversion levels implied by a redirect is doing everything that it can to move away from that technology to a “3DS version 2.0”; see e.g.
https://www.emvco.com/specifications.aspx?id=299 where the rationale is stated as “to reflect current and future market requirements, the payments industry recognised the need to create a new 3-D Secure specification that would support app-based authentication and integration with digital wallets, as well as traditional browser-based e-commerce transactions”. To disallow TPPs do do the same and instead impose redirection, a 10+ year old legacy technology, in our view implies an obvious erection of an obstacle to provide services.
Consumer preference considerations
In some countries, such as the Netherlands, a redirect-based payment solution is very popular, while in other countries services based on the “embedded” authentication method is the most widely used. In this context it must be taken into account that TPPs have, and continue to be, subject to obstructions from ASPSPs in multiple countries and it is our view that there is a clear and intuitive correlation between the amount of obstructions in a country on the one hand and the success of bank-independent PIS based on the embedded method in the same country on the other hand (i.e. the more obstructions, the more difficulty for bank-independent to compete and be successful compared to bank-provided products).
In multiple countries where bank-independent TPPs (i.e. not using redirection) have been subject to relatively few obstructions, they have been very successful and are used by millions of European consumers on a regular basis. To suddenly remove the possibility for these consumers to make payments in the way they are used to, and instead force them through a new user experience which they are not used to and may not understand or appreciate, will put PSUs’ adoption and continued usage of AIS and PIS at significant risk. While redirection gives users who are used to such service the opportunity to continue to do so, the same opportunity must be given to consumers who are used to use an “embedded” service today. To force TPPs to suddenly impose on these users a new and less straightforward payment flow would completely distort the competitive landscape, artificially and unnecessarily remove choice for the merchant and consumer and constitute a clear obstacle to the provision of services of bank-independent TPPs.
Redirect as one (but not the only) alternative
As long as a redirect is not imposed, but the embedded method (as defined in API EG) is also available, ASPSPs should however of course be free to also offer a redirect if they so want. This would promote choice on behalf of the PSU.
Given this, while it should be clear that as per the above in our view a redirect as only alternative is an obvious obstacle in the meaning of Article 32 RTS, we would like to take the opportunity to communicate our view on the top three considerations/criteria to assess whether a redirect is well implemented or not. The criteria are:
a) that PSU interaction with the ASPSP is minimised, allowing the TPP to offer as convenient service as possible to the PSU. In practice, this means the following:
(i) For authentication methods when the credentials are transmitted by the PSU to the ASPSP and the account to be credited is not known beforehand, one step: log-in AND signing. In more detail, ASPSP communicates the amount which is signed and the recipient on one “screen” where the PSU’s credentials are then transmitted. Following this, the PSU is redirected back to the TPP interface to select payment account from which the payment should be made. The TPP communicates the account number to the ASPSP and payment is executed accordingly;
(ii) For authentication method when the credentials are transmitted by the PSU to the ASPSP and the account to be credited is known beforehand (and transmitted by the TPP to the ASPSP together with the initiation request), one step: log-in and signing of the amount to be paid in one authentication step; the ASPSP on one screen states the amount and recipient to the PSU and requests the authentication. The PSU performs the authentication and is then redirected back to the TPP interface.
(iii) For authentication when the credentials are not transmitted by the PSU to the ASPSP (decoupled, e.g. biometrics on mobile phone), and the account to be credited is not known beforehand, one step: log-in and signing of the amount to be paid in one authentication step, following which the selection of account from which the payment should be made is done in the TPP interface which may or may not be at the same device where the authentication is done (e.g. it can be at point of sale or desktop while the authentication is done at a mobile phone). The TPP communicates the account number to the ASPSP and payment is executed accordingly
(iv) For authentication when the credentials are not transmitted by the PSU to the ASPSP (decoupled, e.g. biometrics on mobile phone) and the account to be credited is known beforehand (and transmitted by the TPP to the ASPSP together with the initiation request), one step: authorisation of the specification payment transaction triggered by a push notice by the ASPSP.
In summary, if offered at all, a redirect must ensure a good customer journey requiring no more than one user interaction with the ASPSP.
b) There should be no extra messages, checks of consent, steps and/or questions to confirm the intent of the PSU, but the redirect must be as convenient and simple as possible, merely facilitating the authentication, leaving the account selection and all other steps to the TPP.
c) The speed with which a redirect will be processed by the ASPSP’s IT system must not be slower than the speed with which authentication is processed through the “quickest” customer-facing online interface (in practice typically the mobile bank app API).
Conclusion
In conclusion, redirection is only then not an obstacle (per se) if (and only if) it is an optional, additional method of SCA, but it cannot be the only one offered by ASPSPs. If they were offering one method only, it must be allowing the use of PSCs via their dedicated interface, i.e. the embedded approach.
While CAs know their jobs well, user experience is probably not their main skill set. The idea that CAs should be responsible for assessing the quality of the user experience and what constitutes an acceptable user journey is sub-optimal. Rather, PSUs should be allowed to use both redirect-based services and other services and in normal competition decide which one to use. In particular, PSUs should not be assumed or pre-supposed to have one preference or the other; even in a country where today a redirect-based service (iDEAL) is dominant, users must not be blocked from trying other methods, in particular as redirect-based services are not compatible with a number of new and emerging technologies/devices.
Securing the practice of “forwarding of credentials” was one of the key objectives in revising PSD1 into PSD2 and the reason for regulating and supervising TPPs, adding multi-factor authentication, mandating identification and liability insurance, etc. Consequently, there are numerous clauses in first and second level text, which imply and explicitly assume the TPP’s use of ASPSP-issued credentials and which would expose ASPSPs to claims of anti-competitive behaviour if they tried to prevent this. Therefore, ASPSPs must not be guided in that direction but the opposite should be done, i.e. making clear that mandatory redirection cannot be made compliant, no matter how easy the PSU journey is made in the subjective mind of the ASPSP, let alone being accepted for granting a fall-back exemption."
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.
The purpose of having dedicated interfaces designed and tested to the satisfaction of the TPPs is to ensure that TPPs have a say in what a good interface looks like, particularly in regards to what data is being exchanged and if this data corresponds to what is available in the interface used by the PSU.Article 33(6)(b) consists of two conditions: That the dedicated interface has been designed to the satisfaction of TPPs and that the dedicated interface has been tested to the satisfaction of TPPs. We will in the below address each of these conditions:
Designed to the satisfaction of TPPs:
GL 6.4 assumes that a dedicated interface that is designed based on a market initiative standard satisfies TPPs. This is something we object against. Many market initiatives have had consultations with TPPs but they have also NOT adapted their standards to the feedback received from TPPs and can therefore not be seen as a guarantee that TPPs are satisfied with the design.
And GL 6.5 only requires ASPSPs that design their dedicated interface on their own to describe the engagement with TPPs that has taken place, it does not require ASPSPs to actually take the view of TPPs into account or even describe for the CA which TPP considerations they have chosen to ignore. This obviously does not imply that the dedicated interface has been designed to the satisfaction of TPPs.
A pragmatic guideline to CAs could be to take any feedback sent to them by TPPs into account when deciding on if the design of an ASPSP's dedicated interface satisfies TPPs before allowing it to be exempted.
Tested to the satisfaction of TPPs:
No sensitive information shall be shared through the testing facility according to Article 30(5) but other than that, the testing facility shall enable TPPs to test all functionality needed by the TPP in order to provide their service to PSUs. As such, the list in GL 6.2 should contain all functionality regulated by PSD2 and the RTS on SCA and CSC and would therefore be redundant. (The current list is missing a lot of needed functionality, for example the possibility to test all authentication procedures for both consumer and corporate customers.)
Instead, we propose that GL 6.2 says that TPPs shall be able to test all functionality that the real (live/production) dedicated interface will offer (with any sensitive information removed).
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.
A properly designed and implemented dedicated interface should be superior to the current access methods, and easier to implement, operate and maintain for TPPs. Consequently TPPs have no incentives not to use good dedicated interfaces.Consequently being widely used" is a key metric when determining if a dedicated interface is good enough for the market as the only reason for not being widely used is the lack of quality of the interface against the current access methods. We strongly disagree with the proposal of replacing this requirement with the term “available for wide use”, which is not at all equivalent - rather the opposite - and would violate the explicit wording of the RTS.
We note that per Article 33 (7) RTS, an ASPSP applying for an exemption must be able to offer the “fallback” within 2 months after a potential revocation. Consequently, the effort required by an ASPSP to put in place the fallback method can at a maximum be two months worth of their time and the benefit of receiving an exemption before the RTS equally applies to those two months of work. The granting of exemptions must not be done at the expense of risking the TPPs’ uninterrupted provision of services. Millions of European consumers and thousands of European merchants rely on existing services and in case of any doubt over the quality, reliability or any other aspect of a dedicated interface being put in place by an ASPSP, it must have the contingency measure in place.
If an ASPSP applies for an exemption in time for when the RTS applies, CA should per RTS Article 30 (6) take into account when granting the exemption if the ASPSP is able to offer the fallback method within two months in case their exemption has to be revoked.
An “exemptions” is per definition not the norm but an exception and allowing a bank to not implement the fall-back can only happen as and when the dedicated interface is certain to be widely used and proven to work properly. Given that the implementation of the fall-back cannot be more than 2 months’ work it is not an unreasonable requirement weighted against the severe negative impact on TPPs if not-widely used and therefore not-thoroughly stable dedicated interfaces would fail without having a fall-back in place.
Therefore, until the dedicated interface has been widely used it shall not be given an exemption from the fallback method for the reason that it is then by definition not battle tested enough for justifying removal of the fallback.
We would also like to clarify that the three-month period referred to in Article 33(6)(c) may only be included within the 6-month testing period referred to in Article 30(5) if the real (live/production) dedicated interface is made available for TTPs to use by 14 June 2019 since it is the real dedicated interface and not the testing facility that shall have been widely used. ASPSPs deciding to launch a dedicated interface after 14 September 2019 must per Article 30(5) provide the testing facility 6 months before launch instead of by the date referred to in Article 38(3) and the 3 months in Article 33(6)(c) can by definition only begin after launch.
In case this argument is not accepted, despite the material impact this can have on a TPP business, an alternative approach would be to say that until a dedicated interface is widely used, no exemption from the contingency measure is to be granted, but in order for ASPSPs to not have to implement the contingency measure during the time it takes for the marked to widely use their dedicated interface, RTS Article 30 (6) in the meanwhile applies."
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 reasoning in rationale 60 where it says that Article 33(6)(d) should be seen in the context of testing. Our view is that Article 33(6) applies to the dedicated interface referred to in Article 31, not the testing facility referred to in Article 30(5).Any ASPSP applying for an exemption for a dedicated interface launched after 14 September 2019 will already have the fallback mechanism in place since in order to be compliant until they launch their dedicated interface, they will have allowed TPPs to use the interface used by PSUs. Hence an exemption allows those ASPSPs to stop offering the fallback but there is no extra work for those ASPSPs to continue offering it during the three months referred to in Article 33(6)(c) during which Article 33(6)(d) applies.
And nothing prevents ASPSPs that wishes to never implement the fallback mechanism by receiving an exemption in time for 14 September 2019 to launch their real/live dedicated interface before 14 June 2019 in order to get it used for three months during which Article 33(6)(d) applies.
Hence, problems related to the dedicated interface - the real one, not the testing facility - shall have been resolved without undue delay.
We also disagree with the statement that complaints from licensed TPPs are not a reliable indicator of problems with the interface offered to those TPPs. Because, as stated in question 6, TPPs have no incentives not to use properly functioning dedicated interfaces. The TPPs are the only users of the dedicated interface and as such the only parties that are independent from the ASPSP applying for an exemption that has any knowledge of the problems with the dedicated interface.
A better approach would be to say that ASPSPs applying for an exemption shall document which complaints they have received from TPPs and how long it took the ASPSP to resolve (or reject) each complaint. Furthermore, there should be a communications channel between NCAs and TPPs to assess on the quality of the responses from the ASPSPs.
The current guidelines allow ASPSPs to receive an exemption purely on their own assessment of their own dedicated interface, regardless on how well it is working and how usable it is for TPPs; this is not at all acceptable.