Response to consultation on RTS specifying the requirements on strong customer authentication and common and secure communication under PSD2
Go back
However please find below the following comments in order to facilitate the overall understanding of the draft articles 1-7:
- Article 1.1 refers to an ‘’authentication code’’. As there is no common understanding of what an ‘’authentication code” encompasses, whether it is a personalized token or session key or something else, we suggest ‘’authentication code’’ be replaced by ‘’authentication code features’’ to allow innovation and future oriented solutions.
- Article 1.2: Security experts understand that “information entropy” relates to the check of the truly random level of a value. To make sure this understanding is shared by the market, we suggest to be more specific and to add a definition:
Art. 1.2 ‘’ …information entropy (i.e. the check of the truly random level of a value) …’’.
- Art.1.3.(a): In general, the words “time out” are understood as being associated to “inactivity”. But a “maximum time allowed” can also be necessary, for example to defeat robots that may artificially maintain an activity which is unknown to the PSU. So, given the fact that “time out” can refer to other cases than “inactivity”, the FBF recommends to delete the words “time out” at the end of Article 1.3.(a).
- Article 1.3.d: as FBF agrees that HTTP over TLS is a minimum requirement, FBF acknowledges that this requirement may need to evolve rather quickly in the near future, depending on the creativity of fraudsters. Therefore FBF would prefer to adopt a more open wording to allow for future evolutions:
Art. 1.3.d ‘’protect communication sessions against the capture of data transmitted during the authentication procedure or manipulation by unauthorized parties, including but not limited to by relying on HTTP over TLS, or acknowledged state-of-the-art equivalent’’.
- In article 7.1, as internal auditors are not always certified, FBF recommends that EBA amends its wording by specifying that ‘’The overall security of the SCA procedure shall be periodically tested, evaluated, and audited by independent auditors, whether internal auditors, or external certified auditors’’
Art. 7.1 ‘’The overall security of the SCA procedure shall be periodically tested, evaluated, and audited by internal or external independent and certified auditors’’ should be changed into ‘‘’The overall security of the SCA procedure shall be periodically tested, evaluated, and audited by independent auditors, whether internal auditors, or external certified auditors’’
From our understanding, the RTS applies to both online interactive solution (online web banking) and file transfer solution (host to host solution such as EBICS or SWIFTnet).
In the context of file transfer, corporate solutions propose to give the confirmation of a batch payment order
- either when transmitting the file (such as EBICS TS when the corporate user personally signs the file using cryptography)
- or there is a file transfer followed by a confirmation on a web application with a dynamic linking on the base of the file principal data (such as EBICS T + web confirmation).
We would like that EBA clarifies the exact perimeter of the RTS and the inclusion (or not) of file transfer solutions.
As FBF supports EBA’s overall reasoning and proposals which are based on high level principles, FBF however regrets that EBA could not indeed take into account the risk based approach (RBA) that currently exists and has been widely adopted by the market as a best practice. The RBA allows ASPSP’s to adjust permanently the level of security to an ever evolving fraud landscape, and to deploy, depending on transaction context, adequate, relevant and effective security measures."
However article 2.2.b comes with the requirement that ‘’… the channel, device or mobile application … for displaying the amount and payee shall be independent or segregated from the channel, device or app for initiating the payment transaction.’’ This article should address the issue of logical independence of the channels used to carry out a payment operation and its authentication so as to allow both to be carried out on the same device in areas such as m-commerce and t-commerce. As a conclusion, to take into account the particularity of the mobile ecosystem, we recommend that EBA adds ‘’logically’’ in article 2.2.b as such:
Art. 2.2.b)‘’…The channel, device or mobile application through which the information linking the transaction to a specific amount and a specific payee shall be logically independent or segregated from the channel, device or app for initiating the payment transaction.’’
Moreover, from our understanding, the RTS applies to both online interactive solution (online web banking) and file transfer solution (host to host solution such as for instance EBICS or SWIFTnet).
In the context of file transfer, corporate solutions propose to give the confirmation of a batch payment order
o either when transmitting the file (such as EBICS TS when the corporate user personally signs the file using cryptography)
o or there is a file transfer followed by a confirmation on a web application with a dynamic linking on the base of the file principal data (such as EBICS T + web confirmation).
We would like that EBA clarifies the exact perimeter of the RTS and the inclusion (or not) of file transfer solutions."
We would like to point out the below elements:
- Article 3.1 mentions the ‘’use of non-repeatable characters’’ among the elements of strong customer authentication categorized as knowledge. As no standard use of non-repeatable characters exists consistently in the market, FBF recommends that EBA makes it more specific by indicating ‘’the adequate policy for the use of non-repeatable characters‘’ for clarification.
Article 3.1 shall hence state as follow : “the elements of strong customer authentication categorized as knowledge shall be characterized by security features including but not limited to 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’’.
- We agree with EBA’s view expressed in Rationale 29 on the use of behavioral data. However, we would expect a stricter wording in Article 5.1, in order to exclude the use of behavioral data as a standalone inherence element. Our main reasoning is that one should distinguish between behavioral data in general and behavioral biometrics (such as typing recognition), where the latter can very well be used as an inherence element.
While FBF supports the fact that an ASPSP should not be allowed to discriminate between activities performed through an AISP or PISP and those performed directly by the PSU, FBF would also like to stress the need for ASPSPs to be able to keep deploying their own fraud mitigation measures, such as (but not limited to) the performing of truly random SCA, to better mitigate fraud.
The exemptions criteria should hence not be an exhaustive list, so the ASPSP has also the ability to apply adequate exemptions based on its own transaction risk analysis. An exhaustive list of possible exemptions or criteria to be considered by ASPSPs for the transaction risk analysis may not be future proof enough, and may also prevent future innovations that are to be expected in this dynamic and changing environment. Moreover an exhaustive list of exemptions would tend to create a niche for fraudsters. Some French banks have for instance already been able to observe a recent increase in the fraud rate for online payments under 20 euros starting from January 2016. They could demonstrate that as soon as fraudsters identified this niche of online transactions under 20 euros for specific vendors, these fraudsters organized quickly themselves to be able to launch repeated attacks campaign in an industrial way, targeting this specific niche. As ASPSPs are facing industrialized fraud attacks (resulting in more than one million already of gross fraud), they should have the means to deploy and continuously adapt industrialized fraud mitigation measures as well.
By and large, as stated in Rationale 54, EBA does not propose exemptions based on a transaction-risk analysis performed by the ASPSP, which seems contrary to PSD2 Art. 98.3(a) which stresses that exemptions should be based on “the level of risk involved in the service provided”.
However, article 9.1.a requires personalized security credentials to be masked. While FBF supports this security measure when possible, FBF 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 which is not compliant with art. 9.1.a ’s requirement that a personalized security credential shall be masked. Moreover studies on the user experiment shows that the PSU is not yet ready to have masked data. This requirement could strongly deteriorate the user experience. Therefore we suggest EBA to either delete this article 9.1.a or define in the RTS ‘’Data on personalized security credentials’’.
Likewise art. 9.1.b. can hardly be complied with. As of today, for instance, credentials such as OTP are stored by Telcos in plain text, therefore we suggest to delete it.
In article 16.1, as internal auditors are not always certified, FBF recommends that EBA amends its wording:
Art. 16.1 : ‘’The overall security of the SCA procedure … shall be documented, periodically tested, evaluated, and audited by internal or external independent and certified auditors…’’ should be amended such as into ‘‘’The overall security of the SCA procedure shall be documented, periodically tested, evaluated, and audited by independent auditors, whether internal auditors, or external certified auditors’’
’’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”.
A TPP register will be put in place by EBA and should result from a consolidation of national databases. FBF strongly recommends that a system be set up such as to allow ASPSPs’ automated and 24/7 access to this EBA register. Only then, ASPSPs will be able to promptly address the requests received by one TPP and better address the PSU’s needs. To the benefit of the PSU, this online information should include, but is not limited to, PKI Information and contacts, for a better crisis management in case of any incident.
FBF understands the notion of ‘’secure bilateral identification’’ stated in article 17.1 as ‘’mutual authentication’’. For clarification purpose we then recommend to amend art. 17.1 by replacing ‘’ ‘’secure bilateral identification by ‘’mutual authentication’’. Furthermore, if ‘’bilateral identification’’ means ‘’mutual authentication with a certificate as with TLS (Transport Layer Security), we would like to emphasise the fact that the EMV standard used today does not provide for a payment card to authenticate a payment terminal. Furthermore, this capability is not explicitly planned in EMV 20125, which mean de facto that this particular requirement could not be met.
ISO 20022 messages would indeed have to be drafted in the market to the stated purpose. It would also have to be implemented in a coherent and harmonized way to ensure an effective interoperability.
Regarding the article 22.5.a), we would like to point out that there is currently no standardized way for the ASPSP to identify in a AISP’s request that the PSU is actually actively requesting information from designated accounts.
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?
FBF welcomes the overall reasoning on the requirements of the strong customer authentication, and the resultant provisions proposed in Chapter 1 of the draft RTS.However please find below the following comments in order to facilitate the overall understanding of the draft articles 1-7:
- Article 1.1 refers to an ‘’authentication code’’. As there is no common understanding of what an ‘’authentication code” encompasses, whether it is a personalized token or session key or something else, we suggest ‘’authentication code’’ be replaced by ‘’authentication code features’’ to allow innovation and future oriented solutions.
- Article 1.2: Security experts understand that “information entropy” relates to the check of the truly random level of a value. To make sure this understanding is shared by the market, we suggest to be more specific and to add a definition:
Art. 1.2 ‘’ …information entropy (i.e. the check of the truly random level of a value) …’’.
- Art.1.3.(a): In general, the words “time out” are understood as being associated to “inactivity”. But a “maximum time allowed” can also be necessary, for example to defeat robots that may artificially maintain an activity which is unknown to the PSU. So, given the fact that “time out” can refer to other cases than “inactivity”, the FBF recommends to delete the words “time out” at the end of Article 1.3.(a).
- Article 1.3.d: as FBF agrees that HTTP over TLS is a minimum requirement, FBF acknowledges that this requirement may need to evolve rather quickly in the near future, depending on the creativity of fraudsters. Therefore FBF would prefer to adopt a more open wording to allow for future evolutions:
Art. 1.3.d ‘’protect communication sessions against the capture of data transmitted during the authentication procedure or manipulation by unauthorized parties, including but not limited to by relying on HTTP over TLS, or acknowledged state-of-the-art equivalent’’.
- In article 7.1, as internal auditors are not always certified, FBF recommends that EBA amends its wording by specifying that ‘’The overall security of the SCA procedure shall be periodically tested, evaluated, and audited by independent auditors, whether internal auditors, or external certified auditors’’
Art. 7.1 ‘’The overall security of the SCA procedure shall be periodically tested, evaluated, and audited by internal or external independent and certified auditors’’ should be changed into ‘‘’The overall security of the SCA procedure shall be periodically tested, evaluated, and audited by independent auditors, whether internal auditors, or external certified auditors’’
From our understanding, the RTS applies to both online interactive solution (online web banking) and file transfer solution (host to host solution such as EBICS or SWIFTnet).
In the context of file transfer, corporate solutions propose to give the confirmation of a batch payment order
- either when transmitting the file (such as EBICS TS when the corporate user personally signs the file using cryptography)
- or there is a file transfer followed by a confirmation on a web application with a dynamic linking on the base of the file principal data (such as EBICS T + web confirmation).
We would like that EBA clarifies the exact perimeter of the RTS and the inclusion (or not) of file transfer solutions.
As FBF supports EBA’s overall reasoning and proposals which are based on high level principles, FBF however regrets that EBA could not indeed take into account the risk based approach (RBA) that currently exists and has been widely adopted by the market as a best practice. The RBA allows ASPSP’s to adjust permanently the level of security to an ever evolving fraud landscape, and to deploy, depending on transaction context, adequate, relevant and effective security measures."
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.
FBF agrees on EBA’s overall reasoning of article 2 to ensure that the requirements remain neutral as to when dynamic linking takes place.However article 2.2.b comes with the requirement that ‘’… the channel, device or mobile application … for displaying the amount and payee shall be independent or segregated from the channel, device or app for initiating the payment transaction.’’ This article should address the issue of logical independence of the channels used to carry out a payment operation and its authentication so as to allow both to be carried out on the same device in areas such as m-commerce and t-commerce. As a conclusion, to take into account the particularity of the mobile ecosystem, we recommend that EBA adds ‘’logically’’ in article 2.2.b as such:
Art. 2.2.b)‘’…The channel, device or mobile application through which the information linking the transaction to a specific amount and a specific payee shall be logically independent or segregated from the channel, device or app for initiating the payment transaction.’’
Moreover, from our understanding, the RTS applies to both online interactive solution (online web banking) and file transfer solution (host to host solution such as for instance EBICS or SWIFTnet).
In the context of file transfer, corporate solutions propose to give the confirmation of a batch payment order
o either when transmitting the file (such as EBICS TS when the corporate user personally signs the file using cryptography)
o or there is a file transfer followed by a confirmation on a web application with a dynamic linking on the base of the file principal data (such as EBICS T + web confirmation).
We would like that EBA clarifies the exact perimeter of the RTS and the inclusion (or not) of file transfer solutions."
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?
FBF agrees on the overall requirements stated in articles 3, 4 and 5.We would like to point out the below elements:
- Article 3.1 mentions the ‘’use of non-repeatable characters’’ among the elements of strong customer authentication categorized as knowledge. As no standard use of non-repeatable characters exists consistently in the market, FBF recommends that EBA makes it more specific by indicating ‘’the adequate policy for the use of non-repeatable characters‘’ for clarification.
Article 3.1 shall hence state as follow : “the elements of strong customer authentication categorized as knowledge shall be characterized by security features including but not limited to 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’’.
- We agree with EBA’s view expressed in Rationale 29 on the use of behavioral data. However, we would expect a stricter wording in Article 5.1, in order to exclude the use of behavioral data as a standalone inherence element. Our main reasoning is that one should distinguish between behavioral data in general and behavioral biometrics (such as typing recognition), where the latter can very well be used as an inherence element.
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?
FBF supports strongly both a more secure transaction world and innovation, likewise EBA, and therefore understands the proposed exemptions are optional for ASPSPs. As ASPSPs’ liability is entire, ASPSPs should indeed be encouraged to deploy a risk-based policy in terms of fraud mitigation, to better assess their level of risks and to manage properly their exposure. ASPSPs should be allowed to decide upon the relevant exemptions to put into place or not, depending on the results of the RBA. A limited list of exemptions may not be future proof and may also prevent future innovations (such as Internet of Things) in fraud prevention analysis that are to be expected in this dynamic and changing environment.While FBF supports the fact that an ASPSP should not be allowed to discriminate between activities performed through an AISP or PISP and those performed directly by the PSU, FBF would also like to stress the need for ASPSPs to be able to keep deploying their own fraud mitigation measures, such as (but not limited to) the performing of truly random SCA, to better mitigate fraud.
The exemptions criteria should hence not be an exhaustive list, so the ASPSP has also the ability to apply adequate exemptions based on its own transaction risk analysis. An exhaustive list of possible exemptions or criteria to be considered by ASPSPs for the transaction risk analysis may not be future proof enough, and may also prevent future innovations that are to be expected in this dynamic and changing environment. Moreover an exhaustive list of exemptions would tend to create a niche for fraudsters. Some French banks have for instance already been able to observe a recent increase in the fraud rate for online payments under 20 euros starting from January 2016. They could demonstrate that as soon as fraudsters identified this niche of online transactions under 20 euros for specific vendors, these fraudsters organized quickly themselves to be able to launch repeated attacks campaign in an industrial way, targeting this specific niche. As ASPSPs are facing industrialized fraud attacks (resulting in more than one million already of gross fraud), they should have the means to deploy and continuously adapt industrialized fraud mitigation measures as well.
By and large, as stated in Rationale 54, EBA does not propose exemptions based on a transaction-risk analysis performed by the ASPSP, which seems contrary to PSD2 Art. 98.3(a) which stresses that exemptions should be based on “the level of risk involved in the service provided”.
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?
FBF understands that the application of the exemptions is optional for ASPSPs and preventing ASPSPs to implement stronger security measures would be against PSD2. ASPSPs take risks through liabilities and may be limited by regulations towards not taking too high risks. Regulations should never refrain ASPSPs from lowering their risks, e.g. through mandating security exemptions. Such an approach would indirectly induce also drastic reactions instead of proper and proportionate risk-based reactions, should ASPSPs be confronted with new threats specifically targeting any of the exemption scenarios (e.g. massive low risk transaction fraud). Mandating exemptions could also result in unresolved situations that prevent ASPSPs to comply with other regulations (e.g. national) imposing stricter 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?
FBF overall supports the general reasoning stated in chapter 3.However, article 9.1.a requires personalized security credentials to be masked. While FBF supports this security measure when possible, FBF 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 which is not compliant with art. 9.1.a ’s requirement that a personalized security credential shall be masked. Moreover studies on the user experiment shows that the PSU is not yet ready to have masked data. This requirement could strongly deteriorate the user experience. Therefore we suggest EBA to either delete this article 9.1.a or define in the RTS ‘’Data on personalized security credentials’’.
Likewise art. 9.1.b. can hardly be complied with. As of today, for instance, credentials such as OTP are stored by Telcos in plain text, therefore we suggest to delete it.
In article 16.1, as internal auditors are not always certified, FBF recommends that EBA amends its wording:
Art. 16.1 : ‘’The overall security of the SCA procedure … shall be documented, periodically tested, evaluated, and audited by internal or external independent and certified auditors…’’ should be amended such as into ‘‘’The overall security of the SCA procedure shall be documented, periodically tested, evaluated, and audited by independent auditors, whether internal auditors, or external 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?
FBF supports EBA’s overall reasoning on the requirements stated in articles 17 to 22 and would like to suggest, for clarification purposes to ensure a harmonized implementation throughout Europe, to include part of rationale 69.a (page 20) into article 17:’’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”.
A TPP register will be put in place by EBA and should result from a consolidation of national databases. FBF strongly recommends that a system be set up such as to allow ASPSPs’ automated and 24/7 access to this EBA register. Only then, ASPSPs will be able to promptly address the requests received by one TPP and better address the PSU’s needs. To the benefit of the PSU, this online information should include, but is not limited to, PKI Information and contacts, for a better crisis management in case of any incident.
FBF understands the notion of ‘’secure bilateral identification’’ stated in article 17.1 as ‘’mutual authentication’’. For clarification purpose we then recommend to amend art. 17.1 by replacing ‘’ ‘’secure bilateral identification by ‘’mutual authentication’’. Furthermore, if ‘’bilateral identification’’ means ‘’mutual authentication with a certificate as with TLS (Transport Layer Security), we would like to emphasise the fact that the EMV standard used today does not provide for a payment card to authenticate a payment terminal. Furthermore, this capability is not explicitly planned in EMV 20125, which mean de facto that this particular requirement could not be met.
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?
FBF recognises the use of ISO 20022 elements as a rational tool allowing interoperability, if available and implemented in a harmonized way.ISO 20022 messages would indeed have to be drafted in the market to the stated purpose. It would also have to be implemented in a coherent and harmonized way to ensure an effective interoperability.
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 ?
FBF supports the approach of EBA regarding website certificates issued by a qualify TSP under an e-IDAS policy.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.
FBF supports EBA’s reasoning on the requirements stated in article 22.Regarding the article 22.5.a), we would like to point out that there is currently no standardized way for the ASPSP to identify in a AISP’s request that the PSU is actually actively requesting information from designated accounts.