SPA supports the needs to protect the consumer at a time when a broad range of new technologies are available to pay.

SPA agrees that generalizing the strong customer authentication (SCA) process minimizes the risk of customer impersonation. Furthermore, these requirements for SCA preserve the real freedom of choice of a particular payment instrument. However, the exemptions regime should be extended - Please refer to our answer to Q4.

Art 1.2 Reformulate as: « The authentication code shall be characterized by security features ensuring that : »
Rationale: this is a non exhaustive list that mixes security and non-security properties in an inconsistent and confusing way.

Art 1 3(b) refers to « incorrect » . The meaning of this term is unclear. Do you refer to failure to authenticate the customer whatever the reason?. At present in card F2F payment transactions, the CH is informed in real time if the entered PIN code was wrong. More clarification for management of knowledge-based authentication elements is needed.
As follows
In Art 1.2 (b) remove the last part of the requirement «  for the same payer »

Art 2.2 (b). Replace the current requirement by: «  The technical solution used to generate the authentication code shall guarantee that the data displayed to the customer (amount, payee) are identical to those used to generate the authentication code and to execute the payment. This could be achieved by e.g. is if the channel, device or mobile application through which the information linking the transaction to a specific amount and a specific payee is displayed independent or segregated from the channel, device or mobile application used for initiating the electronic payment transaction as well as an evaluated and certified device with a suitable security assurance level ».

Art 5.1 complete the last sentence by adding( : « as well as an authorized party being rejected ».
Art 3(d) HTTP over TLS should be mentioned as an example not a requirement ( technological neutrality principle)

Art 2.3 Implementation of Art 2.3 and 2.4 may be difficult if the data used to calculate the authentication code ( using dynamic linking) is different from the final amount to be paid. In this case we recommend to add an additional requirement stating that: « the data used during the dynamic linking shall be transmitted along with the payment amount in the authorization message ».

Some further clarification is required in the provisions of Article 6

Article 6 paragraph 1 refers to the the term « reliability » which is not appropriate, even if consistent with Article 4(30) of the PSD2 . Reliability is a term indicating the probability of good operation of a device at a given time «T » assuming that the device is functional at time « 0 », when the device is working in a pre-established physical environmental, not being hacked. Formaly speaking, the terms used in the definition of SCA proposed by SecurePay were more accurate: « …. The breach of one authenticator does not impact the level of security of the other authenticator .

Article 6 paragraph 3 refers to the fact that mobile devices and tablets shall « implement a separated trusted execution environment ». This point should be further clarified, especially considering that all mobile devices used to pay include some kind of « separated » execution environment. However these executions environments don’t feature the same security properties( e.g, a certified hardware tamper resistant device vs a software implementation).

Therefore the term « trusted execution environment » should be defined and how the « independence of elements » applies in that scenario. In particular if the term « separated » is equivalent to « independent from the security point of view ».

The statement « ..including but not limited to mobile phones and tablets » should be rewriten as «  multipurpose devices, e.g. mobile devices and tablets ». This comment applies as well to others articles, where the references to specific devices should clearly indicate that they are just examples.

It’s is unclear to what kind of neutrality Article 2.2 refers to. The same applies to the concept of « channel » (logical ? physical ?).

This neutrality could be better expressed with a requirement such as : the « dynamic linking » procedure should guarantee that the information used to generate the authentication code is the same than the payment information displayed to the payer (refer to Q1).

At the same time « independent or segregated » are ambiguous terms that should be defined. In the way it is expressed, the requirement seems to counter the risk of a man-in-the-middle attack in online payment contexts or to prevent relay attacks for contactless transactions

Article 5 properly refers to the need the « inherence element » guarantees a « sufficient low likehood » of an unauthorized party being authenticated as the legitimate enrolled user. This « sufficient low likehood » should be proven by the compliance of the inherence element with the performance requirements set forth by international standards.

The list of exemptions should be extended to an additional scenario, « enhanced authentication » for efficient fraud reducing technologies, having proven value in field .

An example is a card generating a dynamic code which is displayed and then can either be entered manually for an e-commerce transaction or being transmitted from a mobile application.
Because a contactless card cannot be forged, a contactless transaction can only be executed with a legitimate card. However this card can be used to pay an amount under 50 Euros by anyone being in possession of the card.
A card generating a dynamic code, proves to the issuer that the payer is in possession of a legitimate card to pay. From the risk point of view, the situation is similar to the case of the contactless card, provided that the dynamic code is encrypted. Moreover, the issuer in that case can proceed to a risk management procedure that will provide additional evidence that the payer is likely the cardholder. Therefore from the security point of view it’s not justified that a contactless card may benefit from exemptions while a card using a dynamic code would not.
The amounts 10 Euros, 50 Euros, 100 and 150 Euros appear arbitrary and likely to be subject to frequent future changes. These thresholds should be regularly reviewed and adapted by the EBA.

Art 8.2 (a) to ( c ) vs Art 8.2(d) benefits the use of credit transfers for remote payments and discriminates other payment Binstruments, infringing the principle of « technological neutrality ».

We don’t believe that the RTS should prevent a PSP to execute a SCA procedure even if the transaction falls under any of the exemptions set forth in Chapter 2.

The rationale for the protection of the confidentiality and the integrity of Personal Security Credentials (PSC) is correct, because according to Chapter 3, the security of the payment relies on the security of the PSC. With this regard, Chapter 3 includes provisions covering the overall operational life of the PSC and therefore can be considered as complete.

Can the same PSC be bound with different payment instruments issued by the same PSP?

We suggest to add the term « sensitive data » Art 9 1.b « Sensitive Personalized Security Credentials »

Art 17.1 as written excludes the current card-based EMV payment systems which only support unilateral authentication of the card.

Art 19.2 ( c ) Authentication codes may already be cryptographically protected. It seems as if Art 19 refers to security at the Transport Layer level protocol.

ISO 20022 constitutes a step forward
The technical constraints are twofold:
First is the fact that at present there are few ISO 20022-compliant implementations
Second: ISO 20022 is a collection of data elements and messages not a protocol meaning that by itself ISO 20022 doesn’t guarantee fully interoperability.

SPA agrees 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 with a respective capability (such as computers, tablets and mobile phones), but would as well emphasise the need of respective E2E device authentication protocols regarding eID management and remote administration regarding for tamper resistant devices in charge of all sensitive keys as encipherment keys and keys ensuring the integrity ( authenticity).
Together with the referred generic privacy requirement, the qualified trust services, especially the seal services, are described very explicitly in the eIDAS regulation fulfilling data originality and data integrity to be applied for legal persons as e.g. AIS, PIS and ASPSDs. The gain of this new concept is that qualified seals are accepted as such European–wide and cannot be interpreted differently as it was the case with qualified signatures before, as substitute for “handwritten signatures”

The Smart Payment Association (SPA) is an organization composed of the 6 major card payment manufacturers: Austria Card, Gemalto, Giesecke&Devriendt, Incard, Morpho and Oberthur to collaborate in standardization activities

SPA provides regularly with freely accessible white papers and paper positions in areas of interest for the retail payments industry
SPA provides the industry with accurate figures on payment cards sales worldwide.
SPA is an active contributor in financial standards-setting organizations , including the ECSG, EMVCo, PCI , ISO TC68 and IUT-T Focus Group on Financial inclusion
and systematically participates in public consultations on draft regulatory texts having an impact on the retail payment industry.