We do not 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 for the reason below.
The provisions of chapter 1 for knowledge based challenges appear to assume that a password is the only form of knowledge based challenge. This view was drawn due to the requirements and characteristics of a knowledge element of; - expiry, non-repeating characters and complexity requirements.
Knowledge challenges in the form of PIN are proven, trusted and a familiar method of authentication for payments in card present environments such as point of sale and at ATMs. For the majority of consumers in Western Europe, PIN Authentication for transactions is the norm with 96% of all card transactions using PIN as an authentication method. The norm is to use 4-6 digits with most PINs unchanged for 3 years (time of re-issue).
While CHIP enabled cards have played a part in the success of reducing counterfeit and skimmed card fraud it is only when paired with PIN that there is a strong solution for stolen cards and magnetic stripe skimming. In card not present transactions, strong authentication becomes an ever more important issue. The market for payments using using a touchscreen device s now burgeoning with 40% of all e-commerce carried out on a mobile device in the UK and that number is rising. Yet, for all the speed and convenience mobile offers, security is still the primary concern for the industry and the consumer. A 2015 LexisNexis report, for example, showed that in the US, while mobile accounted for 14% of all transactions, it also accounted for 21% of all payment fraud.

We agree that where practical requirements for dynamic linking should remain neutral but do not believe that RTS has met its own objective of neutrality and our concerns and observations are listed below:
This is a direct question in regards to dynamic linking but it also stealthily introduces the requirement that a second App, Device or Channel is always required to authenticate remote transactions.
This would appear to conflict with soon to be released 3DS 2.0 specifications, which through the introduction of a SDK allows merchants to integrate the SDK into their store/service App and complete authentication inside of the merchant App and not necessarily require that a second ‘authenticator’ App be required (although the specification allows for this scenario as well). This is likely to be welcomed by merchants.
Dynamic linking of data to an authentication is a strong tool for preventing fraud due to manipulation of data, buyers regret and friendly fraud - it should however, never require a consumer to manually transfer data. However, although dynamic linking can be considered a strong tool it is still open to compromise and will not be appropriate for all payment scenarios.
Dynamic linking of data to an authentication should be limited to remote transactions as existing CHIP technologies provide appropriate levels of security in a card present environment.

All form factors of possession elements will have different attack surfaces, and describing the objective of defence is the best approach - perhaps the only missing aspect is the prevention/reduction of the ability to intercept possession elements.

We do not understand the inclusion of contactless transactions. Why has a single technology been described and given a different classification?
For countries where the great majority of transactions are completed via a contactless card at a POS it is easy to imagine merchants quickly moving to a card reader free model. If counters on cards will need to be reset every 4th transaction this will never be a reality, it will stifle innovation and perpetuate the need to ship expensive additional pieces of hardware, increasing the cost of accepting payments.
Visitors to Europe could potentially be impacted by these mandates resulting in lost revenues to European businesses.
If non-European Issuers of payment credentials were excluded/exempted there is a strong likelihood that merchants in Europe would have to build and maintain two systems for payments, the European and the rest of the world. This would add to the cost of processing payments and make Europe less competitive.

Creating exemptions for low value payments on face value appears to make sense because the face value cost of fraud is low. However, in reality that is not the case. Due to the high cost of investigating fraud, if the value of a transaction is low the fraud loss is written off, so 100% of the cost of the fraud and the merchant/service provider’s costs are absorbed by the industry.
Exemptions should be based on the security of the technology used to complete the transaction, such as CHIP and PIN or Token and PIN; or a combination of secure on-boarding of a stored credential into a payment instrument and the value of the transaction.

Yes, however it is unclear exactly what a personalised security credential is and for which payment scenarios they would be required. We have determined from information from Article 9 of the RTS that they are tokens that represent payment instruments such as EMV tokenised card PAN and if our determination is correct the provisioning of tokens using criteria seems suitable but the required use of such tokens is still unclear.
Further clarification is sought.

Yes, we agree with the principle of open standards, which lead to greater interoperability but we do not support to use of ISO 20022 due to the limitations it will introduce (see below).

The use of XML only as stipulated by ISO20022 will surely be seen as an inhibitor to innovation. XML requires the full message structure to be used even when elements of the message are empty. JSON would be able to comply with content requirements of messages but not be as heavy to implement.

The use of a qualified trust service provider over a general provider has the potential to increase delays and costs that would outweigh the upside of such an organisation. The organisation would need the ability to identify and validate the requestor - data already at the payment credential issuer.
The ‘who’ for creation of certificates seems to be a smaller issue than how, if one assumes that all end points must start as untrusted and unrecognised.
A service that issuers could call and issuers could distribute certificates would need to be devised.

With the apparent desire to use XML at the cost of efficient transmission of data problems like this will surface. If the protocol was only to pull data, non-consumer requested data should be kept to a minimum.
Capacity problems will occur even with only 2 requests per day. Systems will still need to be built to meet maximum demand requirements. As requestors have no visibility to what data has changed they will request data for all accounts not just the accounts that have changed.
A secure push mechanism should be envisaged.

A technology provider of multi-factor authentication solutions for unsecured devices such as mobile phones and tablets.