Response to discussion on RTS on strong customer authentication and secure communication under PSD2
Go back
As ASPSPs are responsible for the protection of PSU’s funds and for the correct execution of PSU’s payment transactions: SCA should always be performed by ASPSPs.
Customer authentication should be based on multiple tools defined by transactional contexts and customer behaviour. For instance, authentication for account consulting should not be the same if initiated from home by the user or from an internet coffee in another country.
The examples of actions carried out via a remote channel that may imply a risk of payment fraud or other abuses that are listed in the paragraph 27.iii of the discussion paper are clear enough and bring sufficient detail to understand the issue of article 97 (1) (c) of PSD2.
About the reference to the remote channel, we understand that it concerns only actions being conducted via the internet or through a device that can be used for distant communication: RTS should then refer to electronic remote channel only, excluding for instance mail, fax channels.
Furthermore, if the element of ownership only had to be a physical form, it would lead to have all PSUs equipped: management of tokens or keys means issues to deal with in terms of stocks of piles for calculators for example or quick replacement in case of loss or theft.
The border between the physical support and the immaterial form is blurring: the real matter is to ensure the exclusive control by the PSU of its possession element. There should be an evaluation of the solution level of security to make sure that the container is secured.
Via a softToken (application downloaded into the device), the PSU will always have a device or a media, that is a physical support in the hands, which has been previously enrolled by its AS PSP: the issue relies on the quality and the efficiency of the enrolment of the device by the AS PSP.
Enrolment of the PSU’s device by the AS PSP with the supply of a key linked to that device could be considered, provided that it can be controlled by the AS PSP (when processing the enrollment and regarding the integrity of the device). The PSU, in case of a payment transaction that requires SCA, validates the elements of the transaction in addition to the entry of the credential sent.
Concerning Out Of Band solution, the possession element is a software certificate downloaded into the smartphone of the PSU.
The most important part is that there should be an evaluation to ensure a level of confidence in the overall system. This evaluation should be performed by an independent body and state of the art standards should be referred to.
It is clear that for a better customer experience, within the coming years, biometric characteristics will be increasingly used. In the context of SCA, biometric characteristics match the definition of strong inherence element.
Referring to paragraph 32, Out Of Band solution is considered as a secured and valid solution for SCA and is currently applied in our banking group. The Out Of Band authentication is a double factor authentication similar to the OTP SMS authentication. Via a first channel, the aim is to check “what I know” (my pin code) and then via a second channel “what I own” (my mobile phone). The PSU has to register the “fingerprint” of his/her smartphone (hash) with the bank first and he has to know his/her pin code. The Out Of Band authentication allows the AS PSP to verify the mobile phone possession before each sensitive operation.
It is difficult to ensure a complete 100% independence of the two authentication elements used for SCA with for instance a known case of Trojan horse on smartphones which had impact on payment transactions and captured SMS code (both applications were hacked).
A prior enrollment of the PSU’s devices shall be processed when he/she enters in relation with its AS PSP; the quality of this enrollment being a key point to give the AS PSP the ability to link securely and efficiently the elements allowing to process a strong customer authentication.
Moreover, the AS PSP will have to deal with this issue of independence of the authentication elements on a mobile device and implement adequate fraud management. This fraud management will require detailed information on associated payment data, the device and the use case.
It should be noted that currently when transmitting payment orders by files, corporates are not asked to validate each transaction but their file of payment transactions. Therefore, in such case, dynamic linking should only be done with the file.
It should be noticed that even with dynamic linking, the man in the middle fraud still exists.
It should be noticed that when SCA is not required, authentication based on the PSU’s device (for example with the key provided by the ASPSP for the enrolment) and on behaviour-based characteristics could be done in some cases.
Access to services should be based on a multi-level authentication which level is defined by transactional contexts and customer behaviour. For instance, authentication for account consulting could not be the same if initiated from home by the user or from an internet coffee in another country.
Account number and name of the PSU are considered in PSD2 as non-sensitive data for AIS and PIS under article (4) (32). Thus, for level playing field, these data should also be considered as non-sensitive for ASPSPs.
Clarifications would also be very useful:
- referring to the exemption in 42.A. on the amount of low-value payments
- referring to the exemption in paragraph 42.E. on sensitive payment data (what about the sensibility of the beneficiary’s account number?)
- referring to the exemption in 42.E. on the definition of “purely consultative services” with some use cases for instance. In our understanding, the definition of “purely consultative services” applies only for direct access by PSUs.
In case of PIS or AIS, which transactions may benefit from exemptions listed in the paragraph 42 ? In case of a direct relation between the ASPSP and the PSU, the ASPSP is allowed to apply a simple authentication - exemption to SCA- for transactions with amount below €20 (example of NFC payments). The ASPSP then bears the associated risk. If the TPP was to apply SCA exemption, the TPP should bear the associated risk in case of fraud.
Should such exemptions to SCA be mandatory, and without direct link between the PSU’s device and the ASPSP in case of PIS, then the ASPSP has no means to perform its risk analysis and comply with authentication. As a result, a liability shift should happen from the ASPSP to the TPP as it currently happens in the cards payments framework if the payee’s PSP refuses the strong customer authentication.
We are concerned about the fact that ASPSPs might face the risk of massive claims about unauthorized operations. Such number may increase regarding exemptions application that could attract fraudsters’ interest. Requirements in terms of industrial management of customers’ claims should be addressed particularly in case of PIS as ASPSPs and PISPs do not have any contractual relationship. Without such framework, numerous legal actions will happen and generate additional costs (exceptional handling, insurance, communication).
It is important to anticipate and define an agile way of reviewing the RTS especially about exemptions to SCA. Some exemptions detailed in the RTS may attract fraudsters interested in data theft or fraudulent payments. ASPSPs have systems and solutions that help for monitoring fraud attempts. Such agile mechanism for reviewing RTS on exemptions to SCA should be addressed provided that ASPSPS are free to stop any access or block any service in case of fraud attack.
There is no need for TPPs to get the PSU’s personalised security credentials: this goes against what ASPSPs have worked for during last decades. Each credential is personal and private and should not be shared with anybody or any third party. The PSU should not be allowed to transmit his PSCs to anyone.
- Revocation and destruction of data
- Revocation of credentials
We are facing a situation where the number of actors implied in the payment segment chain may increase quickly. Evidence and end-to-end traceability are essential to offer safe and secure payment services to PSUs with clear rights and obligations between all parties.
We question how the PSU can be certain that the TPP is authorized and is the one it pretends to be?
Besides face-to-face done at the branch office, solutions to be considered for securing the enrolment and the credentials’ delivery will include tomorrow innovative process like face-to-face with video as some solutions are currently being audited for secure qualification.
OAuth 2.0 is an example of open standard that could be used when processing the enrolment.
The growing number of actors between the ASPSP and the PSU, by adding new segments in the payment chain, actually increases the risk of fraud and may weaken the chain.
Moreover, a higher number of actors in the payment chain also increases the risk of phishing.
Evidence and end-to-end traceability are definitely essential issues to mitigate risks over the payment chain.
Moreover, besides the scope and content of these future Regulatory Technical Standards, having a whole framework describing rules and responsibilities of different actors is necessary as it would bring trust and confidence for PSUs, PSPs, and TPPs.
These RTS are paramount to the harmonisation of the market at pan-European level and should ensure a level playing field among all actors.
When defining RTS, we believe that a focus should be made on traceability on ASPSPs and TPPs flows in order to enable fraud prevention and liability shift.
About topic b) - the way TPPs identify themselves towards the ASPSPs: To address this issue, there is a need for a European body which would maintain an updated list of authorized TPPs and would issue associated certificates (PKI concept). This body should operate a Trusted Service List at the European level or centralize Trusted Service Lists operated in each member state.
About topic d) - The minimum functionalities requirements:
Comments on this topic is rather difficult at this stage, we would have wished to be able to further comment on this topic, the lack of clear picture at this stage of RTS details, use cases and customer experience with AIS or PIS was a restraint.
About topic f) - The minimum technical requirements:
Without any contract or scheme management, there could not be any SLA required by EBA. TPP will benefit from the same level of service as PSUs, ASPSP should expect the same behavior from a PSU or a TPP, which refers to the ‘’user thinking time’’, and avoid any batch or robot process .To ensure a better service to the end-users, we recommend that EBA defines exchange limits in terms of volumetric to prevent the risk of denial of service and potentially any discrimination. Such requirements are defined on existing infrastructures (i.e. STET). In France some ASPSPs’ online banking services already went down due to peaks of TPPs requests.
It is important to use open standards that are regularly certified by Third Parties and subject to audits.
e-IDAS regulation could be then a facilitator or an opportunity. In France, today, we do not have any national e-id mean, therefore e-IDAS may not be a short term solution but it could be a facilitating solution in the coming years.
Besides, regarding certificates, all authentication solutions should not be certified as e-IDAS qualified, as it may not fit the need of security of AS PSPS’s services (a lighter method for authentication could be appropriate and then chosen by the ASPSP).
1. With respect to Article 97(1) (c), are there any additional examples of transactions or actions implying a risk of payment fraud or other abuses that would need to be considered for the RTS? If so, please give details and explain the risks involved.
We welcome the fact that Payment Services Directive (PSD2) includes SCA as this will lead to strengthen the overall security of payments in Europe. SCA applied by PSP is mandatory when the payer accesses his payment account on-line or initiates an electronic payment transaction or carries out any action, through a remote channel, which may imply a risk of payment fraud or other abuses.As ASPSPs are responsible for the protection of PSU’s funds and for the correct execution of PSU’s payment transactions: SCA should always be performed by ASPSPs.
Customer authentication should be based on multiple tools defined by transactional contexts and customer behaviour. For instance, authentication for account consulting should not be the same if initiated from home by the user or from an internet coffee in another country.
The examples of actions carried out via a remote channel that may imply a risk of payment fraud or other abuses that are listed in the paragraph 27.iii of the discussion paper are clear enough and bring sufficient detail to understand the issue of article 97 (1) (c) of PSD2.
About the reference to the remote channel, we understand that it concerns only actions being conducted via the internet or through a device that can be used for distant communication: RTS should then refer to electronic remote channel only, excluding for instance mail, fax channels.
2. Which examples of possession elements do you consider as appropriate to be used in the context of strong customer authentication, must these have a physical form or can they be data? If so, can you provide details on how it can be ensured that these data can only be controlled by the PSU?
In tomorrow’s digital world, part of the data will be in the cloud. Therefore, having only a physical support as element of possession is unrealistic. Both physical form and data are to be considered as possession element for SCA.Furthermore, if the element of ownership only had to be a physical form, it would lead to have all PSUs equipped: management of tokens or keys means issues to deal with in terms of stocks of piles for calculators for example or quick replacement in case of loss or theft.
The border between the physical support and the immaterial form is blurring: the real matter is to ensure the exclusive control by the PSU of its possession element. There should be an evaluation of the solution level of security to make sure that the container is secured.
Via a softToken (application downloaded into the device), the PSU will always have a device or a media, that is a physical support in the hands, which has been previously enrolled by its AS PSP: the issue relies on the quality and the efficiency of the enrolment of the device by the AS PSP.
Enrolment of the PSU’s device by the AS PSP with the supply of a key linked to that device could be considered, provided that it can be controlled by the AS PSP (when processing the enrollment and regarding the integrity of the device). The PSU, in case of a payment transaction that requires SCA, validates the elements of the transaction in addition to the entry of the credential sent.
Concerning Out Of Band solution, the possession element is a software certificate downloaded into the smartphone of the PSU.
3. Do you consider that in the context of “inherence” elements, behaviour-based characteristics are appropriate to be used in the context of strong customer authentication? If so, can you specify under which conditions?
Behaviour-based characteristics may help to fight against fraud and may be part of the inherence element. Nonetheless, they cannot be a full substitute to SCA.The most important part is that there should be an evaluation to ensure a level of confidence in the overall system. This evaluation should be performed by an independent body and state of the art standards should be referred to.
It is clear that for a better customer experience, within the coming years, biometric characteristics will be increasingly used. In the context of SCA, biometric characteristics match the definition of strong inherence element.
4. Which challenges do you identify for fulfilling the objectives of strong customer authentication with respect to the independence of the authentication elements used (e.g. for mobile devices)?
We believe that tomorrow use cases in the digital world will not imply 2 different devices. Consumers are keen on easy and quick payment solutions.Referring to paragraph 32, Out Of Band solution is considered as a secured and valid solution for SCA and is currently applied in our banking group. The Out Of Band authentication is a double factor authentication similar to the OTP SMS authentication. Via a first channel, the aim is to check “what I know” (my pin code) and then via a second channel “what I own” (my mobile phone). The PSU has to register the “fingerprint” of his/her smartphone (hash) with the bank first and he has to know his/her pin code. The Out Of Band authentication allows the AS PSP to verify the mobile phone possession before each sensitive operation.
It is difficult to ensure a complete 100% independence of the two authentication elements used for SCA with for instance a known case of Trojan horse on smartphones which had impact on payment transactions and captured SMS code (both applications were hacked).
A prior enrollment of the PSU’s devices shall be processed when he/she enters in relation with its AS PSP; the quality of this enrollment being a key point to give the AS PSP the ability to link securely and efficiently the elements allowing to process a strong customer authentication.
Moreover, the AS PSP will have to deal with this issue of independence of the authentication elements on a mobile device and implement adequate fraud management. This fraud management will require detailed information on associated payment data, the device and the use case.
5. Which challenges do you identify for fulfilling the objectives of strong customer authentication with respect to dynamic linking?
With the development of electronic payments and data to be managed in the cloud, PSPs should try to duplicate the principles used in the area of proximity payments like for card payments i.e. ensuring the link between the payment transaction and the PSU. The PSU should always be aware of what he/she is doing and then especially about the amount of the transaction and the name of the beneficiary (principle of what you see is what you sign). This link may be processed with different solutions.It should be noted that currently when transmitting payment orders by files, corporates are not asked to validate each transaction but their file of payment transactions. Therefore, in such case, dynamic linking should only be done with the file.
It should be noticed that even with dynamic linking, the man in the middle fraud still exists.
6. In your view, which solutions for mobile devices fulfil both the objective of independence and dynamic linking already today?
SCA processed via Out Of Band solution fulfil both objective of independence and dynamic linking.7. Do you consider the clarifications suggested regarding the potential exemptions to strong customer authentication, to be useful?
Clarifications suggested in paragraph 42 will be very useful.It should be noticed that when SCA is not required, authentication based on the PSU’s device (for example with the key provided by the ASPSP for the enrolment) and on behaviour-based characteristics could be done in some cases.
Access to services should be based on a multi-level authentication which level is defined by transactional contexts and customer behaviour. For instance, authentication for account consulting could not be the same if initiated from home by the user or from an internet coffee in another country.
Account number and name of the PSU are considered in PSD2 as non-sensitive data for AIS and PIS under article (4) (32). Thus, for level playing field, these data should also be considered as non-sensitive for ASPSPs.
Clarifications would also be very useful:
- referring to the exemption in 42.A. on the amount of low-value payments
- referring to the exemption in paragraph 42.E. on sensitive payment data (what about the sensibility of the beneficiary’s account number?)
- referring to the exemption in 42.E. on the definition of “purely consultative services” with some use cases for instance. In our understanding, the definition of “purely consultative services” applies only for direct access by PSUs.
In case of PIS or AIS, which transactions may benefit from exemptions listed in the paragraph 42 ? In case of a direct relation between the ASPSP and the PSU, the ASPSP is allowed to apply a simple authentication - exemption to SCA- for transactions with amount below €20 (example of NFC payments). The ASPSP then bears the associated risk. If the TPP was to apply SCA exemption, the TPP should bear the associated risk in case of fraud.
Should such exemptions to SCA be mandatory, and without direct link between the PSU’s device and the ASPSP in case of PIS, then the ASPSP has no means to perform its risk analysis and comply with authentication. As a result, a liability shift should happen from the ASPSP to the TPP as it currently happens in the cards payments framework if the payee’s PSP refuses the strong customer authentication.
We are concerned about the fact that ASPSPs might face the risk of massive claims about unauthorized operations. Such number may increase regarding exemptions application that could attract fraudsters’ interest. Requirements in terms of industrial management of customers’ claims should be addressed particularly in case of PIS as ASPSPs and PISPs do not have any contractual relationship. Without such framework, numerous legal actions will happen and generate additional costs (exceptional handling, insurance, communication).
8. Are there any other factors the EBA should consider when deciding on the exemptions applicable to the forthcoming regulatory technical standards?
There is today no other factor except the fact that all actors should be considered in the same way to ensure a level playing field (same rules for all).It is important to anticipate and define an agile way of reviewing the RTS especially about exemptions to SCA. Some exemptions detailed in the RTS may attract fraudsters interested in data theft or fraudulent payments. ASPSPs have systems and solutions that help for monitoring fraud attempts. Such agile mechanism for reviewing RTS on exemptions to SCA should be addressed provided that ASPSPS are free to stop any access or block any service in case of fraud attack.
9. Are there any other criteria or circumstances which the EBA should consider with respect to transaction risks analysis as a complement or alternative to the criteria identified in paragraph 45?
Other criteria should be added to the ones listed in paragraph 45. such as PSU’s device jailbreak/rootable.10. Do you consider the clarification suggested regarding the protection of users personalised security credentials to be useful?
Revocation of PSCs at the PSU’s request or at the initiative of the PSP should be added to the paragraph 52.i.Some actions done by the PSU on his/her device like rootage or jailbreak of iOS induce that SCA solution might not be considered as sufficiently secured. In such case, it should be allowed to upgrade the level of authentication with an analysis of other characteristics.There is no need for TPPs to get the PSU’s personalised security credentials: this goes against what ASPSPs have worked for during last decades. Each credential is personal and private and should not be shared with anybody or any third party. The PSU should not be allowed to transmit his PSCs to anyone.
11. What other risks with regard to the protection of users’ personalised security credentials do you identify?
We identify the following items:- Revocation and destruction of data
- Revocation of credentials
We are facing a situation where the number of actors implied in the payment segment chain may increase quickly. Evidence and end-to-end traceability are essential to offer safe and secure payment services to PSUs with clear rights and obligations between all parties.
We question how the PSU can be certain that the TPP is authorized and is the one it pretends to be?
12. Have you identified innovative solutions for the enrolment process that the EBA should consider which guarantee the confidentiality, integrity and secure transmission (e.g. physical or electronic delivery) of the users’ personalised security credentials?
Key questions remain the same: What does the enrolment process encompass? What are the actors involved, are we talking about PSU to ASPSP enrolment or TPP to ASPSP enrolment?Besides face-to-face done at the branch office, solutions to be considered for securing the enrolment and the credentials’ delivery will include tomorrow innovative process like face-to-face with video as some solutions are currently being audited for secure qualification.
OAuth 2.0 is an example of open standard that could be used when processing the enrolment.
13. Can you identify alternatives to certification or evaluation by third parties of technical components or devices hosting payment solutions, to ensure that communication channels and technical components hosting, providing access to or transmitting the personalised security credential are sufficiently resistant to tampering and unauthorized access?
No, certification or evaluation by third parties of component payment solutions or mobile devices is necessary.14. Can you indicate the segment of the payment chain in which risks to the confidentiality, integrity of users’ personalised security credentials are most likely to occur at present and in the foreseeable future?
Such risks are present over all segments of the payment chain from enrolment to consent to execute a payment.The growing number of actors between the ASPSP and the PSU, by adding new segments in the payment chain, actually increases the risk of fraud and may weaken the chain.
Moreover, a higher number of actors in the payment chain also increases the risk of phishing.
Evidence and end-to-end traceability are definitely essential issues to mitigate risks over the payment chain.
15. For each of the topics identified under paragraph 63 above (a to f), do you consider the clarifications provided to be comprehensive and suitable? If not, why not?
The list of topics under paragraph 63 seems appropriate. Nonetheless, as regards to the future Regulatory Technical Standards, the definition of the good and appropriate level of detail is a key point. Indeed, the future Regulatory Technical Standards should not be too precise for safety reasons i.e. not having the same solution implemented by all PSPs that could attract fraudster’s interest and for not slowing down innovation, nor too vague in order to allow effective implementation by PSPs of compliant solutions.Moreover, besides the scope and content of these future Regulatory Technical Standards, having a whole framework describing rules and responsibilities of different actors is necessary as it would bring trust and confidence for PSUs, PSPs, and TPPs.
These RTS are paramount to the harmonisation of the market at pan-European level and should ensure a level playing field among all actors.
When defining RTS, we believe that a focus should be made on traceability on ASPSPs and TPPs flows in order to enable fraud prevention and liability shift.
About topic b) - the way TPPs identify themselves towards the ASPSPs: To address this issue, there is a need for a European body which would maintain an updated list of authorized TPPs and would issue associated certificates (PKI concept). This body should operate a Trusted Service List at the European level or centralize Trusted Service Lists operated in each member state.
About topic d) - The minimum functionalities requirements:
Comments on this topic is rather difficult at this stage, we would have wished to be able to further comment on this topic, the lack of clear picture at this stage of RTS details, use cases and customer experience with AIS or PIS was a restraint.
About topic f) - The minimum technical requirements:
Without any contract or scheme management, there could not be any SLA required by EBA. TPP will benefit from the same level of service as PSUs, ASPSP should expect the same behavior from a PSU or a TPP, which refers to the ‘’user thinking time’’, and avoid any batch or robot process .To ensure a better service to the end-users, we recommend that EBA defines exchange limits in terms of volumetric to prevent the risk of denial of service and potentially any discrimination. Such requirements are defined on existing infrastructures (i.e. STET). In France some ASPSPs’ online banking services already went down due to peaks of TPPs requests.
16. For each agreed clarification suggested above on which you agree, what should they contain in your view in order to achieve an appropriate balance between harmonisation, innovation while preventing too divergent practical implementations by ASPSPs of the future requirements?
Some type of framework is expected to ensure a secure way for all parties to communicate and exchange and to allow a harmonized implementation of PSD2.17. In your opinion, is there any standards (existing or in development) outlining aspects that could be common and open, which would be especially suitable for the purpose of ensuring secure communications as well as for the appropriate identification of PSPs taking into consideration the privacy dimension?
Open standards currently exist like those based on API concept.It is important to use open standards that are regularly certified by Third Parties and subject to audits.
18. How would these requirement for common and open standards need to be designed and maintained to ensure that these are able to securely integrate other innovative business models than the one explicitly mentioned under article 66 and 67 (e.g. issuing of own credentials by the AIS/PIS)?
These requirements should ensure that all parties refer to common and open standards allowing innovations’ integration. As stated at the question 17, there is a need for using open standards that are regularly certified by Third Parties and subject to audits.19. Do you agree that the e-IDAS regulation could be considered as a possible solution for facilitating the strong customer authentication, protecting the confidentiality and the integrity of the payment service users’ personalised security credentials as well as for common and secure open standards of communication for the purpose of identification, DP on future RTS on strong customer and secure communication under PSD2 31 authentication, notification, and information? If yes, please explain how. If no, please explain why.
e-IDAS regulation could be considered as a solution with the substantial level for authentication issue.e-IDAS regulation could be then a facilitator or an opportunity. In France, today, we do not have any national e-id mean, therefore e-IDAS may not be a short term solution but it could be a facilitating solution in the coming years.
20. Do you think in particular that the use of “qualified trust services” under e-IDAS regulation could address the risks related to the confidentiality, integrity and availability of PSCs between AIS, PIS providers and ASPSPs? If yes, please identify which services and explain how. If no, please explain why.
e-IDAS regulation does not foresee the transmission of credentials via third parties.Besides, regarding certificates, all authentication solutions should not be certified as e-IDAS qualified, as it may not fit the need of security of AS PSPS’s services (a lighter method for authentication could be appropriate and then chosen by the ASPSP).