Response to consultation on RTS specifying the requirements on strong customer authentication and common and secure communication under PSD2
Go back
We are of the opinion that SCA procedure mechanism as described under the Art. 1, para. 3, letter b) prevents current scenario under which a payment card holder is immediately aware of the fact that an incorrect PIN code was input during initiation of the payment transaction. Since we consider current approach quite customer friendly, we would welcome amending referred wording of the draft RTS in the way that excepts PIN codes issued to be used with payment cards from the imposed requirement.
EBA arrives to the view that authentication elements should not be further defined and that EBA should refrain from such definition. While we understand such a standpoint, we are also of the opinion that given requirements related to the relevant authentication elements indirectly define which specific authentication element falls under such a category (and also qualifies in such indirect definition or not). It definitely brings uncertainty whether some authentication elements frequently used e.g. in the payment cards industry may be considered as a compliant authentication element in the future. By the way of example, under application of the PCI DSS measures, we regard 3-tuple (PAN, expiration date, CVV/CVC) as falling within the category described as knowledge. However, features imposed by the draft RTS to such an authentication element cast doubts if such a conclusion is still possible or not. We would therefore welcome, if impact of the requirements for the authentication element categorized as knowledge were excluded in relation to the 3-tuple (PAN, expiration date, CVV/CVC) if PCI DSS measures are employed in remote environments.
In particular, security performance statistics shall be estimated according to ISO/IEC 19795 standard procedures and the results obtained shall be input to the risk analysis process of the account servicing payment service provider.
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?
It becomes obvious as stipulated in the respective PSD2 articles that AS PSP is going to be ultimately liable to the customer for whom the payment account is established and maintained in case any unauthorized transaction occurs; we are of the opinion that it should be also AS PSP who exclusively controls and assesses the risk involved, especially risk concerning usage of the credentials issued to the respective payment services user. We would therefore welcome if the description of EBA's understanding of the interaction between AS PSP and PISP (introduced in the art. 19 a) of rationale) was included in the draft RTS itself (we find recitals of the draft RTS to be appropriate for such insertion).We are of the opinion that SCA procedure mechanism as described under the Art. 1, para. 3, letter b) prevents current scenario under which a payment card holder is immediately aware of the fact that an incorrect PIN code was input during initiation of the payment transaction. Since we consider current approach quite customer friendly, we would welcome amending referred wording of the draft RTS in the way that excepts PIN codes issued to be used with payment cards from the imposed requirement.
EBA arrives to the view that authentication elements should not be further defined and that EBA should refrain from such definition. While we understand such a standpoint, we are also of the opinion that given requirements related to the relevant authentication elements indirectly define which specific authentication element falls under such a category (and also qualifies in such indirect definition or not). It definitely brings uncertainty whether some authentication elements frequently used e.g. in the payment cards industry may be considered as a compliant authentication element in the future. By the way of example, under application of the PCI DSS measures, we regard 3-tuple (PAN, expiration date, CVV/CVC) as falling within the category described as knowledge. However, features imposed by the draft RTS to such an authentication element cast doubts if such a conclusion is still possible or not. We would therefore welcome, if impact of the requirements for the authentication element categorized as knowledge were excluded in relation to the 3-tuple (PAN, expiration date, CVV/CVC) if PCI DSS measures are employed in remote environments.
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.
Yes, we agree.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?
Since the requirements imposed to the authentication elements categorized as inherence clearly relates to biometric enrolment, verification and authentication, we suggest to incorporate reference to the relevant ISO standards. In this perspective, we suggest to insert last sentence to the Art. 5, para. 1 as follows:In particular, security performance statistics shall be estimated according to ISO/IEC 19795 standard procedures and the results obtained shall be input to the risk analysis process of the account servicing payment service provider.