Response to consultation on RTS specifying the requirements on strong customer authentication and common and secure communication under PSD2
Go back
However we would make two specific points to the EBA on its proposed provisions. Firstly, strong authentication must be balanced against the need to ensure that innovation is unstifled and that the customers can easily and securely access the data.
Secondly, FDATA believes that the current RTS confuses ‘authentication’ and ‘authorisation’ and treats them as the same thing. They are not.
Authentication is the process of establishing identity; authorisation is the process of verifying permission to access a resource or perform an action.
The RTS has stipulations around the principles of this “strong customer authentication”, when it is necessary, and the different factors that are required for it to be “strong”. The implementation of this will vary between different ASPSPs - the use of authentication in this context is correct.
However, the RTS mentions “authentication codes” multiple times, when they would be better described as “authorisation codes”, because they authorize specific transactions or access.
We therefore strongly suggest that the EBA consider adjusting the draft to refer to these codes as “authorisation codes” or more preferably as “authorisation tokens” (code has a generic meaning, whereas “token” has a contextual meaning because it conveys a set of “claims”.
Our view is that the EBA is attempting to be too specific about dynamic linking. This type of security is best left to the market of AIS providers, who have a vested interest in making sure it works.
One key concern is the exemption for AIS providers to the effect that when strong authentication is required, the AISP’s customers will have to re-authenticate every month. We are hugely concerned about this to the point where we suspect AIS providers will not use APIs as a result. We are further concerned that, in practice, users will be less likely to take action on re-authentication prompts if they arrive too regularly.
Is it the wrong approach to solving the problem, and instead we need something like the Direct Debit governance system, which involves no expiry but allows for a cancellation at any time.
So, in this context, customers should be able to revoke access either from the AIS or the ASPSP at any time. Indeed, an AIS (under PSD2 and GDPR) has a strict legal requirement to only use the data in accordance with the customer’s consent.
FDATA recommends that if risk-appropriate customer authentication is not included in the RTS for AIS providers, then AISP transactions should be exempt for strong authentication as defined in the RTS.
If there were any suggestion of Article 10 applying to the AISP ecosystem means that there must be contractual obligations for security by all parties. This is already partly in place in some models (customer-AISP, AISP-aggregator) so missing is the agreement between aggregator-bank. However, bilateral agreements of this sort are contrary to the goal of establishing the broader ecosystem that we want to see develop to foster protection, innovation and competition.
FDATA agrees that Article 11 is risk-based.
Article 12 is more complicated in the AISP model. FDATA agrees that association between the consumer and their credentials must be ensured, but not with tying it to a device. Here too we suggest another paragraph that mirrors the current one, but removes that particular control.
FDATA suggests agreement in Article 13 that security devices are not applicable in an AISP context. The other control objectives seem fine.
FDATA believes that Articles 14, 15 and 16 are workable so long as aggregators get relief from the frequent recertification for the AISP.
However, while AIS providers are referenced in the Articles, there are significant differences in the user experience and information exchanged than with a payment transaction that requires the RTS consider AISP-specific provisions not included in the consultation paper.
Furthermore, the consumer experience for a user accessing the data through an AIS provider may be poorer because the data may be less up-to-date or take longer to access. Challenger banks are already demonstrating that a ‘push-API’ can work, so the recommendation for a ‘pull-API’, we feel, does not promote competition (and may indeed conflict with the standards outlined in paragraph 69f).
Question 1: Do you agree with the EBA’s reasoning on the requirements of the strong customer authentication, and the resultant provisions proposed in Chapter 1 of the draft RTS?
FDATA is in full agreement that strong customer authentication based on consumer risk is required. We have done significant work in that area, both as part of the Open Banking Working Group process in 2015, and more recently as part of a blueprint for how to achieve open banking.However we would make two specific points to the EBA on its proposed provisions. Firstly, strong authentication must be balanced against the need to ensure that innovation is unstifled and that the customers can easily and securely access the data.
Secondly, FDATA believes that the current RTS confuses ‘authentication’ and ‘authorisation’ and treats them as the same thing. They are not.
Authentication is the process of establishing identity; authorisation is the process of verifying permission to access a resource or perform an action.
The RTS has stipulations around the principles of this “strong customer authentication”, when it is necessary, and the different factors that are required for it to be “strong”. The implementation of this will vary between different ASPSPs - the use of authentication in this context is correct.
However, the RTS mentions “authentication codes” multiple times, when they would be better described as “authorisation codes”, because they authorize specific transactions or access.
We therefore strongly suggest that the EBA consider adjusting the draft to refer to these codes as “authorisation codes” or more preferably as “authorisation tokens” (code has a generic meaning, whereas “token” has a contextual meaning because it conveys a set of “claims”.
Question 2: In particular, in relation to the “dynamic linking” procedure, do you agree with the EBA’s reasoning that the requirements should remain neutral as to when the “dynamic linking” should take place, under the conditions that the channel, mobile application, or device where the information about the amount and the payee of the transaction is displayed is independent or segregated from the channel, mobile application or device used for initiating the payment, as foreseen in Article 2.2 of the draft RTS.
Regulation surrounding dynamic linking is unlikely to adversely affect FDATA’s members immediately, however it could do so after a write-access API is in place. We are therefore somewhat concerned about the wording which we find ambiguous in places.Our view is that the EBA is attempting to be too specific about dynamic linking. This type of security is best left to the market of AIS providers, who have a vested interest in making sure it works.
Question 3: In particular, in relation to the protection of authentication elements, are you aware of other threats than the ones identified in articles 3, 4 and 5 of the draft RTS against which authentication elements should be resistant?
We would consider this to be outside the scope of FDATA at this point.Question 4: Do you agree with the EBA’s reasoning on the exemptions from the application of Article 97 on strong customer authentication and on security measures, and the resultant provisions proposed in Chapter 2 of the draft RTS?
FDATA has a significant concern about the EBA’s proposed measures on the frequency of access and re-authentication procedures.One key concern is the exemption for AIS providers to the effect that when strong authentication is required, the AISP’s customers will have to re-authenticate every month. We are hugely concerned about this to the point where we suspect AIS providers will not use APIs as a result. We are further concerned that, in practice, users will be less likely to take action on re-authentication prompts if they arrive too regularly.
Is it the wrong approach to solving the problem, and instead we need something like the Direct Debit governance system, which involves no expiry but allows for a cancellation at any time.
So, in this context, customers should be able to revoke access either from the AIS or the ASPSP at any time. Indeed, an AIS (under PSD2 and GDPR) has a strict legal requirement to only use the data in accordance with the customer’s consent.
FDATA recommends that if risk-appropriate customer authentication is not included in the RTS for AIS providers, then AISP transactions should be exempt for strong authentication as defined in the RTS.
Question 5: Do you have any concern with the list of exemptions contained in Chapter 2 of the draft RTS for the scenario that PSPs are prevented from implementing SCA on transactions that meet the criteria for exemption?
We would consider this to be outside the scope of FDATA at this point.Question 6: Do you agree with the EBA’s reasoning on the protection of the confidentiality and the integrity of the payment service users’ personalised security credentials, and the resultant provisions proposed in Chapter 3 of the draft RTS?
FDATA considers Article 9 as defining control objectives for security and integrity. These apply to credentials for AISP as well as PSPs. As control objectives are risk-based and different from prescriptive controls, there may be a requirement for a differentiated approach to PSP and AISP credential management.If there were any suggestion of Article 10 applying to the AISP ecosystem means that there must be contractual obligations for security by all parties. This is already partly in place in some models (customer-AISP, AISP-aggregator) so missing is the agreement between aggregator-bank. However, bilateral agreements of this sort are contrary to the goal of establishing the broader ecosystem that we want to see develop to foster protection, innovation and competition.
FDATA agrees that Article 11 is risk-based.
Article 12 is more complicated in the AISP model. FDATA agrees that association between the consumer and their credentials must be ensured, but not with tying it to a device. Here too we suggest another paragraph that mirrors the current one, but removes that particular control.
FDATA suggests agreement in Article 13 that security devices are not applicable in an AISP context. The other control objectives seem fine.
FDATA believes that Articles 14, 15 and 16 are workable so long as aggregators get relief from the frequent recertification for the AISP.
Question 7: Do you agree with the EBA’s reasoning on the requirements for common and secure open standards of communication for the purpose of identification, authentication, notification, and information, and the resultant provisions proposed in Chapter 4 of the draft RTS?
FDATA supports the use of common and secure open standards. These standards need to be clearly defined by the EBA. In the UK, we would note that much work has been done in this area, with the HM Treasury commissioned Fingleton Report and the Open Banking Working Group, as well as the CMA report and also the current bank APIs, all using OAuth2 as an authorisation standard. Without clear standards in the EU, the goals of PSD2 regarding open market and enhanced innovation will not be met.However, while AIS providers are referenced in the Articles, there are significant differences in the user experience and information exchanged than with a payment transaction that requires the RTS consider AISP-specific provisions not included in the consultation paper.
Question 8: In particular, do you agree that the use of ISO 20022 elements, components or approved message definitions, if available, should be required to ensure the interoperability of different technological communication solutions implemented between PSPs for the provision of AIS, PIS or for the confirmation on the availability of funds? Do you see any particular technical constraint that would prevent the use of such industry standards?
FDATA believes that whilst ISO 20022 may be manageable for communications between very large entities, it is the wrong standard to use in a PSD2 context. It is an obtuse, large, message based standard and we believe it is impossible to create a modern, consistent API around it. As we mentioned in the previous answer, we believe there is a compelling case to use OAuth2 as an authorisation standard. Most ASPSPs who provide APIs use RESTful JSON based APIs protected by OAuth 2; we would seek to ensure that the EBA does not inadvertently prohibit these types of interfaces nor set a requirement that could be outdated or unsuitable.Question 9: With regards to identification between PSPs, do you agree that website certificates issued by a qualified trust service provider under an e-IDAS policy would be suitable and allow for the use of all common types of devices (such as computers, tablets and mobile phones) for carrying out different payment services ?
We would consider this to be outside the scope of FDATA at this point.Question 10: With regards to the frequency with which AIS providers can request information from designated payment accounts when the payment service user is not actively requesting such information, do you agree that the proposed limit of no more than two times a day achieve an appropriate balance between allowing AISP to provide updated information to their users while not negatively impacting the availability of the ASPSP’s communication interface? If not, please indicate what would be in your view the appropriate frequency and rationale for such frequency.
We are not supportive of the proposal to limit AIS providers’ access to data to twice a day unless customer is manually requesting it. There should be no specific number attached to this procedure; as long as there are clear guidelines for responsible use of the API then no limit should exist. Different providers’ business models will require them to pull data according to different timescales, and we need to ensure that the market supports all use-cases, from those only needing to access the data annually or quarterly to those requiring extremely frequent access several times a day. Any limits would severely impact on the ability of the market to service the consumer.Furthermore, the consumer experience for a user accessing the data through an AIS provider may be poorer because the data may be less up-to-date or take longer to access. Challenger banks are already demonstrating that a ‘push-API’ can work, so the recommendation for a ‘pull-API’, we feel, does not promote competition (and may indeed conflict with the standards outlined in paragraph 69f).