Response to consultation on RTS specifying the requirements on strong customer authentication and common and secure communication under PSD2
Go back
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.
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.
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.
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.
Further clarification is sought.
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.
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.
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 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.
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.
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.
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?
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.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?
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.
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?
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.
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?
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.
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?
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).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?
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.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 ?
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.
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.
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.