Response to consultation on RTS specifying the requirements on strong customer authentication and common and secure communication under PSD2
Go back
SG supports the EBA high principles based approach which ensures technology and business model neutrality.
However, to facilitate the overall understanding, SG would like to suggest some clarifications of the RTS draft wording.
• Article 1.1 refers to an ‘’authentication code’’. SG does not understand what an ‘’authentication code” encompasses, whether it is a personalized token or a session key or something else.
SG proposes the following wording:
Article 1.1 “For the purposes of the application of strong customer authentication in accordance with Article 97(1) of Directive (EU) 2015/2366, the authentication procedure shall result in the generation of an authentication FEATURE (…)
• Article 1.3. (d): As SG agrees that HTTP over TLS is a minimum requirement, SG acknowledges that this requirement may need to evolve rather quickly in the near future, depending on the creativity of fraudsters. SG would prefer the following wording:
Article 1.4 (d): protect communication sessions against the capture of data transmitted during the authentication procedure or manipulation by unauthorised parties, including but not limited to by relying where applicable on HTTP over TLS OR EQUIVALENT.
• Article 6.3. In relation to the mitigating measures concerning the independence of the elements, SG considers that it is better to list some examples that may be used, instead of the mechanism that shall be used. SG proposes the following wording:
Article 6.3:a: “For the purposes of paragraph 2, the mitigating measures MAY include, but are not limited to…..”
• Article 7.1 refers to “internal and external independent and certified auditors”. In some countries, auditors are independent but not certified. SG recommends the following wording:
Article. 7.1: “The overall security of the SCA procedure shall be periodically tested, evaluated, and audited by internal or external independent and OR certified auditors”
However, SG would like to be sure that the requirement of the article 2.2b does not prevent the use of mobile phone. Indeed, there is no means to ensure that the environments are segregated in a mobile phone.
SG does not believe that EBA has the intention to prohibit the current form of mobile banking apps as implemented by many European banks and broadly used by their customers.
SG would therefore suggest the EBA to use the following wording:
Article 2.2.b) ‘’…The channel, or mobile application through which the information linking the transaction to a specific amount and a specific payee shall LOGICALLY be independent or segregated from the channel, or app for initiating the payment transaction.’’
However, SG would like to stress the importance of the enrolment process of the user’s devices. A prior enrolment of the user’s devices shall be processed and the quality of this enrolment is key to give to the banks the capability to link securely and efficiently the elements.
SG security experts expressed the following considerations:
- Article 3 (element categorized as knowledge): An element of strong customer authentification categorized as knowledge should not have “an expiration time”, as the knowledge of a client does not change over the months.
In practice, the technology of non repeatable characters is sometimes replaced by token.
SG would therefore recommend the following wording:
Article 3.1: “The elements of strong customer authentication categorised as knowledge MAY be characterized by security features including, but not limited to, length, COMPLEXITY, AND the use of non-repeatable characters ensuring resistance against the risk of the elements being uncovered or disclosed to unauthorised parties. “
- Article 4 (element categorized as possession): When possible, SG is in favor of anti-cloning features requirement. However, the anti-cloning features requirement is not always in line with existing security practices that are widely used in France, such as SMS.
SG would therefore propose to modify the drafting of the RTS as following:
Article 4.2 ‘’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’’.
- Article 5 (element categorized as inherence): SG security experts draw attention on the word “sensor” in the expression ‘’biometric sensor. The word “sensor’ could limit biometric innovation in the future. They suggest to delete it as following:
Article 5.1: Devices and software provided to the payer in order to read authentication elements categorized as inherence MAY be characterized by security features including, but not limited to, algorithm specifications, BIOMETRY and template protection features ensuring resistance against the risk of sensitive information related to the elements being disclosed to unauthorised parties.
• Objective and non discriminatory risk criteria should be accepted by EBA as:
- Consumer device level
- Connection level (direct / indirect, IP-address, IP GeoLocation, ISP, etc.)
- Application level (language of the application, etc.)
- Payer level (profiling, user interaction profiling, etc.)
- Transactional level (history, beneficiary account, amount, country, urgent/non-urgent payment, etc.)
- Payee or beneficiary level (profiling)
- Big data (data related to fraud / threat environment, customer claims).
• A detailed list of exemptions would immediately become the target of fraudsters and organised crime.
• Moreover, SG believes that non exemption to the strong authentification for the first connection of a client would strongly deteriorate the client experience, without increasing the security as KYC and procedures related to the opening of a bank account already allow a very high level of confidence.
SG therefore proposes the following modifications:
Article 8 (Exemptions to strong customer authentication)
1. The application of strong customer authentication in accordance with Article 97(1) of Directive (EU) 2015/ 2366 is exempted where:
(a) the payer accesses exclusively the information of its payment account online, or the consolidated information on other payment accounts held, without disclosure of sensitive payment data.
The application of strong customer authentication shall not be exempted where:
i: DELETE
ii. the payer accesses the information of its payment account online, or the consolidated information on other payment accounts held, later
Preventing the implementation of stronger security would be against PSD2. None of the PSD provisions forbids applying SCA when criteria of exemption are met. On the contrary, recital 91 asserts that “Payment service providers are responsible for security measures”. Mandatory character of exemptions would not be compatible with liability mechanisms as ASPSP have to bear losses.
• SG considers that PSP must be in position to manage their risks in an appropriate way. Regulations should never refrain ASPSPs from managing the level of their risk controls, e.g. through mandating security exemptions, if the risks are managed on a non discriminatory and objective basis.
Such a regulator’s prescriptive approach would indirectly induce drastic reactions, as the ASPSPs would be confronted with new threats specifically targeting any of the exemption scenarios.
SG sees a risk that the average level of security of payment systems is lowered, because specific situations of an exemption case would currently require application of SCA, which would not allowed anymore with these draft RTS.
For example, there could be a risk in transactions done between two accounts of the same legal person, if such a transaction is immediately followed by a number of transactions to some other account, since this pattern has been used by fraudsters in the past.
In general, the payment transactions for which the exemptions have to be applied will attract fraudsters because they can be quite sure that no further authentication will be required, once they are successful in initiating such a transaction – that is probably signaled as suspicious by the ASPSP but nothing can be done against it, other than to block the transaction, i.e. lowering the service level, which is not a desirable outcome.
However, SG would have some suggestions concerning the wording of the draft RTS.
Indeed, article 9.1.a (readings of the data on credentials) requires personalized security credentials to be masked. While SG supports this security measures when possible, SG notices that, in some cases, personalized security credential cannot be masked. For instance, for online transactions, the ASPSP’s security policy may at a point of time trigger the sending of an authentication code to the PSU, which the PSU has to key in. As the PSU has to read it, this code cannot be masked.
Moreover studies on the user experiment show that the PSU is not ready to have all masked data.
SG suggests amending the draft RTS in the following way:
Article 9 (requirements for security measures)
1. The confidentiality and integrity of personalised security credentials of the payment service user shall be ensured during all phases of the authentication procedure including display, transmission and storage. To that end, the security measures to protect the confidentiality and integrity of payment service users’ personalised security credentials shall provide that:
(a) SOME data on personalised security credentials are masked when displayed and not readable in their full extent.
• Concerning article 9.1.b (storage of the credentials), credentials such as OTP are today stored by Telcos in plain text.
SG suggests amending the draft RTS in the following way:
Article 9 (requirements for security measures)
1. The confidentiality and integrity of personalised security credentials of the payment service user shall be ensured during all phases of the authentication procedure including display, transmission and storage. To that end, the security measures to protect the confidentiality and integrity of payment service users’ personalised security credentials shall provide that:
(b) Personalised security credentials data as well as cryptographic material related to the encryption of the personalised security credentials are, WHEN TECHNICALLY POSSIBLE, not stored in plain text.
• In article 16 (review of the security measures to protect the credentials), the EBA states that the internal auditors need to be independent and certified. In France, internal auditors are independent but not certified.
SG recommends that EBA amends its wording in the following way:
Article 16.1 : ‘The overall security of measures to protect the confidentiality and integrity of payment service users’ personalised security credentials, as referred to in articles 9 to 15, shall be documented, periodically tested, evaluated and audited by internal or external independent OR certified auditors.
To ensure a harmonized implementation throughout Europe, SG is in favor of the inclusion in the article 17 (requirements for identification) of the EBA rationale 69a (page 20) which precise: ’’AISPs, PISPs and PSPs issuing card-based payment instruments shall use this communication interface for payment initiation or any exchange of information related to the access to payment accounts under the conditions as referred to in articles 65, 66, and 67 of PSD2”.
In the future, TPPs will have to be registered in the EBA register, resulting from a consolidation of national databases. SG strongly recommends that a system be set up to allow ASPSPs’ automated and 24/7 access to this TPP database. ASPSP will then be able to promptly address the requests received by one TPP. This online information should include but is not limited to PKI Information and contacts in case of any incident.
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.
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?
• SG welcomes the EBA provisions which states that the authentification procedure will remain fully in the sphere of the competence of the ASPSP.SG supports the EBA high principles based approach which ensures technology and business model neutrality.
However, to facilitate the overall understanding, SG would like to suggest some clarifications of the RTS draft wording.
• Article 1.1 refers to an ‘’authentication code’’. SG does not understand what an ‘’authentication code” encompasses, whether it is a personalized token or a session key or something else.
SG proposes the following wording:
Article 1.1 “For the purposes of the application of strong customer authentication in accordance with Article 97(1) of Directive (EU) 2015/2366, the authentication procedure shall result in the generation of an authentication FEATURE (…)
• Article 1.3. (d): As SG agrees that HTTP over TLS is a minimum requirement, SG acknowledges that this requirement may need to evolve rather quickly in the near future, depending on the creativity of fraudsters. SG would prefer the following wording:
Article 1.4 (d): protect communication sessions against the capture of data transmitted during the authentication procedure or manipulation by unauthorised parties, including but not limited to by relying where applicable on HTTP over TLS OR EQUIVALENT.
• Article 6.3. In relation to the mitigating measures concerning the independence of the elements, SG considers that it is better to list some examples that may be used, instead of the mechanism that shall be used. SG proposes the following wording:
Article 6.3:a: “For the purposes of paragraph 2, the mitigating measures MAY include, but are not limited to…..”
• Article 7.1 refers to “internal and external independent and certified auditors”. In some countries, auditors are independent but not certified. SG recommends the following wording:
Article. 7.1: “The overall security of the SCA procedure shall be periodically tested, evaluated, and audited by internal or external independent and OR certified auditors”
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.
SG agrees on the EBA’s overall reasoning of article 2 to ensure that the requirements remain neutral as to when “dynamic linking” takes place.However, SG would like to be sure that the requirement of the article 2.2b does not prevent the use of mobile phone. Indeed, there is no means to ensure that the environments are segregated in a mobile phone.
SG does not believe that EBA has the intention to prohibit the current form of mobile banking apps as implemented by many European banks and broadly used by their customers.
SG would therefore suggest the EBA to use the following wording:
Article 2.2.b) ‘’…The channel, or mobile application through which the information linking the transaction to a specific amount and a specific payee shall LOGICALLY be independent or segregated from the channel, or app for initiating the payment transaction.’’
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?
• SG is not aware of other threats that the ones identified in articles 3, 4 and 5 of the draft RTS.However, SG would like to stress the importance of the enrolment process of the user’s devices. A prior enrolment of the user’s devices shall be processed and the quality of this enrolment is key to give to the banks the capability to link securely and efficiently the elements.
SG security experts expressed the following considerations:
- Article 3 (element categorized as knowledge): An element of strong customer authentification categorized as knowledge should not have “an expiration time”, as the knowledge of a client does not change over the months.
In practice, the technology of non repeatable characters is sometimes replaced by token.
SG would therefore recommend the following wording:
Article 3.1: “The elements of strong customer authentication categorised as knowledge MAY be characterized by security features including, but not limited to, length, COMPLEXITY, AND the use of non-repeatable characters ensuring resistance against the risk of the elements being uncovered or disclosed to unauthorised parties. “
- Article 4 (element categorized as possession): When possible, SG is in favor of anti-cloning features requirement. However, the anti-cloning features requirement is not always in line with existing security practices that are widely used in France, such as SMS.
SG would therefore propose to modify the drafting of the RTS as following:
Article 4.2 ‘’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’’.
- Article 5 (element categorized as inherence): SG security experts draw attention on the word “sensor” in the expression ‘’biometric sensor. The word “sensor’ could limit biometric innovation in the future. They suggest to delete it as following:
Article 5.1: Devices and software provided to the payer in order to read authentication elements categorized as inherence MAY be characterized by security features including, but not limited to, algorithm specifications, BIOMETRY and template protection features ensuring resistance against the risk of sensitive information related to the elements being disclosed to unauthorised parties.
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?
• SG is of the opinion that EBA does not fulfil its mandate with regard to PSD2 Art. 98.3(a): (exemptions based on “the level of risk involved in the service provided”), since the exemptions in the current draft RTS do not allow for a risk-based assessment.• Objective and non discriminatory risk criteria should be accepted by EBA as:
- Consumer device level
- Connection level (direct / indirect, IP-address, IP GeoLocation, ISP, etc.)
- Application level (language of the application, etc.)
- Payer level (profiling, user interaction profiling, etc.)
- Transactional level (history, beneficiary account, amount, country, urgent/non-urgent payment, etc.)
- Payee or beneficiary level (profiling)
- Big data (data related to fraud / threat environment, customer claims).
• A detailed list of exemptions would immediately become the target of fraudsters and organised crime.
• Moreover, SG believes that non exemption to the strong authentification for the first connection of a client would strongly deteriorate the client experience, without increasing the security as KYC and procedures related to the opening of a bank account already allow a very high level of confidence.
SG therefore proposes the following modifications:
Article 8 (Exemptions to strong customer authentication)
1. The application of strong customer authentication in accordance with Article 97(1) of Directive (EU) 2015/ 2366 is exempted where:
(a) the payer accesses exclusively the information of its payment account online, or the consolidated information on other payment accounts held, without disclosure of sensitive payment data.
The application of strong customer authentication shall not be exempted where:
i: DELETE
ii. the payer accesses the information of its payment account online, or the consolidated information on other payment accounts held, later
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?
• SG is of the opinion that PSPs cannot be prevented from implementing SCA in transactions that meet the criteria for exemption.Preventing the implementation of stronger security would be against PSD2. None of the PSD provisions forbids applying SCA when criteria of exemption are met. On the contrary, recital 91 asserts that “Payment service providers are responsible for security measures”. Mandatory character of exemptions would not be compatible with liability mechanisms as ASPSP have to bear losses.
• SG considers that PSP must be in position to manage their risks in an appropriate way. Regulations should never refrain ASPSPs from managing the level of their risk controls, e.g. through mandating security exemptions, if the risks are managed on a non discriminatory and objective basis.
Such a regulator’s prescriptive approach would indirectly induce drastic reactions, as the ASPSPs would be confronted with new threats specifically targeting any of the exemption scenarios.
SG sees a risk that the average level of security of payment systems is lowered, because specific situations of an exemption case would currently require application of SCA, which would not allowed anymore with these draft RTS.
For example, there could be a risk in transactions done between two accounts of the same legal person, if such a transaction is immediately followed by a number of transactions to some other account, since this pattern has been used by fraudsters in the past.
In general, the payment transactions for which the exemptions have to be applied will attract fraudsters because they can be quite sure that no further authentication will be required, once they are successful in initiating such a transaction – that is probably signaled as suspicious by the ASPSP but nothing can be done against it, other than to block the transaction, i.e. lowering the service level, which is not a desirable outcome.
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?
• SG agrees with the EBA’s reasoning on the protection of the confidentiality and the integrity of the payment service users’ personalised security credentials.However, SG would have some suggestions concerning the wording of the draft RTS.
Indeed, article 9.1.a (readings of the data on credentials) requires personalized security credentials to be masked. While SG supports this security measures when possible, SG notices that, in some cases, personalized security credential cannot be masked. For instance, for online transactions, the ASPSP’s security policy may at a point of time trigger the sending of an authentication code to the PSU, which the PSU has to key in. As the PSU has to read it, this code cannot be masked.
Moreover studies on the user experiment show that the PSU is not ready to have all masked data.
SG suggests amending the draft RTS in the following way:
Article 9 (requirements for security measures)
1. The confidentiality and integrity of personalised security credentials of the payment service user shall be ensured during all phases of the authentication procedure including display, transmission and storage. To that end, the security measures to protect the confidentiality and integrity of payment service users’ personalised security credentials shall provide that:
(a) SOME data on personalised security credentials are masked when displayed and not readable in their full extent.
• Concerning article 9.1.b (storage of the credentials), credentials such as OTP are today stored by Telcos in plain text.
SG suggests amending the draft RTS in the following way:
Article 9 (requirements for security measures)
1. The confidentiality and integrity of personalised security credentials of the payment service user shall be ensured during all phases of the authentication procedure including display, transmission and storage. To that end, the security measures to protect the confidentiality and integrity of payment service users’ personalised security credentials shall provide that:
(b) Personalised security credentials data as well as cryptographic material related to the encryption of the personalised security credentials are, WHEN TECHNICALLY POSSIBLE, not stored in plain text.
• In article 16 (review of the security measures to protect the credentials), the EBA states that the internal auditors need to be independent and certified. In France, internal auditors are independent but not certified.
SG recommends that EBA amends its wording in the following way:
Article 16.1 : ‘The overall security of measures to protect the confidentiality and integrity of payment service users’ personalised security credentials, as referred to in articles 9 to 15, shall be documented, periodically tested, evaluated and audited by internal or external independent OR certified auditors.
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?
• SG supports EBA’s overall reasoning on the requirements related to Chapter 4 (”common and secure open standards of communication”).To ensure a harmonized implementation throughout Europe, SG is in favor of the inclusion in the article 17 (requirements for identification) of the EBA rationale 69a (page 20) which precise: ’’AISPs, PISPs and PSPs issuing card-based payment instruments shall use this communication interface for payment initiation or any exchange of information related to the access to payment accounts under the conditions as referred to in articles 65, 66, and 67 of PSD2”.
In the future, TPPs will have to be registered in the EBA register, resulting from a consolidation of national databases. SG strongly recommends that a system be set up to allow ASPSPs’ automated and 24/7 access to this TPP database. ASPSP will then be able to promptly address the requests received by one TPP. This online information should include but is not limited to PKI Information and contacts in case of any incident.
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?
• SG does not see a technical constraint that would prevent the use of ISO 20022 for the communication between TPPs and the ASPSP, but harmonised messages would need to be developed at European level.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 ?
• SG 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 common types of devices for carrying out different payment servicesQuestion 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.
• SG agrees with the frequency with which AIS providers can request information from designated payment accounts when the payment service user is not actively requesting such information.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.