Response to consultation on RTS specifying the requirements on strong customer authentication and common and secure communication under PSD2
Go back
1) The proposed requirements for SCA currently mix elements of the authorisation process with the authentication process.
The current wording of Articles 1.1, 1.2, 1.3 and Rationale 19 seems to have mixed together the separate concepts of the ‘authentication of the payer’ and the payer’s ‘authorisation of a payment’. In order to avoid unintended consequences, we believe it will be important for these articles to be rewritten in a way which differentiates more clearly between the requirements which relate to these separate concepts.
In this context, we note that the PSD2 definition of “authentication” in Article 4(29) clarifies that authentication is a “procedure which allows the PSP to verify the identity of a PSU or the validity of the use of a specific payment instrument, including the use of the user’s personalised security credentials”, which is not the same as giving approval (‘authorisation’) to the execution of a payment or other specific action.
2) It would be important to clarify that ATM transactions and services are out of scope of the SCA requirements
Our reading of PSD2 would be that a balance and/or transaction check via an ATM would not be seen as falling within the scope of PSD2 Article 97(1)(a) and that an ATM withdrawal or an ATM-initiated payment would not be seen as falling under PSD2 Article 97(2) and the definition of a “remote electronic payment transactions”. Fraudulent transactions at ATMs are comparatively low relative to those carried out at physical point of sale and on-line. To introduce a dynamic element to authorisation at an ATM, would be inconvenient to the consumer, costly for the industry and unlikely to result in significant benefits.
Assuming that the EBA agrees with this interpretation, it would be helpful if this could be clarified in the RTS. As an alternative approach, ATM transactions could be added to the list of exemptions in Chapter 2.
3) A flexible approach to the use of one-time transaction codes will be important in the interests of the end-customer experience and to support innovative solutions
Paragraph 25 in the EBA’s supporting Rationale states that one-time passwords linked to the amount and payee may be generated “with or without any action required by the payer itself”. However, this degree of flexibility is not referenced directly within RTS Article 1(1) itself.
Given the importance of allowing this degree of flexibility in the interests of future proofing and a better customer experience we would ask that appropriate wording is included within the RTS itself making clear that such a one-time code could be delivered through a solution in the background not requiring customer intervention (such as an application cryptogram generated during the authorisation process) as an alternative to being input directly by customers.
4) The reference to ‘trusted execution environment’ in article 6.3 needs to be made more neutral
We believe that the current reference in Article 6(3) to a 'trusted execution environment' should be amended to a more neutral wording, such as 'appropriately secured technical environment'. This change would be in the interests of promoting technical neutrality, given that the phrase “Trusted Execution Environment” is often used in the market in relation to a specific technical approach, which we assume is not the EBA’s intention.
5) The wording of Article 2(2)(b) needs to be clarified
We believe that the following phrase in Article 2(2)(b) is not entirely clear as to its meaning: “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”
Further clarification in the final version of the RTS on the meaning of “segregated” and “independent” in this context would be important, noting the EBA’s helpful comment during the recent Public Hearing that the EBA was not suggesting that the use of separate devices would be necessary and the example given in Rationale paragraph 26 that use of an “independent channel” would be one way of achieving this.
6) Clarification would be welcomed on the intention behind the phrase “shall take into account but not limited to” as used in Article 1(3)(e), and Article 6(3).
It is unclear to us whether this phrase – which also occurs in various other places in the draft RTS – is meant to indicate that the points that follow are merely examples of possible approaches that could be adopted, or alternatively are regarded as prescriptive points which must be followed. We would support the former approach, as the latter would seem to be overly prescriptive and not in line with the EBA’s intention to promote technical neutrality in the interests of future innovation.
7) Greater clarity would be welcomed on how the RTS are intended to apply to businesses/corporates
Although the RTS focus primarily on consumer protection, we note that there are few opt outs for other types of payment service user. We believe that the final version of the RTS needs to provide more guidance on how the RTS would apply to the different requirements and operating practices of business and corporate customers. For example, how corporate mandates would be expected to be used in the new world, and how the RTS will have sufficient flexibility to accommodate elements such as dual signatories in the context of the SCA requirements and more generally in relation to the use of PIS and AIS services.
However, we do have a specific question in relation to Article 2(4). Whilst it would be feasible to link the ‘authentication code’ to the batch file amount total, the article calls for dynamic linking “to the payees of the batch of transactions considered collectively”. Having a code which somehow links to multiple payees within a file does not seem to be a practical requirement if interpreted literally. Is this the EBA’s intention?
1) Clarity of key terms will be crucial in ensuring that the list of exemptions is appropriate and sufficiently comprehensive
Although PSD2 includes a definition for a “remote payment transaction” in PSD2 Article 4(6) - a term which is then used in PSD2 Article 97(2) – it does not define the term “electronic payment transaction”, which is used in PSD2 Article 97(1)(b). It would be important to clarify this term in the context of the RTS generally, including in the context of setting the parameters for the list of SCA exemptions.
2) Setting hard transaction size limits in the EBA RTS would mean that the approach would not be future-proof nor able to adapt swiftly to changing market conditions and needs.
As a general principle, setting specific transaction limits in regulation in the way that is currently proposed in Article 8 could lead to practical implementation issues and could run the risk of stifling innovation as well as leading to a poor customer experience, such as in a situation when recourse to SCA was not practical.
In particular, the proposed limit of EUR 50 for contactless payments in Article 8(1)(b)(i) appears excessively low given the increasing popularity of contactless transactions. Additionally, the proposed cumulative limit of €150 for such transactions again looks low, particularly given that this provision does not specify a proposed time limit for cumulative transactions.
Similar issues arise in the context of the limits for remote electronic payment transactions mentioned in Article 8(2)(d).
3) We are concerned that the current list of permitted exemptions does not include risk profiling.
In the interests of customer experience and optimal fraud management, we believe that PSPs should also be given the ability to apply exemptions from SCA based on a transaction risk analysis. The current lack of such an exemption arguably not seem to align with PSD2 Art. 98.3(a), which requires exemptions based on “the level of risk involved in the service provided”.
This is particularly the case given that without the addition of such a risk-profiling based exemption the list of possible exemptions may not be sufficiently comprehensive or future proofed and have the unintended consequence of preventing future innovations in fraud prevention analysis that are to be expected in the dynamic and changing environment payments.
4) It would be reasonable for ASPSPS to also be allowed to operate a global white list of trusted payees
In the context of Article 8(2)(a) we believe that it would be logical for this exemption to also apply in the case that ASPSPs operate a white list of trusted payees (e.g. national tax accounts), in the interests of the user experience .
Mandating exemptions could also result in unresolved situations that prevent ASPSPs to comply with other regulations (e.g. national) imposing more strict requirements.
1) The meaning of the term “sensitive payment data” needs to be clarified.
We believe that it will be very important to clarify the meaning of the term “sensitive payment data” as used in Article 22(1)(a) (and elsewhere) to avoid fragmentation and a lack of harmonisation concerning the information to be made available to AISPs.
2) Requirements for Identification:The meaning of Article 17(1) needs to be clarified
We are not clear from reading this article which parties are intended to be bilaterally identified, and to who. If this is intended to refer to the general principle that all parties involved in a transaction need to be identified then it would seem that this article should be expanded to include other aspects of payment services, account information services and confirmation of availability of funds, not just payment initiation.
This feels like a topic where further discussion will be necessary to find the right balance –given also the need to reflect the potential complexity on all sides of implementing such a frequency limit.
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?
We wish to highlight a number of comments in relation to the provisions in Chapter 1 and the EBA’s supporting reasoning.1) The proposed requirements for SCA currently mix elements of the authorisation process with the authentication process.
The current wording of Articles 1.1, 1.2, 1.3 and Rationale 19 seems to have mixed together the separate concepts of the ‘authentication of the payer’ and the payer’s ‘authorisation of a payment’. In order to avoid unintended consequences, we believe it will be important for these articles to be rewritten in a way which differentiates more clearly between the requirements which relate to these separate concepts.
In this context, we note that the PSD2 definition of “authentication” in Article 4(29) clarifies that authentication is a “procedure which allows the PSP to verify the identity of a PSU or the validity of the use of a specific payment instrument, including the use of the user’s personalised security credentials”, which is not the same as giving approval (‘authorisation’) to the execution of a payment or other specific action.
2) It would be important to clarify that ATM transactions and services are out of scope of the SCA requirements
Our reading of PSD2 would be that a balance and/or transaction check via an ATM would not be seen as falling within the scope of PSD2 Article 97(1)(a) and that an ATM withdrawal or an ATM-initiated payment would not be seen as falling under PSD2 Article 97(2) and the definition of a “remote electronic payment transactions”. Fraudulent transactions at ATMs are comparatively low relative to those carried out at physical point of sale and on-line. To introduce a dynamic element to authorisation at an ATM, would be inconvenient to the consumer, costly for the industry and unlikely to result in significant benefits.
Assuming that the EBA agrees with this interpretation, it would be helpful if this could be clarified in the RTS. As an alternative approach, ATM transactions could be added to the list of exemptions in Chapter 2.
3) A flexible approach to the use of one-time transaction codes will be important in the interests of the end-customer experience and to support innovative solutions
Paragraph 25 in the EBA’s supporting Rationale states that one-time passwords linked to the amount and payee may be generated “with or without any action required by the payer itself”. However, this degree of flexibility is not referenced directly within RTS Article 1(1) itself.
Given the importance of allowing this degree of flexibility in the interests of future proofing and a better customer experience we would ask that appropriate wording is included within the RTS itself making clear that such a one-time code could be delivered through a solution in the background not requiring customer intervention (such as an application cryptogram generated during the authorisation process) as an alternative to being input directly by customers.
4) The reference to ‘trusted execution environment’ in article 6.3 needs to be made more neutral
We believe that the current reference in Article 6(3) to a 'trusted execution environment' should be amended to a more neutral wording, such as 'appropriately secured technical environment'. This change would be in the interests of promoting technical neutrality, given that the phrase “Trusted Execution Environment” is often used in the market in relation to a specific technical approach, which we assume is not the EBA’s intention.
5) The wording of Article 2(2)(b) needs to be clarified
We believe that the following phrase in Article 2(2)(b) is not entirely clear as to its meaning: “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”
Further clarification in the final version of the RTS on the meaning of “segregated” and “independent” in this context would be important, noting the EBA’s helpful comment during the recent Public Hearing that the EBA was not suggesting that the use of separate devices would be necessary and the example given in Rationale paragraph 26 that use of an “independent channel” would be one way of achieving this.
6) Clarification would be welcomed on the intention behind the phrase “shall take into account but not limited to” as used in Article 1(3)(e), and Article 6(3).
It is unclear to us whether this phrase – which also occurs in various other places in the draft RTS – is meant to indicate that the points that follow are merely examples of possible approaches that could be adopted, or alternatively are regarded as prescriptive points which must be followed. We would support the former approach, as the latter would seem to be overly prescriptive and not in line with the EBA’s intention to promote technical neutrality in the interests of future innovation.
7) Greater clarity would be welcomed on how the RTS are intended to apply to businesses/corporates
Although the RTS focus primarily on consumer protection, we note that there are few opt outs for other types of payment service user. We believe that the final version of the RTS needs to provide more guidance on how the RTS would apply to the different requirements and operating practices of business and corporate customers. For example, how corporate mandates would be expected to be used in the new world, and how the RTS will have sufficient flexibility to accommodate elements such as dual signatories in the context of the SCA requirements and more generally in relation to the use of PIS and AIS services.
Question 2: In particular, in relation to the “dynamic linking” procedure, do you agree with the EBA’s reasoning that the requirements should remain neutral as to when the “dynamic linking” should take place, under the conditions that the channel, mobile application, or device where the information about the amount and the payee of the transaction is displayed is independent or segregated from the channel, mobile application or device used for initiating the payment, as foreseen in Article 2.2 of the draft RTS.
We are supportive of the EBA's intention to promote technical neutrality in relation to the ‘dynamic linking’ requirements given the rapid speed of technological development.However, we do have a specific question in relation to Article 2(4). Whilst it would be feasible to link the ‘authentication code’ to the batch file amount total, the article calls for dynamic linking “to the payees of the batch of transactions considered collectively”. Having a code which somehow links to multiple payees within a file does not seem to be a practical requirement if interpreted literally. Is this the EBA’s intention?
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?
Nil response.Question 4: Do you agree with the EBA’s reasoning on the exemptions from the application of Article 97 on strong customer authentication and on security measures, and the resultant provisions proposed in Chapter 2 of the draft RTS?
We fully support the EBA’s conclusion that the RTS needs to allow for various exemptions from the application of the SCA requirements, but we have a number of comments in relation to the current proposals.1) Clarity of key terms will be crucial in ensuring that the list of exemptions is appropriate and sufficiently comprehensive
Although PSD2 includes a definition for a “remote payment transaction” in PSD2 Article 4(6) - a term which is then used in PSD2 Article 97(2) – it does not define the term “electronic payment transaction”, which is used in PSD2 Article 97(1)(b). It would be important to clarify this term in the context of the RTS generally, including in the context of setting the parameters for the list of SCA exemptions.
2) Setting hard transaction size limits in the EBA RTS would mean that the approach would not be future-proof nor able to adapt swiftly to changing market conditions and needs.
As a general principle, setting specific transaction limits in regulation in the way that is currently proposed in Article 8 could lead to practical implementation issues and could run the risk of stifling innovation as well as leading to a poor customer experience, such as in a situation when recourse to SCA was not practical.
In particular, the proposed limit of EUR 50 for contactless payments in Article 8(1)(b)(i) appears excessively low given the increasing popularity of contactless transactions. Additionally, the proposed cumulative limit of €150 for such transactions again looks low, particularly given that this provision does not specify a proposed time limit for cumulative transactions.
Similar issues arise in the context of the limits for remote electronic payment transactions mentioned in Article 8(2)(d).
3) We are concerned that the current list of permitted exemptions does not include risk profiling.
In the interests of customer experience and optimal fraud management, we believe that PSPs should also be given the ability to apply exemptions from SCA based on a transaction risk analysis. The current lack of such an exemption arguably not seem to align with PSD2 Art. 98.3(a), which requires exemptions based on “the level of risk involved in the service provided”.
This is particularly the case given that without the addition of such a risk-profiling based exemption the list of possible exemptions may not be sufficiently comprehensive or future proofed and have the unintended consequence of preventing future innovations in fraud prevention analysis that are to be expected in the dynamic and changing environment payments.
4) It would be reasonable for ASPSPS to also be allowed to operate a global white list of trusted payees
In the context of Article 8(2)(a) we believe that it would be logical for this exemption to also apply in the case that ASPSPs operate a white list of trusted payees (e.g. national tax accounts), in the interests of the user experience .
Question 5: Do you have any concern with the list of exemptions contained in Chapter 2 of the draft RTS for the scenario that PSPs are prevented from implementing SCA on transactions that meet the criteria for exemption?
We are not in favour of the scenario under which PSPs would be prevented from implementing SCA on transactions that meet the exemption criteria, which would seemingly mean that that PSPs would no longer have the freedom to apply SCA to any transaction where they felt that there were valid risk grounds for doing so. It seems more appropriate to us that PSPs should always have a degree of choice and control over when to apply an exemption, in the interests of being able to find the appropriate balance between user experience and protection and also given the nature of the liability regime within PSD2 and the where the risks will lie in the event of a claim of, for example, an unauthorised or incorrectly executed payment transaction.Mandating exemptions could also result in unresolved situations that prevent ASPSPs to comply with other regulations (e.g. national) imposing more strict 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?
Nil response.Question 7: Do you agree with the EBA’s reasoning on the requirements for common and secure open standards of communication for the purpose of identification, authentication, notification, and information, and the resultant provisions proposed in Chapter 4 of the draft RTS?
We are broadly supportive of the EBA's reasoning and resultant provisions, but have the following specific questions and comments.1) The meaning of the term “sensitive payment data” needs to be clarified.
We believe that it will be very important to clarify the meaning of the term “sensitive payment data” as used in Article 22(1)(a) (and elsewhere) to avoid fragmentation and a lack of harmonisation concerning the information to be made available to AISPs.
2) Requirements for Identification:The meaning of Article 17(1) needs to be clarified
We are not clear from reading this article which parties are intended to be bilaterally identified, and to who. If this is intended to refer to the general principle that all parties involved in a transaction need to be identified then it would seem that this article should be expanded to include other aspects of payment services, account information services and confirmation of availability of funds, not just payment initiation.
Question 8: In particular, do you agree that the use of ISO 20022 elements, components or approved message definitions, if available, should be required to ensure the interoperability of different technological communication solutions implemented between PSPs for the provision of AIS, PIS or for the confirmation on the availability of funds? Do you see any particular technical constraint that would prevent the use of such industry standards?
We support the principle of using the ISO 20022 data dictionary as a way of helping to ensure the necessary level of standardisation and hence interoperability between different implementations and communication interfaces in the interests of an efficient pan-EU market environment for AIS and PIS services. The ISO 20022 data dictionary is fairly well developed in the payments space, but additional work is likely to be needed, not least to develop ISO 20022 terms to support AIS. There is also a need to ensure that an agreed ISO 20022-based approach is flexible enough to support different implementations and communication interfaces, such as in API-based implementations where compatibility with approaches based on SOAP and JSON would be important.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 ?
Whilst e-IDAS might be one potential way of achieving the objective, we would note that there would be risks involved if the RTS were to go as far as mandating this specific approach given that e-IDAS solutions have yet to be implemented. Also it is not clear at this point whether e-IDAS would be a cost effective solution. Therefore it would seem more logical for the RTS to take a technology neutral stance on this issue, at least at this point in time.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.
We feel that it would be appropriate to set such a frequency limit, but we are not sure that the proposed limitation of 2 times a day for AISP access would be high enough in the context of aspirations to provide near real-time account transaction updates via AISP solutions.This feels like a topic where further discussion will be necessary to find the right balance –given also the need to reflect the potential complexity on all sides of implementing such a frequency limit.