Raiffeisenbank a.s., Czech Republic

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.
Yes, we agree.
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.
It is apparent that situations in which requirement for SCA or requirement for additional dynamic linking of the transaction with a specific amount and a specific payee shall not apply, does not allow AS PSP to implement any risk assessment policy. The draft RTS in chapter 3 introduces rather prescriptive list of details in which requirement for SCA or dynamic linking as mentioned above is exempted. We would welcome if the draft RTS enables AS PSP to implement possible exceptions based on the assessment of risk involved in the service provided and therefore based on rather higher level standards to which AS PSP are expected to adapt, shall they decide not to apply SCA or the requirement for additional dynamic linking in appropriate cases.
Provided that the draft RTS keeps following principle based on exhaustive list of exemptions, under which the transaction falls in scenario where SCA or additional dynamic linking is no longer required, we are of the opinion that none of these exemptions should be regarded mandatory.
Yes, we agree.
In our perspective, requirement of the Art. 17 para. 1 can be hardly achieved in a secure way for the EMV card transactions, internet browser access, and as the case may be remote phone access to the call centre. In the first situation, there are no means for a terminal-to-card authentication. In the remaining two cases, the payer is using a general electronic device that the account servicing payment service provider cannot identify in a secure way. Therefore, we suggest deleting Art. 17 para. 1.
Yes, we agree.
Yes, we agree.
Yes, we agree.
[Credit institution"]"
[Issuing of payment instruments and/or acquiring of payment transactions"]"
Yes
michal.brodsky@rb.cz
Michal Brodsky
+420602108884
Yes