Response to consultation on RTS specifying the requirements on strong customer authentication and common and secure communication under PSD2
Go back
We understand and support the conclusion that risk measurements are part of the SCA procedure.
PROBLEM: We argue that the current proposed article to prevent, detect and block fraudulent payments hampers innovation and does not cater for future possibilities since it is too prescriptive and does not cater for a targeted approach of fraud prevention methods.
PROPOSAL: “These mechanisms may take into account:...”
2. AUTHENTICATION VERSUS AUTHORIZATION:
PROBLEM: There is no clear differentiation between authentication and authorization in the RTS implying confusion and uncertainty.
PROPOSAL: Include distinction between authentication and authorization
3. CONSENT MANAGEMENT:
PROBLEM: There may be conflicts between the consents given by the PSU to his ASPSP, as account keeper (as mentioned in the rationale 3b), and to a PISP/AISP. It is particularly essential in the context of exception to the SCA.
Example: the PSU has withdrawn a given consent and communicated this to his ASPSP without informing the PISP.
PROPOSAL: The consent given to the ASPSP must prevail to avoid any conflict between the instructions given by the PSU to his ASPSP and to a PISP/AISP.
4. RATIONALE 19.A) “The only situation when the transaction would be authenticated within the sphere of competence of the PISP is when a PISP issues its own personalised security credentials for the user, in place of the credentials issued by the ASPSP. This would however require a prior contractual agreement between the PIS and the ASPSP on the acceptance of such credentials by ASPSP.”
PROBLEM: If this requirement remains not specified explicitly then there would be no enforcement of this prior contractual agreement.
PROPOSAL: We suggest including Rationale 19.a) in a specific article in the RTS.
5. ARTICLE 6.3: “For the purposes of paragraph 2, the mitigating measures shall include, … the implementation of separated trusted execution environments inside the multipurpose device; …”
PROBLEM: We consider that it is better to list some examples that may be used, instead of the mechanism that shall be used. The term Trusted Execution Environment is a (too) specific defined term in the Global Platform standard.
PROPOSAL: “For the purposes of paragraph 2, the mitigating measures may include, … the implementation of secure environments inside the multipurpose device; …”
PROBLEM: There are however many alternative mechanisms available to ensure the confidentiality, authenticity and integrity of the information displayed to the payer. We believe that such mechanisms are equally effective as your proposal as laid down in article 2.2.(b) in creating an adequately secured and protected environment to display the amount and the account number of the payee, and assuring the integrity of this data towards the PSU and the ASPSP.
These mechanisms could include, but are not limited to:
• Secure Element (SIM or dedicated chip) for storage of sensitive data, accessible only by PSU and authorized app
• App-separation / sandboxing
• Remote security updates, to prevent or react on possible weaknesses
• Hardening of an app / secure coding
• White-box cryptography
• Device binding (secure activation of an app for use by only one PSU on only one device), based on continually refreshed data elements or challenge/response
• Detection of mobile malware and fraud on the device
• App-store monitoring (for malicious apps)
It is very important that the Regulatory Technical Standards are future proof, technologically neutral and principle based. Our suggestion is therefore to leave all technical options open and to not prescribe just one particular mechanism to ensure the confidentiality, authenticity and integrity of the information displayed to the payer.
PROPOSAL: We therefore propose to delete the last sentence of article 2.2(b) in which EBA prescribes that 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.
Proposal as alternative regulatory option: Article 2.2 (b): “the confidentiality, authenticity and integrity of the information displayed to the payer through all phases of the authentication procedure including generation, transmission and use of the authentication code.”
The side effect of this “excessive use of SCA”, next to a negative impact on the user experience, is also a negative impact on the transaction security : the customer does not see SCA as an exception linked to a higher risk transaction deserving his full attention but as a plain annoyance which he performs without giving it a second thought.
Furthermore, the reasoning that such a risk-based approach “reduces predictability for the TPP” is flawed anyways since art 1.3 e mandates a risk scoring post SCA (or exemption) that can result in the transaction being refused.
Innovation and future developments would be blocked
PROPOSAL: We consider that the ASPSP, as account keeper, is the best placed to decide on the need for applying SCA, as it is the case today. Moreover, there would be no discrimination or a different user experience when the PSU accesses directly an ASPSP or indirectly via PISP.
1. PROBLEM for consumer clients: we agree to apply the exemptions integrally to ensure a level playing field. Applying SCA on transactions with high risk is in most of the cases much better than blocking them: it avoids extra traffic of re-initiation of the transaction and is much more customer friendly, while maintaining the high level of security.
PROPOSAL: In case of (a suspicion of) fraud the ASPSP wants to be able to apply SCA.
2. PROBLEM for non-consumer clients: we are of the opinion that applying the exemption mandatorily is not suitable. These clients have implemented authorization matrixes which are integrated in our authorisation procedures/SCA and apply to all of their payments and even to the level of access they have to electronic channels. All put in place with the rationale of enhancing the security and improving the protection against fraud seeing the interests at stake.
PROPOSAL: As a consequence we consider that ASPSPs should have the liberty to apply SCA for non-consumer clients in relation to the payments initiated through or the access granted to electronic payment channels at all times.
3. ARTICLE 8.1.A: We agree that in some rare circumstances SCA is logical and needed once every month.
PROBLEM: From market experience and user data information we however know that the large majority of our customers is checking their account information from the same location and via the same device. We consider that this information provides sufficient safeguards to allow for a period of at least one year without SCA for the consultation of account information from a security perspective.
PROPOSAL as alternative regulatory option:
Article 8.1 (a): “the payer accesses exclusively the information of its payment account online, or the consolidated information on other payment accounts held, without disclosure of sensitive payment data. The application of strong customer authentication shall not be exempted where: i. the payer accesses the information of its payment account online, or the consolidated information on other payment accounts held, for the first time, ii. the payer accesses the information of its payment account online, or the consolidated information on other payment accounts held, later than a period determined by the ASPSP based on a risk assessment.
PROBLEM: In order for this fraud detection to be as efficient as possible, and in order to protect the “level playing field” principle, ASAPS must receive from PISPs transaction and contextual data mentioned in article 1.3.e and also transaction type (P2P, P2M, …) transaction mode (F2F, remote) beneficiary data (merchant name, location, activity… ) and the same contextual data that is available in the ASPSP’s own channels (device type, OS, location, network…). That set of data would allow the ASPSP to score the transaction risk from PISPs with the same level of efficiency as the risk from the ASPSP’s own channels (resulting in the same, as low as possible, rate of transaction rejections).
PROPOSAL: Include the principle of this information exchange in article 19.2.a
2. ARTICLE 19.3: “Account servicing payment service providers shall ensure that their communication interface uses ISO 20022 elements, components or approved message definitions…”
We agree that standardisation is highly needed to ensure interoperability.
PROBLEM: Several standards are available in the market and/or will be developed which can be used in the communication between PSPs.
PROPOSAL: We therefore propose that the RTS remains neutral in prescribing industry standards with one clear exemption: the usage of ISO 20022 data definitions should be the basis. ISO20022 is the only industry standard data definition for payments and can be used in all kind of standard message definitions.
Proposal as alternative regulatory option:
Article 19.3: “Account servicing payment service providers shall ensure that their communication interface uses ISO 20022 data definitions, if available ...”
PROBLEM: As mentioned in rationale 77 we have to assume that there will be qualified trust service providers designated under eIDAS by October 2018. Febelfin assumes that identification also entails the authentication.
PROPOSAL: The concerned authorities (EBA, ECB and EC) and ENISA should follow-up the designation of qualified trust service providers under e-IDAS and make sure that there is at least one/two e-IDAS qualified trust service providers at least 6 months before the entry into force of this RTS.
Proposal as alternative regulatory option:
Article 20.1 : “For the purpose of identification/ authentication, payment service providers shall rely on Qualified certificates for website authentication as per article 3(39) of Regulation (EU) No 910/2014.”
PROBLEM: EBA should also take into account that problems with the communication interface is not only related to the times the AISP requests information of the customer, but also to the amount of information/data that could be processed in a single request and the number of requests in a certain time window (possibly from different AISPs).
PROPOSAL: “Account information service provider shall request information from designated payment accounts and associated payment transactions of the previous day and only once the same information: … ”
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?
1. ARTICLE 1.3(E): “...prevent, detect and block fraudulent payment transactions before the PSP’s final authorisation. These mechanisms shall take into account, …”We understand and support the conclusion that risk measurements are part of the SCA procedure.
PROBLEM: We argue that the current proposed article to prevent, detect and block fraudulent payments hampers innovation and does not cater for future possibilities since it is too prescriptive and does not cater for a targeted approach of fraud prevention methods.
PROPOSAL: “These mechanisms may take into account:...”
2. AUTHENTICATION VERSUS AUTHORIZATION:
PROBLEM: There is no clear differentiation between authentication and authorization in the RTS implying confusion and uncertainty.
PROPOSAL: Include distinction between authentication and authorization
3. CONSENT MANAGEMENT:
PROBLEM: There may be conflicts between the consents given by the PSU to his ASPSP, as account keeper (as mentioned in the rationale 3b), and to a PISP/AISP. It is particularly essential in the context of exception to the SCA.
Example: the PSU has withdrawn a given consent and communicated this to his ASPSP without informing the PISP.
PROPOSAL: The consent given to the ASPSP must prevail to avoid any conflict between the instructions given by the PSU to his ASPSP and to a PISP/AISP.
4. RATIONALE 19.A) “The only situation when the transaction would be authenticated within the sphere of competence of the PISP is when a PISP issues its own personalised security credentials for the user, in place of the credentials issued by the ASPSP. This would however require a prior contractual agreement between the PIS and the ASPSP on the acceptance of such credentials by ASPSP.”
PROBLEM: If this requirement remains not specified explicitly then there would be no enforcement of this prior contractual agreement.
PROPOSAL: We suggest including Rationale 19.a) in a specific article in the RTS.
5. ARTICLE 6.3: “For the purposes of paragraph 2, the mitigating measures shall include, … the implementation of separated trusted execution environments inside the multipurpose device; …”
PROBLEM: We consider that it is better to list some examples that may be used, instead of the mechanism that shall be used. The term Trusted Execution Environment is a (too) specific defined term in the Global Platform standard.
PROPOSAL: “For the purposes of paragraph 2, the mitigating measures may include, … the implementation of secure environments inside the multipurpose device; …”
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.
ARTICLE 2.2.B: We understood that Article 2.2 has to be read in the spirit of wanting to prevent man-in-the-middle attacks. The goal is to come to a model in which fraudulent activity is prevented by making sure that a breach during the initiation does not lead to a breach during the authorization.PROBLEM: There are however many alternative mechanisms available to ensure the confidentiality, authenticity and integrity of the information displayed to the payer. We believe that such mechanisms are equally effective as your proposal as laid down in article 2.2.(b) in creating an adequately secured and protected environment to display the amount and the account number of the payee, and assuring the integrity of this data towards the PSU and the ASPSP.
These mechanisms could include, but are not limited to:
• Secure Element (SIM or dedicated chip) for storage of sensitive data, accessible only by PSU and authorized app
• App-separation / sandboxing
• Remote security updates, to prevent or react on possible weaknesses
• Hardening of an app / secure coding
• White-box cryptography
• Device binding (secure activation of an app for use by only one PSU on only one device), based on continually refreshed data elements or challenge/response
• Detection of mobile malware and fraud on the device
• App-store monitoring (for malicious apps)
It is very important that the Regulatory Technical Standards are future proof, technologically neutral and principle based. Our suggestion is therefore to leave all technical options open and to not prescribe just one particular mechanism to ensure the confidentiality, authenticity and integrity of the information displayed to the payer.
PROPOSAL: We therefore propose to delete the last sentence of article 2.2(b) in which EBA prescribes that 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.
Proposal as alternative regulatory option: Article 2.2 (b): “the confidentiality, authenticity and integrity of the information displayed to the payer through all phases of the authentication procedure including generation, transmission and use of the authentication code.”
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?
We refer to the answer of the EPC and EBF. We have no additional comment.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?
PROBLEM: Limiting the exemptions to a small number of fixed rules means that a large amount of transactions will be classified as requiring SCA (eg. card transactions with contact without PIN in parkings and tollways, white list of bank for credit transfers to trusted beneficiaries eg. public institutions and utilities…) even though we would have technical means to qualify many of them as low-risk and would be willing to allow them without SCA.The side effect of this “excessive use of SCA”, next to a negative impact on the user experience, is also a negative impact on the transaction security : the customer does not see SCA as an exception linked to a higher risk transaction deserving his full attention but as a plain annoyance which he performs without giving it a second thought.
Furthermore, the reasoning that such a risk-based approach “reduces predictability for the TPP” is flawed anyways since art 1.3 e mandates a risk scoring post SCA (or exemption) that can result in the transaction being refused.
Innovation and future developments would be blocked
PROPOSAL: We consider that the ASPSP, as account keeper, is the best placed to decide on the need for applying SCA, as it is the case today. Moreover, there would be no discrimination or a different user experience when the PSU accesses directly an ASPSP or indirectly via PISP.
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 understand that the application of the exemptions is optional for the ASPSP. The mandatory character would be problematic in following cases:1. PROBLEM for consumer clients: we agree to apply the exemptions integrally to ensure a level playing field. Applying SCA on transactions with high risk is in most of the cases much better than blocking them: it avoids extra traffic of re-initiation of the transaction and is much more customer friendly, while maintaining the high level of security.
PROPOSAL: In case of (a suspicion of) fraud the ASPSP wants to be able to apply SCA.
2. PROBLEM for non-consumer clients: we are of the opinion that applying the exemption mandatorily is not suitable. These clients have implemented authorization matrixes which are integrated in our authorisation procedures/SCA and apply to all of their payments and even to the level of access they have to electronic channels. All put in place with the rationale of enhancing the security and improving the protection against fraud seeing the interests at stake.
PROPOSAL: As a consequence we consider that ASPSPs should have the liberty to apply SCA for non-consumer clients in relation to the payments initiated through or the access granted to electronic payment channels at all times.
3. ARTICLE 8.1.A: We agree that in some rare circumstances SCA is logical and needed once every month.
PROBLEM: From market experience and user data information we however know that the large majority of our customers is checking their account information from the same location and via the same device. We consider that this information provides sufficient safeguards to allow for a period of at least one year without SCA for the consultation of account information from a security perspective.
PROPOSAL as alternative regulatory option:
Article 8.1 (a): “the payer accesses exclusively the information of its payment account online, or the consolidated information on other payment accounts held, without disclosure of sensitive payment data. The application of strong customer authentication shall not be exempted where: i. the payer accesses the information of its payment account online, or the consolidated information on other payment accounts held, for the first time, ii. the payer accesses the information of its payment account online, or the consolidated information on other payment accounts held, later than a period determined by the ASPSP based on a risk assessment.
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?
We refer to the answer of the EPC and EBF. We have no additional comment.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 refer to the answer of the EPC and EBF. We have no additional comment.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?
1. ARTICLE 19.2.A: “the interface shall enable… to start the authentication procedure”PROBLEM: In order for this fraud detection to be as efficient as possible, and in order to protect the “level playing field” principle, ASAPS must receive from PISPs transaction and contextual data mentioned in article 1.3.e and also transaction type (P2P, P2M, …) transaction mode (F2F, remote) beneficiary data (merchant name, location, activity… ) and the same contextual data that is available in the ASPSP’s own channels (device type, OS, location, network…). That set of data would allow the ASPSP to score the transaction risk from PISPs with the same level of efficiency as the risk from the ASPSP’s own channels (resulting in the same, as low as possible, rate of transaction rejections).
PROPOSAL: Include the principle of this information exchange in article 19.2.a
2. ARTICLE 19.3: “Account servicing payment service providers shall ensure that their communication interface uses ISO 20022 elements, components or approved message definitions…”
We agree that standardisation is highly needed to ensure interoperability.
PROBLEM: Several standards are available in the market and/or will be developed which can be used in the communication between PSPs.
PROPOSAL: We therefore propose that the RTS remains neutral in prescribing industry standards with one clear exemption: the usage of ISO 20022 data definitions should be the basis. ISO20022 is the only industry standard data definition for payments and can be used in all kind of standard message definitions.
Proposal as alternative regulatory option:
Article 19.3: “Account servicing payment service providers shall ensure that their communication interface uses ISO 20022 data definitions, if available ...”
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 ?
ARTICLE 20.1: “For the purpose of identification, payment service providers shall rely on Qualified certificates for website authentication as per article 3(39) of Regulation (EU) No 910/2014.”PROBLEM: As mentioned in rationale 77 we have to assume that there will be qualified trust service providers designated under eIDAS by October 2018. Febelfin assumes that identification also entails the authentication.
PROPOSAL: The concerned authorities (EBA, ECB and EC) and ENISA should follow-up the designation of qualified trust service providers under e-IDAS and make sure that there is at least one/two e-IDAS qualified trust service providers at least 6 months before the entry into force of this RTS.
Proposal as alternative regulatory option:
Article 20.1 : “For the purpose of identification/ authentication, payment service providers shall rely on Qualified certificates for website authentication as per article 3(39) of Regulation (EU) No 910/2014.”
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.
ART.22.5.(A): “Account information service provider shall request information from designated payment accounts and associated payment transactions:…”PROBLEM: EBA should also take into account that problems with the communication interface is not only related to the times the AISP requests information of the customer, but also to the amount of information/data that could be processed in a single request and the number of requests in a certain time window (possibly from different AISPs).
PROPOSAL: “Account information service provider shall request information from designated payment accounts and associated payment transactions of the previous day and only once the same information: … ”