Response to consultation on RTS specifying the requirements on strong customer authentication and common and secure communication under PSD2
Go back
The EACB would like to comment on the four following main topics:
1) Scope:
- [All articles in Chapter 1]: The EACB considers that it could be useful to define which specific kind of payments fall under the scope of each of the articles of Chapter 1. We are not convinced for example that the requirements regarding dynamic linking as described can work in the case of bulk payments for corporates, ATM withdrawals or POS payments. An option could be to add in these articles a provision stating for instance that article X applies to credit transfers, direct debits, contactless, instant, mobile payments or card payments.
2) Concepts:
- [Article 1]: Firstly, regarding the terminology, it would like to stress that the draft RTS does not provide enough clarity regarding some fundamental concepts such as ’’authentication code’’ or ’’authentication procedure’’. Article 1 of the Draft RTS creates some confusion between ’’authentication’’ and ’’authorisation’’. Indeed, according to article 4 of PSD2 ’’authentication’’ is the procedure allowing the PSP to verify the identity of the user. In contrast, authorisation happens when the customer approves the execution of a specific operation/payment. For instance, article 1.3 (e) of the draft RTS openly refers to authorisation instead of authentication.
- [Article 1.1]: Furthermore, article 1.1 of the draft RTS states that ’’the authentication procedure should result in the generation of an authentication code that it is accepted only once by the payment services provider’’. The EACB would like to suggest the EBA to clarify whether the authentication code is the output or an input (One Time Password) to the authentication procedure.
- [Article 2. 2 b)]: As far as the strong customer authentication procedure with dynamic linking is concerned, the EACB would like to request a clarification regarding the meaning of device, channel and mobile application in article 2.2 of the draft RTS. Indeed, the provision requires PSPs to ensure the independence or segregation of the channels, devices or mobile applications used on the one side for displaying the information about the specific payee and amount and on the other side for initiating the electronic payment. The EACB would propose to either define more clearly what the three terms are meant to mean or to delete the text of art. 2.2 (b) reading “The channel, device or mobile application……payment transaction”. In defence of the latter option, the EACB considers that the the first sentence of art 2.2 (a) and 2.2. (b) are already sufficient to explain the objective pursued.
- [Article 1. 2]: Regarding article 1.2 of the Draft RTS, the EACB thinks that it could be useful to explain that, in order to achieve the goal to prevent reuse or use of an old-and-unused authentication code, the expiration time of an authentication code can be also assured by the authentication system, not necessarily included in the generation algorithm. For example, when the authentication code is generated by the system and sent via a secure channel to the customer, the system may associate the generation time to the code and discard the code when it has been provided after a prefixed period.
3) Mechanisms that should be included in the strong customer authentication procedure (article 1. 3 of the draft RTS):
- [Article 1. 3 (a)]: In order to not force mandatory customer’s logout after a session time limit, lowering the customer experience, the same security objective may be achieved forcing logout after a period of session inactivity. Instead of the logout, it may be asked customer to re-authenticate himself/herself if he/she would like to continue the session.
- [Article 1. 3 (b)]: Regarding the requirement consisting in excluding that any of the authentication elements can be identified as incorrect where the authentication procedure has failed to generate the authentication code, the EACB believes that feedback to the customer might be useful under some circumstances. Therefore, this article should be revised specially for those situation where a single authentication element is required.
- [Article 1. 3 (c)]: It could be useful to explain that blocking further customer action after the maximum number of failed authentication attempts may be performed by the PSP without taking into consideration “a given period of time”.
- [Article 1. 3 (e)]: According to the draft RTS, PSPs have to ’’prevent, detect and block fraudulent transactions’’ in the context of the strong customer authentication procedure. This formulation suggests that PSPs have to deal with any kind of fraud within the authentication procedure. Whilst banks have extensive fraud management processes in place, the EACB would consider that this obligation falls within the context of the authentication process specifically and should thus be limited to fraud related to authentication. Furthermore, although the use of the mechanisms listed as (i.) to (v.) in article 1. 3 (e) are widely implemented, we feel that including them as mandatory (instead of recommended) may take out of compliance risk analysis systems which use, for example, only four of the listed five but take into account other mechanisms (such as IP address or geolocalization analysis) unlisted but, in our opinion, not less useful.
4) Independence of the authentication elements:
- [Article 6.2]: Finally, as far as the independence of the authentication elements is concerned and when the authentication elements or the code are used through multi-purpose devices such as tablets or mobile phones, the EACB considers that ASPSP do not always have the means to control whether there is a risk of the device being compromised. Indeed, multi-purpose devices belong to consumers and what they put on it/how they use it remain largely outside the control of banks. Therefore we suggest to modify the drafting of article 6.2 of the draft RTS to read ’’the authentication procedure shall provide measures to mitigate the consequences of the multi-purpose device being compromised’’ instead of mitigating ’’the risks of the multi-purpose device being compromised’’.
Having said that, we are not convinced that the requirements regarding dynamic linking as described can work in the case of bulk payments for corporates, ATM withdrawals or POS payments. It would be useful to clarify that this article is not meant to cover all electronic payments.
The EACB also considers that the requirement on the independence or segregation of the devices is too restrictive. Indeed, the EACB would like to point out that it is possible to operate safely when the device displaying the information that links the transaction to a specific payee or amount is the same one as it is used to initiate the electronic payment.
Furthermore, as explained above in our response to question 1, the EACB would ask either to define more clearly what the terms “channel”, “device” or “mobile application” mean or to delete the text of art. 2.2 (b) reading “The channel, device or mobile payment……payment transaction”. In defense of the latter option, the EACB considers that the first sentence of the art 2.2 (a) and 2.2. (b) are already sufficient to explain the objective pursued.
More in general, the EACB believes that the environment in which the draft RTS will be implemented is an increasingly complex ecosystem full of diverse providers. The RTS should be designed in such a way as not to freeze developments in this context. This complex and uncertain environment necessarily raises the important question of the allocation of liability between the different actors involved in a specific transaction. For instance, it might be the case that the technological solution used in a specific transaction is supported by software that is not under the control of the bank.
- [Article 3 and 4]: The requirements related to elements categorized as knowledge and possession seem to be related to specific elements (password, token generator) and may not suit innovative solutions like image or pattern selection or mobile phones associated to the customer.
- [Article 5]: Following the question raised by EBA on the Discussion Paper of December 2015, the EACB would like to point out that the possibility to use behavioural data as a standalone inherence element should be clearly excluded in article 5 of the draft RTS. Indeed, behavioural authentication is still an early technology which has to be monitored and tested in detail in combination with a specific threat model. Although it could be a solution which combines strong security with user convenience, it seems too early to base the inherence elements on behavioural data only.
- [Article 3, 4 and 5]: The list of terms used in these articles as examples of security features that should characterized authentication elements should be removed. The EACB considers that the objective of protecting authentication elements against any risk of fraud can be equally achieved without listing technological terms that might be outdated or unsuitable for the future. Therefore, the EACB would like to propose the deletion of the following parts of articles 3, 4 and 5:
• [Article 3.1]: The elements of strong customer authentication categorised as knowledge shall be characterized by security features including, but not limited to, length, complexity, expiration time and the use of non-repeatable characters ensuring resistance against the risk of the elements being uncovered or disclosed to unauthorised parties.
• [Article 4.1]: The elements of strong customer authentication categorised as possession shall be characterised by security features including, but not limited to, algorithm specifications, key length and information entropy ensuring resistance against the risk of the elements being used by, or disclosed to, unauthorised parties.
• [Article 5.1]: Devices and software provided to the payer in order to read authentication elements categorized as inherence shall be characterized by security features including, but not limited to, algorithm specifications, biometric sensor and template protection features ensuring resistance against the risk of sensitive information related to the elements being disclosed to unauthorised parties.
The EACB would like to make the following comments:
- [Rationale 55]: In line with what we understood at the Public Hearing that took place at the EBA premises on the 23rd of September 2016 and the views expressed by the European Commission on the issue of the exemptions, it should be clarified that the PSP, also when the conditions for the application of an exemption are met, remains free to decide whether or not to apply the strong customer authentication procedure on the ground of security reason. This option should be activated given that Article 98. 3 (a) of PSD2 provides for the possibility to base exemptions on ’’the level of risk involved in the service provided’’. Therefore the banks’ risk analysis should be allowed to play a role in the implementation of the overall strong customer authentication internal procedure. Indeed, risk based approaches are promoted by supervisors and regulators in many areas of banking such as credit analysis and AML. It would be inconsistent not to apply such approach in this case.
The EACB understands that when a PSP decides to deviate from an exemption, it should be able to explain its action and should not discriminate between transactions from TPPs and its own.
- [Article 8. 1 (a) i.]: The draft RTS provides that the application of strong customer authentication shall not be exempted where the payer accesses for the first time the information of its payment account online, or the consolidated information on other payment accounts held. On this specific point, we think that keeping the need of strong authentication when the access to the information occurs “for the first time” entails the need for the PSP to guarantee the strong authentication for the customer – including all the cost related to guarantee this specific measure (i.e. token) – even for only one time. So, basically, we think that it is not a real exemption if PSPs have to put in place all the specific requirements for strong authentication, even for the first time;
- [Article 8. 1 (b)]: It provides for an exemption for the case of a contactless electronic payment transaction meeting the following conditions: ”i. the individual amount of contactless electronic payment transaction does not exceed the maximum amount of 50 EUR; ii. the cumulative amount of previous non-remote electronic payment transactions initiated via the payment instrument offering a contactless functionality without application of strong customer authentication does not exceed 150 EUR.” In our opinion, EBA should further clarify the limit of 150 EUR, including a definition of the reference period to calculate this “cumulative amount” (one week? one day?); in addition, the question can be raised why such an exemption should be applied to contactless payments only and not to contact payments.
- [Article 8. 2 (a)]: “list of trusted beneficiaries previously created by the payer with its account servicing payment services provider”: we agree with the exemption but we think that PSP should have the possibility, for security reasons, to create some specific limits to this exemption.
The EACB considers that preventing PSPs to apply strong customer authentication when they deem it necessary would be unacceptable according to the spirit of PSD2.
Indeed, article 98. 3 of PSD2 literally states that exemptions from strong customer authentication should be based among others on ’’the level of risk involved in the service provided’’. From our perspective, this article is clear enough to understand that the aim of the legislator has been to allow for a risk based approach to the exemptions from the application of strong customer authentication.
Therefore, the EACB considers that article 8 of the draft RTS cannot be fully conceived without taking into account the implications of a risk based approach. The interpretation of PSD2 provisions on this specific aspect may correspond to the European Commission, but providing the rules for the exemptions including the bank’s own risk analysis is a part of EBA’s mandate.
Therefore, the EACB trusts that the scenario in which PSPs are prevented from implementing strong customer authentication that meet the criteria for exemption will not become a binding reality.
- [Rationale 19 (a)]: According to the EBA, the scenario in which a PISP issue its own personalised security credentials for the user should remain within the sphere of competence of that PISP. The EACB welcomes that the acceptance of such credentials should be subject to a prior contractual agreement between the banks and the PISP and would suggest to extend this reasoning to AISP. Furthermore, it might be useful to have this provision within the binding text of the RTS (not only rationale).
- [Article 9. 1 (c)]:. With regard to this article, EACB members would like to be reassured that they can continuously monitor the evolution of security technology and apply state of the art measures. In this context, the EACB would like to suggest a more open wording and propose to replace ‘’secure and tamper resistant devices and environments’’ by ‘’secure environments’’.
- [Article 10]: The scope of the requirement should not be limited to the context of acquiring of card-based transactions.
- [Recital 13]: The access of third parties to payments accounts should be implemented with some security measures which are needed in order to protect the confidentiality of the information that is present in the system of the PSP and that is not directly linked to the operation which is subject to the access of a third party. Without these security measures, third parties have a direct access to the internet banking of the bank’s customers and are allowed to see all the services provided by the PSP through the internet banking; including services that are not necessarily linked with the payment/consultation operation required. The EACB was therefore happy to receive confirmation during the Public Hearing that took place on the 23rd of September at the EBA premises, that ASPSP have the possibility to choose whether to allow AISP, PISP or payment service providers issuing card-based payment instruments access via online banking or via a new “dedicated” interface for AISS, PISP e.g. with APIs. According to the explanations provided by EBA on this point, banks will not need for instance to ensure also the access of third-parties thought their online banking platforms if they have decided to develop a specific interface for the communication with third-party providers.
- [Article 19. 4]: It should not be required that the technical specifications of the communication interface are made available as a publicly downloadable documentation. Rather, they should be freely sent on demand after the verification of the legitimate identity of the PSP.
- [Article 19. 5]: The requirement to publicly disclose changes 3 months in advance has the following disadvantages: a) it does not favour rapid adoption of changes; b) new functionalities’ specifications may often change in the final steps of development as a result of internal tests; c) it may break fair competition between PSPs. According to the above listed topics, we suggest to specify a period of 1 month.
- [Article 19. 7]: Ensuring freely and unlimited availability of test environment to the community of TPPs increases management costs with no obligation for the supported PSP to develop and correctly manage interface on their side.
- [Article 19. 6]: According to article 19. 6 of the draft RTS “ASPSP shall ensure that their communication interface is operating on the same level of service, including support, as the online platform made available to the payment service user when directly accessing its accounts online. Account servicing payment service providers shall monitor the availability of this communication interface and make such statistics available on demand to the competent authorities”. The EACB would like to point out that ensuring freely and unlimited availability of support to the community of TPPs increases management costs with no obligation for the supported PSP to develop and correctly manage the interface on their side. Free of charge support should be limited to basic questions.
- [Article 21. 5]: Regarding the security of the communication session, the EACB considers that it is not safe enough to prevent only the staff of AISP and PISP from seeing the credentials in the clear in intermediate stages. Indeed, machines can still see the credentials and these machines can be compromised/hacked even within secure environments and also need to be shielded from access to this information.
- [Article 22. 1 (a)]: Regarding the lack of definition of sensitive payment data, it should be clarified that information made available to TPPs shall be strictly limited to those required by payment systems and they shall not include other personal information that could be maintained by ASPSPs as other services of functionality provided by the website channel. According to our understanding of the EBA Public Hearing on PSD2 (article 98), ASPSP should only ensure TPP’s access to PSD2 related payments’ information.
However, regarding the content of the certificate (article 20. 3 (a)) which shall include, among others, the role of the PSP, the EACB would like to point out that the situation of players having multiple roles should also be considered by adding and/or between the different forms of provider.
Furthermore, a clarification may be needed in order to clarify that the scope of the requirement is limited to identification between the servers of different providers (TPPs, ASPSPs) and does not include identification of devices held by users.
- [Article 22. 5 (a)]: AISP requesting information from a designated payments account based on the user’s request: the EACB agrees with the EBA’s view that this scenario should not be subject to limits regarding the frequency of the information requests from the AISP.
- [Article 22. 5 (b)]: AISP requesting information from a designated payments account without the user’s request: the EACB would like to propose a maximum of 1 request per day as this limit ensures that the average user of AIS will have access to updated information. In addition, the EACB considers that a mandate or any other technical means should be envisaged for banks to know that the user has given his/her consent to the AISP to access his/her payment account when there is no explicit demand from his/her side.
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 EACB takes note of the EBA’s approach to the definition of the requirements of the strong customer authentication consisting in setting high level principles over extremely detailed provisions.The EACB would like to comment on the four following main topics:
1) Scope:
- [All articles in Chapter 1]: The EACB considers that it could be useful to define which specific kind of payments fall under the scope of each of the articles of Chapter 1. We are not convinced for example that the requirements regarding dynamic linking as described can work in the case of bulk payments for corporates, ATM withdrawals or POS payments. An option could be to add in these articles a provision stating for instance that article X applies to credit transfers, direct debits, contactless, instant, mobile payments or card payments.
2) Concepts:
- [Article 1]: Firstly, regarding the terminology, it would like to stress that the draft RTS does not provide enough clarity regarding some fundamental concepts such as ’’authentication code’’ or ’’authentication procedure’’. Article 1 of the Draft RTS creates some confusion between ’’authentication’’ and ’’authorisation’’. Indeed, according to article 4 of PSD2 ’’authentication’’ is the procedure allowing the PSP to verify the identity of the user. In contrast, authorisation happens when the customer approves the execution of a specific operation/payment. For instance, article 1.3 (e) of the draft RTS openly refers to authorisation instead of authentication.
- [Article 1.1]: Furthermore, article 1.1 of the draft RTS states that ’’the authentication procedure should result in the generation of an authentication code that it is accepted only once by the payment services provider’’. The EACB would like to suggest the EBA to clarify whether the authentication code is the output or an input (One Time Password) to the authentication procedure.
- [Article 2. 2 b)]: As far as the strong customer authentication procedure with dynamic linking is concerned, the EACB would like to request a clarification regarding the meaning of device, channel and mobile application in article 2.2 of the draft RTS. Indeed, the provision requires PSPs to ensure the independence or segregation of the channels, devices or mobile applications used on the one side for displaying the information about the specific payee and amount and on the other side for initiating the electronic payment. The EACB would propose to either define more clearly what the three terms are meant to mean or to delete the text of art. 2.2 (b) reading “The channel, device or mobile application……payment transaction”. In defence of the latter option, the EACB considers that the the first sentence of art 2.2 (a) and 2.2. (b) are already sufficient to explain the objective pursued.
- [Article 1. 2]: Regarding article 1.2 of the Draft RTS, the EACB thinks that it could be useful to explain that, in order to achieve the goal to prevent reuse or use of an old-and-unused authentication code, the expiration time of an authentication code can be also assured by the authentication system, not necessarily included in the generation algorithm. For example, when the authentication code is generated by the system and sent via a secure channel to the customer, the system may associate the generation time to the code and discard the code when it has been provided after a prefixed period.
3) Mechanisms that should be included in the strong customer authentication procedure (article 1. 3 of the draft RTS):
- [Article 1. 3 (a)]: In order to not force mandatory customer’s logout after a session time limit, lowering the customer experience, the same security objective may be achieved forcing logout after a period of session inactivity. Instead of the logout, it may be asked customer to re-authenticate himself/herself if he/she would like to continue the session.
- [Article 1. 3 (b)]: Regarding the requirement consisting in excluding that any of the authentication elements can be identified as incorrect where the authentication procedure has failed to generate the authentication code, the EACB believes that feedback to the customer might be useful under some circumstances. Therefore, this article should be revised specially for those situation where a single authentication element is required.
- [Article 1. 3 (c)]: It could be useful to explain that blocking further customer action after the maximum number of failed authentication attempts may be performed by the PSP without taking into consideration “a given period of time”.
- [Article 1. 3 (e)]: According to the draft RTS, PSPs have to ’’prevent, detect and block fraudulent transactions’’ in the context of the strong customer authentication procedure. This formulation suggests that PSPs have to deal with any kind of fraud within the authentication procedure. Whilst banks have extensive fraud management processes in place, the EACB would consider that this obligation falls within the context of the authentication process specifically and should thus be limited to fraud related to authentication. Furthermore, although the use of the mechanisms listed as (i.) to (v.) in article 1. 3 (e) are widely implemented, we feel that including them as mandatory (instead of recommended) may take out of compliance risk analysis systems which use, for example, only four of the listed five but take into account other mechanisms (such as IP address or geolocalization analysis) unlisted but, in our opinion, not less useful.
4) Independence of the authentication elements:
- [Article 6.2]: Finally, as far as the independence of the authentication elements is concerned and when the authentication elements or the code are used through multi-purpose devices such as tablets or mobile phones, the EACB considers that ASPSP do not always have the means to control whether there is a risk of the device being compromised. Indeed, multi-purpose devices belong to consumers and what they put on it/how they use it remain largely outside the control of banks. Therefore we suggest to modify the drafting of article 6.2 of the draft RTS to read ’’the authentication procedure shall provide measures to mitigate the consequences of the multi-purpose device being compromised’’ instead of mitigating ’’the risks of the multi-purpose device being compromised’’.
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.
The EACB in principle agrees with the EBA reasoning as explained in Rationale 23 of the Consultation Paper that requirements should remain neutral as to when the ’’dynamic linking’’ should take place under the conditions expressed above. Indeed, the EACB welcomes EBA’s effort to provide PSPs with flexibility to adapt their current solutions and make them compliant with the draft RTS.Having said that, we are not convinced that the requirements regarding dynamic linking as described can work in the case of bulk payments for corporates, ATM withdrawals or POS payments. It would be useful to clarify that this article is not meant to cover all electronic payments.
The EACB also considers that the requirement on the independence or segregation of the devices is too restrictive. Indeed, the EACB would like to point out that it is possible to operate safely when the device displaying the information that links the transaction to a specific payee or amount is the same one as it is used to initiate the electronic payment.
Furthermore, as explained above in our response to question 1, the EACB would ask either to define more clearly what the terms “channel”, “device” or “mobile application” mean or to delete the text of art. 2.2 (b) reading “The channel, device or mobile payment……payment transaction”. In defense of the latter option, the EACB considers that the first sentence of the art 2.2 (a) and 2.2. (b) are already sufficient to explain the objective pursued.
More in general, the EACB believes that the environment in which the draft RTS will be implemented is an increasingly complex ecosystem full of diverse providers. The RTS should be designed in such a way as not to freeze developments in this context. This complex and uncertain environment necessarily raises the important question of the allocation of liability between the different actors involved in a specific transaction. For instance, it might be the case that the technological solution used in a specific transaction is supported by software that is not under the control of the bank.
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?
In addition to the threats identified in articles 3, 4 and 5 of the draft RTS, the EACB is not aware of other specific threats against which authentication elements should be resistant.- [Article 3 and 4]: The requirements related to elements categorized as knowledge and possession seem to be related to specific elements (password, token generator) and may not suit innovative solutions like image or pattern selection or mobile phones associated to the customer.
- [Article 5]: Following the question raised by EBA on the Discussion Paper of December 2015, the EACB would like to point out that the possibility to use behavioural data as a standalone inherence element should be clearly excluded in article 5 of the draft RTS. Indeed, behavioural authentication is still an early technology which has to be monitored and tested in detail in combination with a specific threat model. Although it could be a solution which combines strong security with user convenience, it seems too early to base the inherence elements on behavioural data only.
- [Article 3, 4 and 5]: The list of terms used in these articles as examples of security features that should characterized authentication elements should be removed. The EACB considers that the objective of protecting authentication elements against any risk of fraud can be equally achieved without listing technological terms that might be outdated or unsuitable for the future. Therefore, the EACB would like to propose the deletion of the following parts of articles 3, 4 and 5:
• [Article 3.1]: The elements of strong customer authentication categorised as knowledge shall be characterized by security features including, but not limited to, length, complexity, expiration time and the use of non-repeatable characters ensuring resistance against the risk of the elements being uncovered or disclosed to unauthorised parties.
• [Article 4.1]: The elements of strong customer authentication categorised as possession shall be characterised by security features including, but not limited to, algorithm specifications, key length and information entropy ensuring resistance against the risk of the elements being used by, or disclosed to, unauthorised parties.
• [Article 5.1]: Devices and software provided to the payer in order to read authentication elements categorized as inherence shall be characterized by security features including, but not limited to, algorithm specifications, biometric sensor 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?
The EACB considers that the EBA’s reasoning on the exemptions from the application of article 97 of PSD2 is very prescriptive. Combined with the fact that banks are largely liable for any fraud and are the first port of call to resolve any issue puts banks (and their mandate to protect client funds) in a straightjacket without recourse to own risk management. This straightjacket also does not offer much flexibility in providing smooth customer experience (like Uber, 1-click, etc.) which merchants and customers want.The EACB would like to make the following comments:
- [Rationale 55]: In line with what we understood at the Public Hearing that took place at the EBA premises on the 23rd of September 2016 and the views expressed by the European Commission on the issue of the exemptions, it should be clarified that the PSP, also when the conditions for the application of an exemption are met, remains free to decide whether or not to apply the strong customer authentication procedure on the ground of security reason. This option should be activated given that Article 98. 3 (a) of PSD2 provides for the possibility to base exemptions on ’’the level of risk involved in the service provided’’. Therefore the banks’ risk analysis should be allowed to play a role in the implementation of the overall strong customer authentication internal procedure. Indeed, risk based approaches are promoted by supervisors and regulators in many areas of banking such as credit analysis and AML. It would be inconsistent not to apply such approach in this case.
The EACB understands that when a PSP decides to deviate from an exemption, it should be able to explain its action and should not discriminate between transactions from TPPs and its own.
- [Article 8. 1 (a) i.]: The draft RTS provides that the application of strong customer authentication shall not be exempted where the payer accesses for the first time the information of its payment account online, or the consolidated information on other payment accounts held. On this specific point, we think that keeping the need of strong authentication when the access to the information occurs “for the first time” entails the need for the PSP to guarantee the strong authentication for the customer – including all the cost related to guarantee this specific measure (i.e. token) – even for only one time. So, basically, we think that it is not a real exemption if PSPs have to put in place all the specific requirements for strong authentication, even for the first time;
- [Article 8. 1 (b)]: It provides for an exemption for the case of a contactless electronic payment transaction meeting the following conditions: ”i. the individual amount of contactless electronic payment transaction does not exceed the maximum amount of 50 EUR; ii. the cumulative amount of previous non-remote electronic payment transactions initiated via the payment instrument offering a contactless functionality without application of strong customer authentication does not exceed 150 EUR.” In our opinion, EBA should further clarify the limit of 150 EUR, including a definition of the reference period to calculate this “cumulative amount” (one week? one day?); in addition, the question can be raised why such an exemption should be applied to contactless payments only and not to contact payments.
- [Article 8. 2 (a)]: “list of trusted beneficiaries previously created by the payer with its account servicing payment services provider”: we agree with the exemption but we think that PSP should have the possibility, for security reasons, to create some specific limits to this exemption.
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?
Pending clarification from the European Commission on whether or not PSPs would have the possibility to apply strong customer authentication when the conditions for an exemption are met, the EACB would like to expose in advance its point of view.The EACB considers that preventing PSPs to apply strong customer authentication when they deem it necessary would be unacceptable according to the spirit of PSD2.
Indeed, article 98. 3 of PSD2 literally states that exemptions from strong customer authentication should be based among others on ’’the level of risk involved in the service provided’’. From our perspective, this article is clear enough to understand that the aim of the legislator has been to allow for a risk based approach to the exemptions from the application of strong customer authentication.
Therefore, the EACB considers that article 8 of the draft RTS cannot be fully conceived without taking into account the implications of a risk based approach. The interpretation of PSD2 provisions on this specific aspect may correspond to the European Commission, but providing the rules for the exemptions including the bank’s own risk analysis is a part of EBA’s mandate.
Therefore, the EACB trusts that the scenario in which PSPs are prevented from implementing strong customer authentication that meet the criteria for exemption will not become a binding reality.
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?
The EACB takes note of the EBA’s reasoning on the protection of the confidentiality and the integrity of the payment service users’ personalised security credentials. In this context, we would like to make the following comments:- [Rationale 19 (a)]: According to the EBA, the scenario in which a PISP issue its own personalised security credentials for the user should remain within the sphere of competence of that PISP. The EACB welcomes that the acceptance of such credentials should be subject to a prior contractual agreement between the banks and the PISP and would suggest to extend this reasoning to AISP. Furthermore, it might be useful to have this provision within the binding text of the RTS (not only rationale).
- [Article 9. 1 (c)]:. With regard to this article, EACB members would like to be reassured that they can continuously monitor the evolution of security technology and apply state of the art measures. In this context, the EACB would like to suggest a more open wording and propose to replace ‘’secure and tamper resistant devices and environments’’ by ‘’secure environments’’.
- [Article 10]: The scope of the requirement should not be limited to the context of acquiring of card-based transactions.
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?
The EACB takes note of the requirements for common and secure open standards of communication and the resultant provisions proposed by EBA in Chapter 4 of the draft RTS. In this context, we wish to make the following observations and comments:- [Recital 13]: The access of third parties to payments accounts should be implemented with some security measures which are needed in order to protect the confidentiality of the information that is present in the system of the PSP and that is not directly linked to the operation which is subject to the access of a third party. Without these security measures, third parties have a direct access to the internet banking of the bank’s customers and are allowed to see all the services provided by the PSP through the internet banking; including services that are not necessarily linked with the payment/consultation operation required. The EACB was therefore happy to receive confirmation during the Public Hearing that took place on the 23rd of September at the EBA premises, that ASPSP have the possibility to choose whether to allow AISP, PISP or payment service providers issuing card-based payment instruments access via online banking or via a new “dedicated” interface for AISS, PISP e.g. with APIs. According to the explanations provided by EBA on this point, banks will not need for instance to ensure also the access of third-parties thought their online banking platforms if they have decided to develop a specific interface for the communication with third-party providers.
- [Article 19. 4]: It should not be required that the technical specifications of the communication interface are made available as a publicly downloadable documentation. Rather, they should be freely sent on demand after the verification of the legitimate identity of the PSP.
- [Article 19. 5]: The requirement to publicly disclose changes 3 months in advance has the following disadvantages: a) it does not favour rapid adoption of changes; b) new functionalities’ specifications may often change in the final steps of development as a result of internal tests; c) it may break fair competition between PSPs. According to the above listed topics, we suggest to specify a period of 1 month.
- [Article 19. 7]: Ensuring freely and unlimited availability of test environment to the community of TPPs increases management costs with no obligation for the supported PSP to develop and correctly manage interface on their side.
- [Article 19. 6]: According to article 19. 6 of the draft RTS “ASPSP shall ensure that their communication interface is operating on the same level of service, including support, as the online platform made available to the payment service user when directly accessing its accounts online. Account servicing payment service providers shall monitor the availability of this communication interface and make such statistics available on demand to the competent authorities”. The EACB would like to point out that ensuring freely and unlimited availability of support to the community of TPPs increases management costs with no obligation for the supported PSP to develop and correctly manage the interface on their side. Free of charge support should be limited to basic questions.
- [Article 21. 5]: Regarding the security of the communication session, the EACB considers that it is not safe enough to prevent only the staff of AISP and PISP from seeing the credentials in the clear in intermediate stages. Indeed, machines can still see the credentials and these machines can be compromised/hacked even within secure environments and also need to be shielded from access to this information.
- [Article 22. 1 (a)]: Regarding the lack of definition of sensitive payment data, it should be clarified that information made available to TPPs shall be strictly limited to those required by payment systems and they shall not include other personal information that could be maintained by ASPSPs as other services of functionality provided by the website channel. According to our understanding of the EBA Public Hearing on PSD2 (article 98), ASPSP should only ensure TPP’s access to PSD2 related payments’ information.
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?
As ISO 20022 is regularly used in the banking environment, the EACB agrees 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 banks and third party providers.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 ?
The EACB agrees that website certificates issued by a qualified trust service provider under an e-IDAS policy are a suitable solution for the identification between PSPs. Indeed, it is particularly welcomed that PSPs must identify themselves with a digital certificate so the bank can see it’s a third party accessing the account and not the customer.However, regarding the content of the certificate (article 20. 3 (a)) which shall include, among others, the role of the PSP, the EACB would like to point out that the situation of players having multiple roles should also be considered by adding and/or between the different forms of provider.
Furthermore, a clarification may be needed in order to clarify that the scope of the requirement is limited to identification between the servers of different providers (TPPs, ASPSPs) and does not include identification of devices held by users.
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.
The EACB takes note of the approach taken by EBA in article 22.5 of the draft RTS consisting in dealing in a different way with the frequency of account information services depending on whether or not the information request is required by the user. In this framework, the EACB would like to make the following comments on the specific limits.- [Article 22. 5 (a)]: AISP requesting information from a designated payments account based on the user’s request: the EACB agrees with the EBA’s view that this scenario should not be subject to limits regarding the frequency of the information requests from the AISP.
- [Article 22. 5 (b)]: AISP requesting information from a designated payments account without the user’s request: the EACB would like to propose a maximum of 1 request per day as this limit ensures that the average user of AIS will have access to updated information. In addition, the EACB considers that a mandate or any other technical means should be envisaged for banks to know that the user has given his/her consent to the AISP to access his/her payment account when there is no explicit demand from his/her side.