Response to consultation on RTS specifying the requirements on strong customer authentication and common and secure communication under PSD2
Go back
However, we would welcome clarification from the EBA on the following elements: certain terms defined in chapter 1 can be interpreted in multiple ways, which could affect the level of security effectively ensured and the associated European level playing field.
Firstly, we would like to point out that the term “authentication code” used throughout chapter 1 creates confusion between two distinct notions, i.e. the “authentication” of the client, and the “authorization” of the transaction.
It is our understanding that in article 1, “authentication code” refers only to the code that enables the PSP to verify the identity of the client.
By contrast, in article 2, we understand that “authentication code” refers to the code used during the authorization phase, which is better known as a “non-repudiation code”, or “authorization code” in IT security lexicon.
Therefore, for clarity purposes, we propose to replace “authentication code” with “non-repudiation code” in article 2. The non-repudiation code embraces all the required functions: it allows for the authentication of the user, guarantees the integrity of the transaction data, and ensures that the transaction cannot be denied or replayed.
Furthermore, we are unsure about the applicability of strong customer authentication as defined in Chapter 1 to some processes currently in use, such as EBICS/SWIFTNet (host to host protocols).
In the context of file transfer, corporate solutions propose to give the confirmation of a batch payment order:
• Either when transmitting the file (with EBICS TS, when the corporate user personally signs the file using cryptography)
• Or, through confirmation of the file transfer on a web application that includes a dynamic linking on the basis of the file’s principal data (e.g.: EBICS T + web confirmation)
In both cases, the certificate used by the corporate user to authenticate himself or sign the payment order is not necessarily delivered by the ASPSP. However, we do not believe that such practices represent a potential breach in security. Indeed, it is our opinion that security risk is already accounted for, both in the regulations that trust service providers must comply with, and in the processes themselves (notably through secure encryption and dynamic linking).
Regarding Article 1.3.a), we understand “time out” to mean that the payer’s connection to his or her online payment account should be closed after a certain period of inactivity. However, “time out” may potentially refer to other settings, such as “maximum time allowed” (intended to prevent unrequested robot activity).
Article 1.3.a) should then be amended as follows : (“time out” meaning the customer’s logout after a session time limit with no activity)
Regarding Article 1.3.d), for security reason, we would suggest replacing “HTTP over TLS” with “HTTP 1.1 minimum over TLS v.1.2 minimum”.
Further along, concerning Article 1.3.e), we would like to point out that some efficient fraud detection systems only include four out of the five proposed mechanisms, but compensate for it by making use of additional indicators, such as IP addresses used for connexion. In order to take such systems into account, we propose to replace “shall” by “may”.
Besides, we suggest expanding mechanism i.: in our opinion, “the blacklists of compromised IBANs” should be included into the parameterised rules taken into account by PSPs.
Moreover, we would welcome the inclusion in a recital of the rationale 19.a), which explicitly states that the authentication procedure remains fully in the sphere of competence of the ASPSP whenever PISPs rely on the procedure provided by the ASPSP to the user:
« In accordance with Article 97(5), PISPs have the right to rely on the authentication procedures provided by the account servicing payment service provider (ASPSP) to the user. In such cases, the authentication procedure will remain fully in the sphere of competence of the ASPSP. The only situation when the transaction would be authenticated within the sphere of competence of the PISP is when a PISP issues its own personalised security credentials for the user, in place of the credentials issued by the ASPSP. This would however require a prior contractual agreement between the PIS and the ASPSP on the acceptance of such credentials by ASPSP. Such agreement would also be outside of the scope of PSD2.»
Regarding 2.1.a), we suggest replacing “at all times” with “for each transaction and before giving consent”, for a better understanding and for the sake of customer convenience.
Regarding 2.2.b), we would like to point out that the wording currently used may be misleading, as it can be interpreted to mean that the use of two distinct devices is required for compliance with SCA standards, which does not fit current and future consumers behaviour. Moreover, it is our understanding that the use of two separate mobile applications is compliant. If this is indeed the correct interpretation, we suggest amending the last sentence as follow: “the channel, [device - to be cut] or mobile application through which the information linking the transaction to a specific amount and a specific payee is displayed shall be [logically] independent or segregated from the channel, [device - to be cut] or mobile application used for initiating the electronic payment transaction”.
On the same subject, we would like the EBA to clarify whether the “separated trusted execution environment” mentioned in article 6.3.a) is referring to the Global Platform standard “Trusted Execution Environment”.
We are not opposed to the implementation of such a standard in the future, but would like to stress that it is currently technically unfeasible, since not all smartphones are compatible with this technology yet.
Regarding 2.4, we would welcome clarification on the notion of “batch”. It is our understanding that “batch” refers to any batch or set of payments made to multiple payees. We also understand “considered collectively” to mean that only the number of transactions needs to be displayed, rather than a list of all the payees designated by name. For instance, in the case of corporate clients signing their files of payment orders made to several payees (i.e. pay roll, suppliers payments file,..), only the total amount of the transactions and the number of transactions should be displayed.
Regarding 3.1, questions occur about length and expiration time required when the element is categorised as knowledge.
For instance, the PIN code of a card is usually defined with 4 digits, nonetheless the security of the PIN code lies in the maximum number of failed authentication attempts. Moreover, the PIN code does not have any expiration time but the card does have one.
Article 3.1 shall be amended as follows : “The elements of strong customer authentication categorized as knowledge shall be characterized by security features [including but not limited to - to be cut] [such as] length, complexity, expiration time and the adequate policy for use of non-repeatable characters ensuring resistance against the risk of the elements being uncovered or disclosed to unauthorized parties’’.
Regarding 4.2., in order to account for the fact that PSPs do not manage SIM cards, we suggest amending the phrase as follow: “the use of elements categorized as possession shall be subject to measures designed to prevent replication of the elements, including in particular anti-cloning features, [when possible,] to offer resistance against the risks of forging and cloning of the elements”.
Following the same reasoning, we deplore the absence of an exemption based on transaction-risk analysis. The EBA’s choice not to include a risk-based exemption was made in spite of the fact that such an exemption is provided for in the directive itself, as explicitly stated in Article 98.3.a): the exemptions specified by the EBA should be based on certain criteria, among which “the level of risk involved in the service provided”.
Indeed, we are of the opinion that as long as ASPSPs remain liable for risk management and in charge of protecting the customer’s funds, they should be left free to apply their own risk analysis and therefore apply strong customer authentication if needed.
Regarding article 8. 2. d) ii, we would welcome some clarification on the cumulative amount of previous remote electronic payment transactions : is it a cumulative amount calculated on each payment instrument provided to the PSU or is it a unique cumulative amount irrespective of the payment instrument used by the PSU ?
To begin with, the authentication procedures remain fully in the sphere of competence of the ASPSP, as mentioned in rationale 19. Therefore, the ASPSP should be left free to implement SCA according to its own risk analysis, including on transactions that normally meet the criteria for exemptions, in particular for fraud risk mitigation purpose.
Allowing such risk-based analyses, provided for in article 98.3.a) of the directive, and hinted at in rationale 46, seems justified for reasons of liability, since ASPSPs are considered liable for risk management.
Besides, we are extremely concerned about the risk of fraudsters exploiting the mandatory nature of exemptions to develop new fraud scenarios (such as massive attacks on low-value payments). ASPSPs would then be unable to react in a proportionate, risk-based manner.
Moreover, making exemptions mandatory would prevent some ASPSPs from complying with stricter national requirements.
However, regarding Article 9.1.a), we would welcome clarifications from the EBA on the elements that are included under the phrase “data on personalized security credentials”.
We are unsure about the way this paragraph should be implemented in the case of one-time passwords displayed on a smartphone screen during the authorization phase of the transaction.
We are also unsure about the applicability of Article 12.b), which requires the implementation of SCA for the association of a PSU’s identity with personalized security credentials, payment instruments or authentication devices or software. Indeed, SCA requires the PSP to associate the user with elements of knowledge, possession and/or inherence that have been linked to the client making the request; as a consequence, we fail to see how the PSP could apply SCA to a user it has not registered yet.
Yet as already mentioned in our answer to EBA’s discussion paper, we do believe that the quality of the enrolment of the PSU is of utmost importance.
Regarding 17.1, we would like to point out that “secure bilateral identification” is not possible in the case of card transactions. Current card specifications (EMV) do not provide for “bilateral identification” between cards or mobile devices and payment terminals, since the card device is unable to identify the terminal. This situation is unlikely to change in the near future, since EMV 20125 is not expected to provide for mutual authentication either.
Regarding Article 19, we approve of the obligation for ASPSPs to offer a communication interface for PISPs and AISPs. However, we suggest including into Article 19 the rational 69.a), which requires TPPs to use the communication interface that is made available to them, on a mandatory basis.
We would like to point out that even though ISO 20022 ATICA messages already exist for the card payment environment, they are not currently in use.
Therefore, we propose to add to Article 19 a paragraph stating that TPPs gaining access to a communication interface must take into account the technical limitations of this interface, when the ASPSP makes them public. For instance, TPPS should avoid, whenever possible, connecting to the interface in the time windows where the risk of denial of service is at its highest. Those time windows should be displayed by the ASPSP.
We would like to point out that we cannot determine whether the information is actively requested by the PSU himself or not.
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?
The group CA welcomes the EBA’s approach of high level principles for strong customer authentication requirements as new technological solutions will come.However, we would welcome clarification from the EBA on the following elements: certain terms defined in chapter 1 can be interpreted in multiple ways, which could affect the level of security effectively ensured and the associated European level playing field.
Firstly, we would like to point out that the term “authentication code” used throughout chapter 1 creates confusion between two distinct notions, i.e. the “authentication” of the client, and the “authorization” of the transaction.
It is our understanding that in article 1, “authentication code” refers only to the code that enables the PSP to verify the identity of the client.
By contrast, in article 2, we understand that “authentication code” refers to the code used during the authorization phase, which is better known as a “non-repudiation code”, or “authorization code” in IT security lexicon.
Therefore, for clarity purposes, we propose to replace “authentication code” with “non-repudiation code” in article 2. The non-repudiation code embraces all the required functions: it allows for the authentication of the user, guarantees the integrity of the transaction data, and ensures that the transaction cannot be denied or replayed.
Furthermore, we are unsure about the applicability of strong customer authentication as defined in Chapter 1 to some processes currently in use, such as EBICS/SWIFTNet (host to host protocols).
In the context of file transfer, corporate solutions propose to give the confirmation of a batch payment order:
• Either when transmitting the file (with EBICS TS, when the corporate user personally signs the file using cryptography)
• Or, through confirmation of the file transfer on a web application that includes a dynamic linking on the basis of the file’s principal data (e.g.: EBICS T + web confirmation)
In both cases, the certificate used by the corporate user to authenticate himself or sign the payment order is not necessarily delivered by the ASPSP. However, we do not believe that such practices represent a potential breach in security. Indeed, it is our opinion that security risk is already accounted for, both in the regulations that trust service providers must comply with, and in the processes themselves (notably through secure encryption and dynamic linking).
Regarding Article 1.3.a), we understand “time out” to mean that the payer’s connection to his or her online payment account should be closed after a certain period of inactivity. However, “time out” may potentially refer to other settings, such as “maximum time allowed” (intended to prevent unrequested robot activity).
Article 1.3.a) should then be amended as follows : (“time out” meaning the customer’s logout after a session time limit with no activity)
Regarding Article 1.3.d), for security reason, we would suggest replacing “HTTP over TLS” with “HTTP 1.1 minimum over TLS v.1.2 minimum”.
Further along, concerning Article 1.3.e), we would like to point out that some efficient fraud detection systems only include four out of the five proposed mechanisms, but compensate for it by making use of additional indicators, such as IP addresses used for connexion. In order to take such systems into account, we propose to replace “shall” by “may”.
Besides, we suggest expanding mechanism i.: in our opinion, “the blacklists of compromised IBANs” should be included into the parameterised rules taken into account by PSPs.
Moreover, we would welcome the inclusion in a recital of the rationale 19.a), which explicitly states that the authentication procedure remains fully in the sphere of competence of the ASPSP whenever PISPs rely on the procedure provided by the ASPSP to the user:
« In accordance with Article 97(5), PISPs have the right to rely on the authentication procedures provided by the account servicing payment service provider (ASPSP) to the user. In such cases, the authentication procedure will remain fully in the sphere of competence of the ASPSP. The only situation when the transaction would be authenticated within the sphere of competence of the PISP is when a PISP issues its own personalised security credentials for the user, in place of the credentials issued by the ASPSP. This would however require a prior contractual agreement between the PIS and the ASPSP on the acceptance of such credentials by ASPSP. Such agreement would also be outside of the scope of PSD2.»
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.
We agree with the EBA’s reasoning on dynamic linking, but we would like to make a few comments and propose some amendments:Regarding 2.1.a), we suggest replacing “at all times” with “for each transaction and before giving consent”, for a better understanding and for the sake of customer convenience.
Regarding 2.2.b), we would like to point out that the wording currently used may be misleading, as it can be interpreted to mean that the use of two distinct devices is required for compliance with SCA standards, which does not fit current and future consumers behaviour. Moreover, it is our understanding that the use of two separate mobile applications is compliant. If this is indeed the correct interpretation, we suggest amending the last sentence as follow: “the channel, [device - to be cut] or mobile application through which the information linking the transaction to a specific amount and a specific payee is displayed shall be [logically] independent or segregated from the channel, [device - to be cut] or mobile application used for initiating the electronic payment transaction”.
On the same subject, we would like the EBA to clarify whether the “separated trusted execution environment” mentioned in article 6.3.a) is referring to the Global Platform standard “Trusted Execution Environment”.
We are not opposed to the implementation of such a standard in the future, but would like to stress that it is currently technically unfeasible, since not all smartphones are compatible with this technology yet.
Regarding 2.4, we would welcome clarification on the notion of “batch”. It is our understanding that “batch” refers to any batch or set of payments made to multiple payees. We also understand “considered collectively” to mean that only the number of transactions needs to be displayed, rather than a list of all the payees designated by name. For instance, in the case of corporate clients signing their files of payment orders made to several payees (i.e. pay roll, suppliers payments file,..), only the total amount of the transactions and the number of transactions should be displayed.
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?
We do not identify other threats; however, we express concern about some requirements related to security features.Regarding 3.1, questions occur about length and expiration time required when the element is categorised as knowledge.
For instance, the PIN code of a card is usually defined with 4 digits, nonetheless the security of the PIN code lies in the maximum number of failed authentication attempts. Moreover, the PIN code does not have any expiration time but the card does have one.
Article 3.1 shall be amended as follows : “The elements of strong customer authentication categorized as knowledge shall be characterized by security features [including but not limited to - to be cut] [such as] length, complexity, expiration time and the adequate policy for use of non-repeatable characters ensuring resistance against the risk of the elements being uncovered or disclosed to unauthorized parties’’.
Regarding 4.2., in order to account for the fact that PSPs do not manage SIM cards, we suggest amending the phrase as follow: “the use of elements categorized as possession shall be subject to measures designed to prevent replication of the elements, including in particular anti-cloning features, [when possible,] to offer resistance against the risks of forging and cloning of the elements”.
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?
We fully support the EBA’s efforts to ensure safer transactions, and plan to take part in those efforts. Indeed, it is our understanding that in order to meet this objective, the implementation of the exemptions proposed will be made optional for ASPSPs, as stated in rationale 46: “the draft RTS under consultation should contain a list of specific exemptions defined in chapter 2 of the draft RTS, in which PSPs are not obliged to apply strong customer authentication”. ASPSPs would then be able to apply SCA whenever they deem it necessary, from a security point of view.Following the same reasoning, we deplore the absence of an exemption based on transaction-risk analysis. The EBA’s choice not to include a risk-based exemption was made in spite of the fact that such an exemption is provided for in the directive itself, as explicitly stated in Article 98.3.a): the exemptions specified by the EBA should be based on certain criteria, among which “the level of risk involved in the service provided”.
Indeed, we are of the opinion that as long as ASPSPs remain liable for risk management and in charge of protecting the customer’s funds, they should be left free to apply their own risk analysis and therefore apply strong customer authentication if needed.
Regarding article 8. 2. d) ii, we would welcome some clarification on the cumulative amount of previous remote electronic payment transactions : is it a cumulative amount calculated on each payment instrument provided to the PSU or is it a unique cumulative amount irrespective of the payment instrument used by the PSU ?
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?
We have no objection about the list of exemptions itself, but we are adamantly opposed to any scenario in which those exemptions would be made mandatory, for several reasons.To begin with, the authentication procedures remain fully in the sphere of competence of the ASPSP, as mentioned in rationale 19. Therefore, the ASPSP should be left free to implement SCA according to its own risk analysis, including on transactions that normally meet the criteria for exemptions, in particular for fraud risk mitigation purpose.
Allowing such risk-based analyses, provided for in article 98.3.a) of the directive, and hinted at in rationale 46, seems justified for reasons of liability, since ASPSPs are considered liable for risk management.
Besides, we are extremely concerned about the risk of fraudsters exploiting the mandatory nature of exemptions to develop new fraud scenarios (such as massive attacks on low-value payments). ASPSPs would then be unable to react in a proportionate, risk-based manner.
Moreover, making exemptions mandatory would prevent some ASPSPs from complying with stricter national requirements.
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?
We globally agree with the EBA’s reasoning on the protection of the confidentiality and the integrity of the payment service users’ personalised security credentials, and with the resultant provisions proposed in chapter 3, which are coherent with state-of-the-art standards.However, regarding Article 9.1.a), we would welcome clarifications from the EBA on the elements that are included under the phrase “data on personalized security credentials”.
We are unsure about the way this paragraph should be implemented in the case of one-time passwords displayed on a smartphone screen during the authorization phase of the transaction.
We are also unsure about the applicability of Article 12.b), which requires the implementation of SCA for the association of a PSU’s identity with personalized security credentials, payment instruments or authentication devices or software. Indeed, SCA requires the PSP to associate the user with elements of knowledge, possession and/or inherence that have been linked to the client making the request; as a consequence, we fail to see how the PSP could apply SCA to a user it has not registered yet.
Yet as already mentioned in our answer to EBA’s discussion paper, we do believe that the quality of the enrolment of the PSU is of utmost importance.
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?
We globally agree with the EBA’s reasoning, however we would like to offer some remarks.Regarding 17.1, we would like to point out that “secure bilateral identification” is not possible in the case of card transactions. Current card specifications (EMV) do not provide for “bilateral identification” between cards or mobile devices and payment terminals, since the card device is unable to identify the terminal. This situation is unlikely to change in the near future, since EMV 20125 is not expected to provide for mutual authentication either.
Regarding Article 19, we approve of the obligation for ASPSPs to offer a communication interface for PISPs and AISPs. However, we suggest including into Article 19 the rational 69.a), which requires TPPs to use the communication interface that is made available to them, on a mandatory basis.
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?
We agree with the principle of using ISO 20022 elements, components or approved message definitions, if available, for communication solutions to be implemented between ASPSPs and TPPs.We would like to point out that even though ISO 20022 ATICA messages already exist for the card payment environment, they are not currently in use.
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 ?
We approve the use of Qualified certificates for website authentication. Nevertheless, we express concern about the number of qualified trust service providers that will be able to provide those certificates by the end of 2018.Question 10: With regards to the frequency with which AIS providers can request information from designated payment accounts when the payment service user is not actively requesting such information, do you agree that the proposed limit of no more than two times a day achieve an appropriate balance between allowing AISP to provide updated information to their users while not negatively impacting the availability of the ASPSP’s communication interface? If not, please indicate what would be in your view the appropriate frequency and rationale for such frequency.
Regarding article 22.5.), we agree with the proposed limit of twice a day. However, we are still concerned about the risk of denial of service, especially if there is no coordination between participants.Therefore, we propose to add to Article 19 a paragraph stating that TPPs gaining access to a communication interface must take into account the technical limitations of this interface, when the ASPSP makes them public. For instance, TPPS should avoid, whenever possible, connecting to the interface in the time windows where the risk of denial of service is at its highest. Those time windows should be displayed by the ASPSP.
We would like to point out that we cannot determine whether the information is actively requested by the PSU himself or not.