Response to consultation on RTS specifying the requirements on strong customer authentication and common and secure communication under PSD2

Go back

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?

We strongly agree with the reasoning set out by the EBA on the need for strong customer authentication, to deliver on the aims of PSD2. Smart, connected mobile devices are the primary platform that consumers choose to use to interact with their financial services providers. Mobile payment platforms are ubiquitous, overtaking web-browser based interfaces and in-person transaction. While this makes life easier and more convenient for the consumers, it introduces a level of risk for users, technology platforms and service providers who make use of those platforms.

Efforts by regulators in support of strong customer authentication to mitigate these risks is welcome, but only to the extent that it promotes innovation and allows room for payment services to keep up with the fraudsters and deploy new solutions when necessary.

Our concern is that the authentication procedure and authentication code described in Article 1 Chapter 1 of the draft RTS is too prescriptive and may result in crowding out other forms of authentication. Security is a moving target and if the EBA enshrined a given authentication procedure in its guidance, this will ultimately become a point of vulnerability for malicious actors to exploit. We encourage the EBA to take a high-level, principles based approach, which sets baseline requirements but does not develop detailed requirements prescribing the concrete authentication procedure.

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.

No comment

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?

The threat landscape outlined in this section of the guidance is accurate but not comprehensive. We would suggest that the EBA take account of the shifting nature of the threat landscape: 84% of cyber-attacks now happen at the app layer. Existing software based protection has failed to keep up with this threat landscape – antivirus software only catches 45% of all malware attacks. Authentication with a discrete hardware component has proved effective at eradicating software attacks, but has scaled badly. For the coming few years, its unlikely that 100% of devices will provide accessible hardware security, so we suggest that a combination of software and hardware-based is the best way to deliver on the aims of the EBA guidance. The EBA guidance could however spell out more clearly the benefits of hardware enabled security to underpin strong customer authentication. It is the direction the industry should go to alleviate many possible attacks.

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?

No comment

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?

No comment

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?

We strongly support the protection of the confidentiality and integrity of payment service user’s personalised security credentials as outlined in the EBA guidance, but observe that the EBA guidance should not seek to duplicate or overwrite the high standards of protection for personal data as enshrined in the General Data Protection Regulation (GDPR).

We strongly endorse the provision which states that “Secret cryptographic material related to the encryption of the credentials is stored in secure and tamper resistant devices and environments”. Providing a Trusted Execution Environment is the best means of delivering the most secure level of protection for any given device.

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?

We support common and secure open standards for the development of authentication technologies and do not have any objections with the provisions outlined in Chapter 4 of the RTS.

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?

We support an open and competitive environment for the development of payment services. The use of ISO 20022 is a good starting point to help ensure interoperability between PSPs and to promote and open and competitive landscape. We don’t envisage any particular technical constraints which would present the use of such industry standards at this stage.

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 ?

Our primary observation with regards to website certificates issued by a qualified trust service provider under e-IDAS is that this does not follow the direction of travel set by the market. Research demonstrates that in-app web activity vastly outstrips web based mobile activity, a trend which is only set to increase in the future. This phenomenon is even more pronounced when it comes to mobile banking and payment services: according to the British Bankers Association, apps represent 42% of interaction in 2015 rising to 73% by 2020.

While the measures for website certificates set out in the guidance are well meaning, they fail to account for the fact that a steadily diminishing percentage of online activity (and payment services in particular) takes place on the web. Instead consumer are opting for in-app payment services, largely on account of the superior user experience (speed and ease of use). As such we suggest the EBA guidance take better account of the measures which can be taken to safeguard mobile banking apps and in-app payment services.

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.

No comment

Please select which category best describes you and/or your organisation

[IT services provider "]"

Please select which category best describes the services provided by you/your organisation

[Other"]"

If you selected "Other", please provide details

Trustonic develops a secure environment that runs at the heart of smart connected products and enables developers and service providers to access a range of security features.

Name of organisation

Trustonic