GENERAL REMARKS

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.

5. 3.5 Payment Service User credentials protection
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.

IT, security and consulting company in payment system and services (250 employees).

Galitt offers consulting and services dedicated to payment systems and secure electronic transactions. With a full set of recognized skills and know-how, Galitt assists its clients during the whole project life cycle: experts from the Payment Consulting Unit with their innovative approaches shed light on strategic choices; consultants from the Payment Services Unit support customers implementing their payment projects; teams from Testing Solutions Unit develop test software and take an active role in test automation and certification processes; staff from the Payment Solutions Unit build and run added-value payment applications; trainers from the Payment Education Unit broadcast Galitt expertise and skills during their seminars