Response to consultation on RTS specifying the requirements on strong customer authentication and common and secure communication under PSD2
Go back
1 Strong Customer Authentication definition unclear
The draft RTS specifies (as the DSP2) the strong customer authentication is an authentication based on the use of two or more elements categorized as:
• knowledge (something only the user knows),
• possession (something only the user possesses),
• inherence (something the user is),
This specification is unclear because it authorizes 2 elements from the same category (e.g. 2 passwords).
However, the draft RST doesn’t raise this ambiguity; it must clearly exclude the use à 2 elements of the same category.
REMARKS ON CHAPTER 1
2. Transaction dispute
The Article 2 (Strong customer authentication procedure with dynamic linking) – paragraph 1.b includes the requirement of dynamic linking between the transaction amount and the payee by the mean of an Authentication Code.
In case of dispute from the payer about the amount or the payee, what are the evidence that must be provided by the PSP to the payer?
If the “authentication code” is a part of these evidence (required by the DSP2 - Article 72 Evidence on authentication and execution of payment transactions), how can it prevent all repudiation from the payer?
In case of cryptography usage to create this “Authentication Code”(Chapter 3.2.1 – paragraph 24), an independent actor must play the arbitral role of cryptogram verifier in order to solve the dispute. Which type of actor can play this role?
3. EMV payment with PIN uncompliant to SCA requirements
The following are the elements, used in the authentication procedure for EMV face to face payment by card with offline PIN:
• • the PIN code,
• • the EMV card.
However, this authentication procedure does not comply with the Article 6 (Requirements related to the independence of the elements) – paragraph 1.
The PIN code is verified locally by the EMV card, so if the card is compromise (e.g. by forgery) any wrong PIN code can be valid.
Therefore, face to face EMV payment with PIN is not compliant with SCA requirements!
Do-you agree with this assertion?
If so, could modify the RTS in order to make this payment mode compliant.
4. 3.4 Auditors Independence
Article 7 (Review of the strong customer authentication procedure) – paragraph 1 requires that security of the strong customer authentication procedure must be periodically tested, evaluated and audited by internal or external independent and certified auditors.
However, internal auditors cannot be considered as totally independent. Therefore only external, independent and certified auditors must be authorized to evaluate the security of a SCA procedure.
Chapter 4 does not oblige the ASPSP to require the previous express authorization of the payment service user (PSU) before allowing the access to or the use by any other PSP his own personalised security credentials (PSCs provided by ASPSP) for relying the authentication procedure.
In order to protect the European people against abuse usage of his PSCs (e.g. by fraudulent PSP), his express consent to his own PSCs access use or rely is fundamental.
Moreover, the ASPSP must provide the means that allow the PSU to revoke one PSP at any time.
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?
GENERAL REMARKS1 Strong Customer Authentication definition unclear
The draft RTS specifies (as the DSP2) the strong customer authentication is an authentication based on the use of two or more elements categorized as:
• knowledge (something only the user knows),
• possession (something only the user possesses),
• inherence (something the user is),
This specification is unclear because it authorizes 2 elements from the same category (e.g. 2 passwords).
However, the draft RST doesn’t raise this ambiguity; it must clearly exclude the use à 2 elements of the same category.
REMARKS ON CHAPTER 1
2. Transaction dispute
The Article 2 (Strong customer authentication procedure with dynamic linking) – paragraph 1.b includes the requirement of dynamic linking between the transaction amount and the payee by the mean of an Authentication Code.
In case of dispute from the payer about the amount or the payee, what are the evidence that must be provided by the PSP to the payer?
If the “authentication code” is a part of these evidence (required by the DSP2 - Article 72 Evidence on authentication and execution of payment transactions), how can it prevent all repudiation from the payer?
In case of cryptography usage to create this “Authentication Code”(Chapter 3.2.1 – paragraph 24), an independent actor must play the arbitral role of cryptogram verifier in order to solve the dispute. Which type of actor can play this role?
3. EMV payment with PIN uncompliant to SCA requirements
The following are the elements, used in the authentication procedure for EMV face to face payment by card with offline PIN:
• • the PIN code,
• • the EMV card.
However, this authentication procedure does not comply with the Article 6 (Requirements related to the independence of the elements) – paragraph 1.
The PIN code is verified locally by the EMV card, so if the card is compromise (e.g. by forgery) any wrong PIN code can be valid.
Therefore, face to face EMV payment with PIN is not compliant with SCA requirements!
Do-you agree with this assertion?
If so, could modify the RTS in order to make this payment mode compliant.
4. 3.4 Auditors Independence
Article 7 (Review of the strong customer authentication procedure) – paragraph 1 requires that security of the strong customer authentication procedure must be periodically tested, evaluated and audited by internal or external independent and certified auditors.
However, internal auditors cannot be considered as totally independent. Therefore only external, independent and certified auditors must be authorized to evaluate the security of a SCA 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.
NAQuestion 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?
NAQuestion 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?
NAQuestion 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?
NAQuestion 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?
NAQuestion 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?
5. 3.5 Payment Service User credentials protectionChapter 4 does not oblige the ASPSP to require the previous express authorization of the payment service user (PSU) before allowing the access to or the use by any other PSP his own personalised security credentials (PSCs provided by ASPSP) for relying the authentication procedure.
In order to protect the European people against abuse usage of his PSCs (e.g. by fraudulent PSP), his express consent to his own PSCs access use or rely is fundamental.
Moreover, the ASPSP must provide the means that allow the PSU to revoke one PSP at any time.