Response to consultation on RTS specifying the requirements on strong customer authentication and common and secure communication under PSD2
Go back
Re Authentication procedure and authentication code
Article 1(3) implies that user ID/password and One Time Password (OTP) must be entered in one process. If access is not granted there will be no clue to which of the authentications factors there is wrong. In our view Article 1(3), therefore, prevents the use of existing, widespread, and secure authentication procedures in the Nordics. In the Nordics the vast majority of authentications take place as a two-factor authentication procedure started by the PSUs entering his or her user ID and password followed by an OTP (or OTP followed by a password), for example in the form of a challenge response mechanism. Therefore, Article 1(3) will affect nearly all of the existing two-factor solutions available in the Nordics today. We suggest that the RTS is amended to allow for such current and well-functioning solutions that are in line with the overall objectives of the PSD2 and the RTS.
Re Strong customer authentication procedure with dynamic linking
Further, we call for the EBA to provide clarity regarding the last sentences of Article 2(2) (b): 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. This sentence implies in our view that a mobile banking app may not be able to use a security Software Development Kit (SDK) integrated into the banking app as the security function providing the Dynamic Linking capability is in the banking app. Article 2(2) (b) can be interpreted as the SDK is not segregated or independent from the banking app in which the amount and payee information are displayed to the PSU. If this is the case, it will cause a number of problems for implementation with banks as they commonly integrate SDKs from various security vendors. We suggest that the RTS is amended to allow for the use of SDKs as components that are “independent or segregated from the… mobile application” in order to ensure that we do not set unnecessary obstacles for the emergence of m-commerce, specifically payments initiated through mobile wallets.
Re Requirements related to elements categorised as possession
Also, Article 4(2) specifies the requirements for the possession elements and by the wording it seems that the subject of interest is a program or an app in which case we agree that the requirement is relevant. However, the Article will exclude existing, well-functioning, and widespread physical independent code cards which the PSUs carry with them in their wallets. The physical code card is very secure and user-friendly (easy to use, understand and carry along – also for people who do not possess smartphones or other technical devices). In Denmark a code card constitutes the second factor possession element which is distributed and used regularly by 4.5 million Danes when they, inter alia, sign transactions in their online banking solution and log-on to public authorities to benefit of the digital transformation. Existing well-functioning solutions, such as the external and independent physical code cards used in Denmark, which do not entail a larger security risk than possession devices implemented as apps which cannot be copied/cloned (such as code generators), should not be prevented as this would jeopardize the use of such existing and secure solutions and would be disproportional in terms of achieving the objectives of the RTS. To reduce the use of an existing and secure solution will hamper digitization in general.
Re Requirements related to the independence of the elements
We ask the EBA to provide clarity on its interpretation of Article 6(3) and whether a “trusted execution environment” should be viewed as a Trusted Execution Environment (TEE) as defined by GlobalPlatform (see http://www.globalplatform.org/mediaguidetee.asp). If this is the case it would greatly limit the use of “general available multi-purpose devices” such as mobile phones and tablets from being used as very few smart phones available today provides genuine TEE. A suggestion could be to require that the Token Secret, which constitutes the real possession element, should be protected in an environment which prevents malicious programs to get hold or use the Token Secret.
Rationale 17 defines transactions initiated by payees (i.a. merchants) not to be regarded as “electronic payment transactions” under PSD2 Article 97(1) (b), however, Rationale 18 provides that if the payer’s consent for a direct debit transaction is given in the form of an electronic mandate it will fall under Article 97(1) (c).
We ask that the EBA specifies that mandates provided by PSUs prior to the PSD2 and RTS taking effect will not require a new consent by SCA and, accordingly, that such pre-issued mandates will remain valid. If all existing electronic mandates were to require a new consent it would have severe consequences for both payees and payers, and be very costly and cumbersome.
With respect to other payment services initiated by the payee according to an agreement with the payer, such as recurrent card based payments, the SCA requirements under the RTS will in reality mean that all such payee initiated transactions require SCA prior to initiation. This would significantly and adversely affect the user experience in payee initiated card based payment services which are, inter alia, used for paying recurrent bills, such as payment for consumption of water and electricity, telephone bills, internet bills, television bills, etc., and which currently do not require authentication in connection with each transaction as the strong customer authentication is done at the time of service subscription.
We encourage EBA RTS to adopt a more flexible approach to payment services initiated by the payee according to an agreement with the payer so that payee initiated transactions do not require SCA in connection with each transaction. This is crucial for such products to work and will not entail an increased risk of fraud. For instance, data from the Danish payment card scheme, the Dankort, shows that fraud in relation to recurrent card based payments is subject to approximately ten times less fraud than remote electronic payments in general.
A suggested approach could be that the RTS exempts the payees of the requirements of SCA if, in due time (e.g. 5-7 days) prior to charging the payer, they inform the payer and ASPSP of the upcoming recurring payment.
Re application of exemptions
According to the Rationale, 41, exemptions to SCA can be applied by ASPSPs only. In our view, this conflict with the objectives for the RTS provided by the PSD2 and mentioned under 3(c) and 3(d).
When PSUs and merchants enter into agreements, the merchants may know the PSUs better than the ASPSPs, especially when it comes to their loyal customers, however, with the rationale of the RTS only the ASPSPs - and not the acquiring PSPs that have the contractual relationship with the merchants - will be able to apply an exemption.
This does not lead to “fair competition among all PSPs” in accordance with the objectives under 3 (c), as ASPSPs/issuers may also be performing acquiring services in competition with the acquiring PSPs who are not ASPSPs/issuers and, therefore, not able to benefit from the exemptions. On the contrary, it may have a negative impact on competition among acquirers as it is likely to entail barriers to effective competition based on the SCA models implemented by the ASPSPs.
Further, it will not allow for “technology and business model neutrality” under 3 (d) if only ASPSPs will be able to benefit from the exemptions, as it will directly impose restrictions on acquiring PSPs business model, which is to price acceptance services based on optimization of risk – not only for intra-European transactions but also for inter-European transactions.
By moving all exemption rights and liability to ASPSPs, the balance between ASPSPs/issuers that are also performing acquiring services and acquirers who are not issuers shifts to the detriment of the latter. A suggestion to solve this issue could be to require that the ASPSPs should inform the acquiring PSPs of the SCA elements available to the acquiring PSPs and then the acquiring PSP would have an opportunity to match or exceed these elements with a view to gain liability shift.
Re Maximum amounts
Article 8(2) (d) specifies that the individual amount of a remote electronic payment transaction initiated by the payer is exempted from the requirement of SCA when it does not exceed the maximum amount of €10 and the cumulative maximum amount of €100. As the price level in the Nordics is high compared to the rest of the EU, a maximum amount of €10 per remote electronic payment transaction would in reality entail that all such transactions will require strong customer authentication negatively affecting the user experience when purchasing online.
Furthermore, the level of fraud currently registered in online payments is concentrated around much higher amount levels than €10 e.g. in Denmark 93 % of all fraud is on transactions above €67. As a consequence of this, the Danish FSA exempted transactions below €60 from the requirement of strong customer authentication when EBA’s Guidelines on the security of internet payments was implemented in Denmark.
Consequently, it is recommended that the maximum amount of €10 is replaced with a maximum amount of €60 and a cumulative maximum amount of €100 is replaced with a cumulative maximum of €180.
Furthermore, we urge that EBA consider exempting unattended payment environments for the requirements of SCA in relation to contact based transactions. If the application of SCA at such environments is required it would entail significant obstacles for PSUs such as paying at toll ways (bridges and highways) in their daily commute and when travelling abroad.
In the Rationale, 19(b), it is provided, that the EBA is of the understanding that PSD2 Article 74(2) will only apply during the transitional period between the application date of the PSD2 and the application date of the RTS under consultation.
First of all, it should be noted that the PSD2 does not provide that Article 74(2) will only apply for a transitional period of time.
Second of all, in case Article 74(2) will not apply after the application date of the RTS, this does not create a level-playing field as issuers who are also providing acquiring services will have a competitive advantage compared to acquirers who are not also acting as issuers. Acquirers have agreements with merchants, not issuers, but the acquirers are left without a say if they are not able to take on liability towards the merchants and, thus, the (non-issuer) acquiring PSP – merchant (payee) relationship will be negatively affected.
Third of all, it should be noted that if liability is placed solely on the issuers, the acquirers and the payees will be less likely to protect the PSUs from man-in-the-middle attacks, etc. Placing all liability with the ASPSPs would only make sense in a world with no fraud, however, neither the EBA nor the issuers can be guaranteed against fraud. Instead, both ASPSPs and acquiring PSPs should have an incentive to secure the optimal balance between risk of fraud and convenience which could be achieved with the continued application of Article 74 (2) after the RTS enter into force.
In addition to keeping Article 74 (2), we suggest a model where the ASPSPs make the SCA elements available to the acquiring PSPs and, on that basis, the acquiring PSPs would have the opportunity to match or exceed these elements with a view to gain liability shift.
Re “Usage” of Personalised Security Credentials
In relation to RTS Articles 11, 12, 13, 14 and 15, they seem to comprise the protection of the PSC entire lifecycle. However, clauses for the usage of PSC are missing. The RTS should provide for security requirements related to the PSU’s general daily usage of the PSC, as confidentiality of the PSC in all stages of the life time is essential for the security of the entire solution. Omitting security requirements for the usage phase of the PSC could lead to serious security flaws.
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?
Nets agrees with EBA that the RTS should be developed at a higher rather than granular level to ensure continuous adaptation to counter evolving fraud scenarios. However, we ask that the EBA take the following into consideration:Re Authentication procedure and authentication code
Article 1(3) implies that user ID/password and One Time Password (OTP) must be entered in one process. If access is not granted there will be no clue to which of the authentications factors there is wrong. In our view Article 1(3), therefore, prevents the use of existing, widespread, and secure authentication procedures in the Nordics. In the Nordics the vast majority of authentications take place as a two-factor authentication procedure started by the PSUs entering his or her user ID and password followed by an OTP (or OTP followed by a password), for example in the form of a challenge response mechanism. Therefore, Article 1(3) will affect nearly all of the existing two-factor solutions available in the Nordics today. We suggest that the RTS is amended to allow for such current and well-functioning solutions that are in line with the overall objectives of the PSD2 and the RTS.
Re Strong customer authentication procedure with dynamic linking
Further, we call for the EBA to provide clarity regarding the last sentences of Article 2(2) (b): 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. This sentence implies in our view that a mobile banking app may not be able to use a security Software Development Kit (SDK) integrated into the banking app as the security function providing the Dynamic Linking capability is in the banking app. Article 2(2) (b) can be interpreted as the SDK is not segregated or independent from the banking app in which the amount and payee information are displayed to the PSU. If this is the case, it will cause a number of problems for implementation with banks as they commonly integrate SDKs from various security vendors. We suggest that the RTS is amended to allow for the use of SDKs as components that are “independent or segregated from the… mobile application” in order to ensure that we do not set unnecessary obstacles for the emergence of m-commerce, specifically payments initiated through mobile wallets.
Re Requirements related to elements categorised as possession
Also, Article 4(2) specifies the requirements for the possession elements and by the wording it seems that the subject of interest is a program or an app in which case we agree that the requirement is relevant. However, the Article will exclude existing, well-functioning, and widespread physical independent code cards which the PSUs carry with them in their wallets. The physical code card is very secure and user-friendly (easy to use, understand and carry along – also for people who do not possess smartphones or other technical devices). In Denmark a code card constitutes the second factor possession element which is distributed and used regularly by 4.5 million Danes when they, inter alia, sign transactions in their online banking solution and log-on to public authorities to benefit of the digital transformation. Existing well-functioning solutions, such as the external and independent physical code cards used in Denmark, which do not entail a larger security risk than possession devices implemented as apps which cannot be copied/cloned (such as code generators), should not be prevented as this would jeopardize the use of such existing and secure solutions and would be disproportional in terms of achieving the objectives of the RTS. To reduce the use of an existing and secure solution will hamper digitization in general.
Re Requirements related to the independence of the elements
We ask the EBA to provide clarity on its interpretation of Article 6(3) and whether a “trusted execution environment” should be viewed as a Trusted Execution Environment (TEE) as defined by GlobalPlatform (see http://www.globalplatform.org/mediaguidetee.asp). If this is the case it would greatly limit the use of “general available multi-purpose devices” such as mobile phones and tablets from being used as very few smart phones available today provides genuine TEE. A suggestion could be to require that the Token Secret, which constitutes the real possession element, should be protected in an environment which prevents malicious programs to get hold or use the Token Secret.
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.
No comments.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?
No comments.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?
Re Direct debits and other payment services initiated by the payee according to an agreement with the payerRationale 17 defines transactions initiated by payees (i.a. merchants) not to be regarded as “electronic payment transactions” under PSD2 Article 97(1) (b), however, Rationale 18 provides that if the payer’s consent for a direct debit transaction is given in the form of an electronic mandate it will fall under Article 97(1) (c).
We ask that the EBA specifies that mandates provided by PSUs prior to the PSD2 and RTS taking effect will not require a new consent by SCA and, accordingly, that such pre-issued mandates will remain valid. If all existing electronic mandates were to require a new consent it would have severe consequences for both payees and payers, and be very costly and cumbersome.
With respect to other payment services initiated by the payee according to an agreement with the payer, such as recurrent card based payments, the SCA requirements under the RTS will in reality mean that all such payee initiated transactions require SCA prior to initiation. This would significantly and adversely affect the user experience in payee initiated card based payment services which are, inter alia, used for paying recurrent bills, such as payment for consumption of water and electricity, telephone bills, internet bills, television bills, etc., and which currently do not require authentication in connection with each transaction as the strong customer authentication is done at the time of service subscription.
We encourage EBA RTS to adopt a more flexible approach to payment services initiated by the payee according to an agreement with the payer so that payee initiated transactions do not require SCA in connection with each transaction. This is crucial for such products to work and will not entail an increased risk of fraud. For instance, data from the Danish payment card scheme, the Dankort, shows that fraud in relation to recurrent card based payments is subject to approximately ten times less fraud than remote electronic payments in general.
A suggested approach could be that the RTS exempts the payees of the requirements of SCA if, in due time (e.g. 5-7 days) prior to charging the payer, they inform the payer and ASPSP of the upcoming recurring payment.
Re application of exemptions
According to the Rationale, 41, exemptions to SCA can be applied by ASPSPs only. In our view, this conflict with the objectives for the RTS provided by the PSD2 and mentioned under 3(c) and 3(d).
When PSUs and merchants enter into agreements, the merchants may know the PSUs better than the ASPSPs, especially when it comes to their loyal customers, however, with the rationale of the RTS only the ASPSPs - and not the acquiring PSPs that have the contractual relationship with the merchants - will be able to apply an exemption.
This does not lead to “fair competition among all PSPs” in accordance with the objectives under 3 (c), as ASPSPs/issuers may also be performing acquiring services in competition with the acquiring PSPs who are not ASPSPs/issuers and, therefore, not able to benefit from the exemptions. On the contrary, it may have a negative impact on competition among acquirers as it is likely to entail barriers to effective competition based on the SCA models implemented by the ASPSPs.
Further, it will not allow for “technology and business model neutrality” under 3 (d) if only ASPSPs will be able to benefit from the exemptions, as it will directly impose restrictions on acquiring PSPs business model, which is to price acceptance services based on optimization of risk – not only for intra-European transactions but also for inter-European transactions.
By moving all exemption rights and liability to ASPSPs, the balance between ASPSPs/issuers that are also performing acquiring services and acquirers who are not issuers shifts to the detriment of the latter. A suggestion to solve this issue could be to require that the ASPSPs should inform the acquiring PSPs of the SCA elements available to the acquiring PSPs and then the acquiring PSP would have an opportunity to match or exceed these elements with a view to gain liability shift.
Re Maximum amounts
Article 8(2) (d) specifies that the individual amount of a remote electronic payment transaction initiated by the payer is exempted from the requirement of SCA when it does not exceed the maximum amount of €10 and the cumulative maximum amount of €100. As the price level in the Nordics is high compared to the rest of the EU, a maximum amount of €10 per remote electronic payment transaction would in reality entail that all such transactions will require strong customer authentication negatively affecting the user experience when purchasing online.
Furthermore, the level of fraud currently registered in online payments is concentrated around much higher amount levels than €10 e.g. in Denmark 93 % of all fraud is on transactions above €67. As a consequence of this, the Danish FSA exempted transactions below €60 from the requirement of strong customer authentication when EBA’s Guidelines on the security of internet payments was implemented in Denmark.
Consequently, it is recommended that the maximum amount of €10 is replaced with a maximum amount of €60 and a cumulative maximum amount of €100 is replaced with a cumulative maximum of €180.
Furthermore, we urge that EBA consider exempting unattended payment environments for the requirements of SCA in relation to contact based transactions. If the application of SCA at such environments is required it would entail significant obstacles for PSUs such as paying at toll ways (bridges and highways) in their daily commute and when travelling abroad.
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?
No comments.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?
Re Application of PSD2 Article 74(2)In the Rationale, 19(b), it is provided, that the EBA is of the understanding that PSD2 Article 74(2) will only apply during the transitional period between the application date of the PSD2 and the application date of the RTS under consultation.
First of all, it should be noted that the PSD2 does not provide that Article 74(2) will only apply for a transitional period of time.
Second of all, in case Article 74(2) will not apply after the application date of the RTS, this does not create a level-playing field as issuers who are also providing acquiring services will have a competitive advantage compared to acquirers who are not also acting as issuers. Acquirers have agreements with merchants, not issuers, but the acquirers are left without a say if they are not able to take on liability towards the merchants and, thus, the (non-issuer) acquiring PSP – merchant (payee) relationship will be negatively affected.
Third of all, it should be noted that if liability is placed solely on the issuers, the acquirers and the payees will be less likely to protect the PSUs from man-in-the-middle attacks, etc. Placing all liability with the ASPSPs would only make sense in a world with no fraud, however, neither the EBA nor the issuers can be guaranteed against fraud. Instead, both ASPSPs and acquiring PSPs should have an incentive to secure the optimal balance between risk of fraud and convenience which could be achieved with the continued application of Article 74 (2) after the RTS enter into force.
In addition to keeping Article 74 (2), we suggest a model where the ASPSPs make the SCA elements available to the acquiring PSPs and, on that basis, the acquiring PSPs would have the opportunity to match or exceed these elements with a view to gain liability shift.
Re “Usage” of Personalised Security Credentials
In relation to RTS Articles 11, 12, 13, 14 and 15, they seem to comprise the protection of the PSC entire lifecycle. However, clauses for the usage of PSC are missing. The RTS should provide for security requirements related to the PSU’s general daily usage of the PSC, as confidentiality of the PSC in all stages of the life time is essential for the security of the entire solution. Omitting security requirements for the usage phase of the PSC could lead to serious security flaws.