Response to consultation on RTS specifying the requirements on strong customer authentication and common and secure communication under PSD2
Go back
We however consider that some clarifications or precisions of the RTS text would be relevant:
o About “who is acting in the customer’s authentication process. Our understanding is that:
- ASPSPs must provide authent methods, have them available for TPPs asking for them, and providing authent codes etc.
- TPPs have the possibility to rely on ASPSPs’ authent methods and codes, solely or in addition to their owns
- TPPs have the right to perform only their own authent (SCA of course) and create the authent code on its own, not asking anything from ASPSP at time of operation, if they have an agreement with ASPSP (Consultation paper 3.2.1.19.a)
These statements (if our understanding is correct) are clearly described in the Consultation Paper, but do not appear explicitely in the RTS, especially the third statement here above. An explicit redaction would be useful.
o RTS Chapter 1/article 2.2.b specifies “The channel, device or mobile application through which the information linking the transaction to a specific amount and a specific payee is displayed shall be independent or segregated from the channel, device or mobile application used for initiating the electronic payment transaction.”. Our understanding is that:
- “independent or segregated” means “different as the breach of an element does not compromise the other one”
- To comply with this requirement
o The channel through which the information linking the transaction to a specific amount and a specific payee is displayed shall be independent or segregated from the channel used for initiating the electronic payment transaction
o Or the device on which the information linking the transaction to a specific amount and a specific payee is displayed shall be independent or segregated from the device used for initiating the electronic payment transaction
o Or the mobile application through which the information linking the transaction to a specific amount and a specific payee is displayed shall be independent or segregated from the mobile application used for initiating the electronic payment transaction
o As an example, having 2 different applications, an eCommerce App initiating the payment, and a banking App performing OTP based Auth, on the same device and using 4G channel, would comply with the requirement.
-
If this understanding is not correct, additional explanations in the text would be useful
o The concept of Personalized security credentials (PSC) is widely described in the RTS, that also include requirements related to their generation, security and usage. We understand EBA’s concern to not define more in details what are PSCs, but would appreciate having a minimal list of elements whose presence in the PSCs would be mandatory
o In addition, we understand that SCA procedures certifications, mentionned in several parts of the text, would give way to further EBA’s Works and communications in order to define when, how and by whom will the certified auditors be appointed, and what would be their mandate.
But the main clarifications we would consider relevant address the field and targets of PSD2 and RTS:
o Recital 1 explains RTS are not limited to remote payments, and cover all electronic payments. By the way, contactless face to face payments are explicitely mentionned in several parts of the text
o Recital 2 explains that “[…] remote payment transactions are subject to a higher risk […]”
o We understood that EBA consider, at least concerning EMV card payments, that the situation is rather satisfying for (contact) face to face payment
o As a matter of fact, we understand that EMV card payments relying on chip and PIN do comply with PSD2 and RTS
o A clear statement, possibly from the initial recitatives, of the field RTS are covering and on the status of current face to face payment modes that exist in Europe with regard to this regulation would be useful for all actors to understand that the investments they made in the domain satisfy PSD2, or, if it is not the case, to measure additional efforts to engage
o About Direct Debit:
o Consultation Paper 3.2.1.17 states that Direct Debit are out of RTS the scope, according to PSD2 97.1.b
o Consultation Paper 3.2.1.18 however states that “if the payer’s consent for a direct debit transaction is given in the form of an electronic mandate” RTS shall apply
o RTS explicitely address Credit Transfers, but never mention Direct Debit (in the limits of Consultation Paper 3.2.1.18)
o This could lead to misinterpretations of the RTS considering all forms of Direct Debit as out of scope
o We so consider a minimal set of references to Direct Debit (in the limits of Consultation Paper 3.2.1.18), rules or exemptions, would be relevant
o And in a general manner, clarifications are necessary on the rules to be applied in the transition phase, keeping in mind that the actors of the payment industry need reasonable delays to integrate changes that may be significant.
- To integrate and generalize SCA processes and methods. As we already mentionned it, we welcome this requirement
- To adapt the security measures to the transactions’ actual level of risk
Considering this second point, our analyze of PSD2 was that ASPSPs might take their risk. Actually, if they considered, using risk management tools, that a transaction's risk was low, they might decide not to trigger full SCA processes for this transaction, in order to ease user convenience. Typically, a 3D-Secure process in the card payment context might have followed such a scenario.
RTS clearly prohibit such an approach.
Maintaining this position in the RTS potentially generates 2 kinds of risk on remote payment:
- Accept only complicate customers’ payment journeys, that seems in contradiction with PSD2 objectives to encourage the electronic payment development, and to adapt security measures to the actual risk level in order to improve user convenience
- Encourage all but virtuous behaviors from players, especially merchants or processors, as uncontrolled crossborder operations outside of PSD2 reach
We so disagree with this approach we consider too restrictive and not user convenience oriented.
In addition, we think clarifications of the text would be useful
- Chapter 2 Article 1.a: The text refers to sensitive data". Consultation paper / 3.2.2.50 states that EBA did not wish to give further definition. A list of minimal mandatory elements considered as “sensitive data” woud however be useful.
- Chapter 2 Article 2.a: Does the exemption "List of trusted beneficiaries" apply (on a stable list, see text) for any operation/payment on this list, whatever amount, date, etc.?"
See however our remark about PSCs, in our answer to Question 1.
In addition, we understand that SCA procedures certifications would give way to further EBA’s Works and communications in order to define when, how and by whom will the certified auditors be appointed, and what would be their mandate.
Our first remark is that RTS, Recital 12 may be read as a simple recommandation in favor of ISO 20022, where the Consultation Paper seems to consider this standard as the solution to implement. A clarification would be useful to understand if ISO 2002 is a requirement or only a recommendation.
However, it should be underlined that ISO 20022 might lead to various instantiations, with a resulting risk on interoperability. EBA should so encourage and support interested parties in convergence approaches aiming at elaborate actual common instantiations.
Our understanding is that e-IDAS policy and processes would be:
- Mandatory for PSPs mutual identifications
- Optional for SCA processes
If this understanding is not correct, further clarifications of the text would be useful.
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?
Gemalto acknowledge and welcome EBA strong orientation to request Strong Customer authentication in order to improve security of the electronic payment and consumers’ protection.We however consider that some clarifications or precisions of the RTS text would be relevant:
o About “who is acting in the customer’s authentication process. Our understanding is that:
- ASPSPs must provide authent methods, have them available for TPPs asking for them, and providing authent codes etc.
- TPPs have the possibility to rely on ASPSPs’ authent methods and codes, solely or in addition to their owns
- TPPs have the right to perform only their own authent (SCA of course) and create the authent code on its own, not asking anything from ASPSP at time of operation, if they have an agreement with ASPSP (Consultation paper 3.2.1.19.a)
These statements (if our understanding is correct) are clearly described in the Consultation Paper, but do not appear explicitely in the RTS, especially the third statement here above. An explicit redaction would be useful.
o RTS Chapter 1/article 2.2.b specifies “The channel, device or mobile application through which the information linking the transaction to a specific amount and a specific payee is displayed shall be independent or segregated from the channel, device or mobile application used for initiating the electronic payment transaction.”. Our understanding is that:
- “independent or segregated” means “different as the breach of an element does not compromise the other one”
- To comply with this requirement
o The channel through which the information linking the transaction to a specific amount and a specific payee is displayed shall be independent or segregated from the channel used for initiating the electronic payment transaction
o Or the device on which the information linking the transaction to a specific amount and a specific payee is displayed shall be independent or segregated from the device used for initiating the electronic payment transaction
o Or the mobile application through which the information linking the transaction to a specific amount and a specific payee is displayed shall be independent or segregated from the mobile application used for initiating the electronic payment transaction
o As an example, having 2 different applications, an eCommerce App initiating the payment, and a banking App performing OTP based Auth, on the same device and using 4G channel, would comply with the requirement.
-
If this understanding is not correct, additional explanations in the text would be useful
o The concept of Personalized security credentials (PSC) is widely described in the RTS, that also include requirements related to their generation, security and usage. We understand EBA’s concern to not define more in details what are PSCs, but would appreciate having a minimal list of elements whose presence in the PSCs would be mandatory
o In addition, we understand that SCA procedures certifications, mentionned in several parts of the text, would give way to further EBA’s Works and communications in order to define when, how and by whom will the certified auditors be appointed, and what would be their mandate.
But the main clarifications we would consider relevant address the field and targets of PSD2 and RTS:
o Recital 1 explains RTS are not limited to remote payments, and cover all electronic payments. By the way, contactless face to face payments are explicitely mentionned in several parts of the text
o Recital 2 explains that “[…] remote payment transactions are subject to a higher risk […]”
o We understood that EBA consider, at least concerning EMV card payments, that the situation is rather satisfying for (contact) face to face payment
o As a matter of fact, we understand that EMV card payments relying on chip and PIN do comply with PSD2 and RTS
o A clear statement, possibly from the initial recitatives, of the field RTS are covering and on the status of current face to face payment modes that exist in Europe with regard to this regulation would be useful for all actors to understand that the investments they made in the domain satisfy PSD2, or, if it is not the case, to measure additional efforts to engage
o About Direct Debit:
o Consultation Paper 3.2.1.17 states that Direct Debit are out of RTS the scope, according to PSD2 97.1.b
o Consultation Paper 3.2.1.18 however states that “if the payer’s consent for a direct debit transaction is given in the form of an electronic mandate” RTS shall apply
o RTS explicitely address Credit Transfers, but never mention Direct Debit (in the limits of Consultation Paper 3.2.1.18)
o This could lead to misinterpretations of the RTS considering all forms of Direct Debit as out of scope
o We so consider a minimal set of references to Direct Debit (in the limits of Consultation Paper 3.2.1.18), rules or exemptions, would be relevant
o And in a general manner, clarifications are necessary on the rules to be applied in the transition phase, keeping in mind that the actors of the payment industry need reasonable delays to integrate changes that may be significant.
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, provided that our understanding of the text is correct, as presented in our answer to Question 1 here above. If not, at least some additional clarifications would be useful.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?
There are no comments from Gemalto to this question.Question 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?
Gemalto consider PSD2, in its concern to help electronic payment development, asks ASPSPs:- To integrate and generalize SCA processes and methods. As we already mentionned it, we welcome this requirement
- To adapt the security measures to the transactions’ actual level of risk
Considering this second point, our analyze of PSD2 was that ASPSPs might take their risk. Actually, if they considered, using risk management tools, that a transaction's risk was low, they might decide not to trigger full SCA processes for this transaction, in order to ease user convenience. Typically, a 3D-Secure process in the card payment context might have followed such a scenario.
RTS clearly prohibit such an approach.
Maintaining this position in the RTS potentially generates 2 kinds of risk on remote payment:
- Accept only complicate customers’ payment journeys, that seems in contradiction with PSD2 objectives to encourage the electronic payment development, and to adapt security measures to the actual risk level in order to improve user convenience
- Encourage all but virtuous behaviors from players, especially merchants or processors, as uncontrolled crossborder operations outside of PSD2 reach
We so disagree with this approach we consider too restrictive and not user convenience oriented.
Question 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?
To illustrate and complement our reaction to Question 4 here above, we would wish to underline that RTS approach, in the sense we understand it, disregards existing solutions that prove their efficiency in fighting against fraud, even if they do not strictly comply with SCA requirements. The typical example we would like to underline is the one of dynamic CV cards, possibly used in combination with 3D-Secure in order to balance security and user convenience. In the context of RTS “as is”, dynamic CV cards will lose a great part of their attractiveness, as, in parallel, uncontroled channels as Mail Order will not be regulated, increasing the risk of fraud deport on such unsecure channels.In addition, we think clarifications of the text would be useful
- Chapter 2 Article 1.a: The text refers to sensitive data". Consultation paper / 3.2.2.50 states that EBA did not wish to give further definition. A list of minimal mandatory elements considered as “sensitive data” woud however be useful.
- Chapter 2 Article 2.a: Does the exemption "List of trusted beneficiaries" apply (on a stable list, see text) for any operation/payment on this list, whatever amount, date, etc.?"
Question 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?
There are no comments from Gemalto to this question.See however our remark about PSCs, in our answer to Question 1.
In addition, we understand that SCA procedures certifications would give way to further EBA’s Works and communications in order to define when, how and by whom will the certified auditors be appointed, and what would be their mandate.
Question 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?
Gemalto acknowledges EBA’s requirements for common and secure open standards of communication.Question 8: In particular, do you agree that the use of ISO 20022 elements, components or approved message definitions, if available, should be required to ensure the interoperability of different technological communication solutions implemented between PSPs for the provision of AIS, PIS or for the confirmation on the availability of funds? Do you see any particular technical constraint that would prevent the use of such industry standards?
Gemalto acknowledges EBA’s position in favor of ISO 20022 elements usage.Our first remark is that RTS, Recital 12 may be read as a simple recommandation in favor of ISO 20022, where the Consultation Paper seems to consider this standard as the solution to implement. A clarification would be useful to understand if ISO 2002 is a requirement or only a recommendation.
However, it should be underlined that ISO 20022 might lead to various instantiations, with a resulting risk on interoperability. EBA should so encourage and support interested parties in convergence approaches aiming at elaborate actual common instantiations.
Question 9: With regards to identification between PSPs, do you agree 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 (such as computers, tablets and mobile phones) for carrying out different payment services ?
Gemalto acknowledges and welcomes EBA’s position in favor of e-IDAS policy.Our understanding is that e-IDAS policy and processes would be:
- Mandatory for PSPs mutual identifications
- Optional for SCA processes
If this understanding is not correct, further clarifications of the text would be useful.