Skip to main content
Response to consultation on RTS specifying the requirements on strong customer authentication and common and secure communication under PSD2
Go backQuestion 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?
BEVH appreciates the opportunity to submit views on the draft regulatory technical standard (RTS) on strong customer authentication (SCA) from the perspective of e-commerce and online merchants whose success depends on secure but also frictionless payment solutions provided by payment service providers (PSPs). We fear that in its current form, the RTS will put the e-commerce industry in the EU at a disadvantage. Fraud and security innovation will be stifled, while EU customers will be subjects to onerous, unnecessary SCA for all transactions. We have several comments on question 1:
Regarding chapter 1, behavioral data should constitute sufficient input to derive inherence elements, so that traders can perform SCA with a customer login and data from purchases/past purchases.
Regarding chapter 1, article 1, 3 (e), the mechanisms listed go well beyond knowledge, possession, and inherence elements, and in fact support the case for usage of risk based modelling in all authentication scenarios.
Article 3 provides too stringent a criteria for knowledge elements should have an expiration and be non-repeatable character as listed in article 3. For example static passwords with sufficiently complex combinations of numbers, letters and special characters should suffice as knowledge elements.
Auditing of PSPs as described in the draft RTS are not required by PSD2 and are impractical. Auditing should be left to the regulatory bodies who are responsible for PSPs, subject to the RTS and PSD2.
3DS would appear to be one of the only solutions to comply with the RTS (at least for credit and debit). When 3DS latency and expected abandonment are juxtaposed, the impact to the ecommerce industry becomes of great concern. When comparing the offline chip and pin to online 3DS, Online commerce clearly is at a disadvantage, given 3DS’s inconsistency across different banks, the inability to support mobile devices, continuing outages and lack of responsiveness. Since 3DS predates the mobile age, it was not designed to be optimized for many of the devices that exist today. For some banks, half of the screen is cut off in the mobile challenge experience.
Whereas mechanisms are in place to perform SCA on credit and debit cards, albeit sup-par, no such infrastructure exists for direct debit. The industry may not be able to design, agree upon, test and implement such an infrastructure by October 2018.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.
Regarding chapter 1, article 2, 1(b), 2 would appear that authentication and authorization are being used interchangeably, where they are two separate actions. 2(a), suggests changing of the ‘authentication code’ in the event of an ‘amount’ but does not specify the method by with the change should take place or to whom the code should be provided. It would appear to be impracticable to have a dynamic ‘authentication’ code as successive code changes have no relationship to each other. In 2(b) it is unclear how and when an ‘authentication code’ would be displayed to a payer, and how this would be done independently of the channel device or mobile application the payer is using to initiate the electronic payment transaction. This would suggest a payee would be required to display the ‘authentication code’ to the payer by means of a separate device than the one the payer is using to make the purchase. This stipulation is unnecessary and highly impractical. Item 3 does not specify how split orders and shipments should be managed where a single charge is authorized at different times by the payee. Merchants do not control customers devices and thus cannot implement separate trusted executions environments on a third party device, nor can merchants ensure that such a device has not been compromised as suggest in article 6.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?
No comment.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?
Regarding item 3.2.1 15 (a. - c.) in the draft RTS, a targeted risk based approach in conjunction with SCA provides a more complex approach to fraud. Regarding item 54, imposing the same criteria to all providers for a transaction risk analysis would not take into account the fact that specific industries, services, providers and situations may present very different risks profiles. For instance, a gambling website is not exposed to the same fraud risk as a retail website selling cameras. Similarly, not all providers collect the same information about their customers or have the same information available to assess risks. Therefore, the objective of defining a common list of information to be taken into account does not only seem unattainable, but also undesirable. The diversity of fraud risks and attempts, including the fact that certain situations present a very low risk of fraud, is a critical factor to determine a balanced approach in the risk assessment. Rather than define certain minimum criteria, the EBA should consider setting risk thresholds for merchants based on available industry norms. A prescriptive approach to how risk-based analysis is performed would limit innovation. The dynamic between fraudsters and PSPs essentially evolves as an arms race. Continual innovation in risk assessment is a critical part of the industry’s defense.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?
Yes, we are concerned as the EBA is implementing too rigid of a framework regarding the exemptions. The EBA’s approach doesn’t seem to allow to address appropriately risk, in line with a risk-based approach. For instance, high-risk, low-value transaction should be challenged but they wouldn’t be under the draft RTS if not amended, while high-value, low-risk transactions woul be challenged. This will not help to effectively prevent fraud.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?
No comment.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?
No comment.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?
No comment.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 ?
No comment.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
[Other "]"If you selected "Other", please provide details
Distance Sellers AssociationPlease select which category best describes the services provided by you/your organisation
[Other"]"If you selected "Other", please provide details
Clients.Name of organisation
bevh - German Distance Sellers Association