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.
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.
No comment.
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.
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.
