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”.

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.

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.

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.

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.

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.

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).