Response to discussion on RTS on strong customer authentication and secure communication under PSD2
Go back
Therefore, e-commerce/online card payments should also be considered as an additional example to be subject to SCA as they are considered risky transactions. In terms of actions implying risk, we are of the view that the editing (update) of personal data, as physical and digital addresses such as phone number, e-mail address, and customer’s personal data should be subject to SCA. The rationale behind this is that information can be used by the fraudster for theft identity purposes.
Another consideration is the use of Strong Customer Authentication at “Login” phase. If strong customer authentication would be required for the display of sensitive payment data (i.e. personal e-mail or mobile number), then SCA in login phase (access the online account) should not be necessary.
In addition, another action zone that implies risk is “pre-login”, which is the webpage that takes the customer to his online home baking login’s page. The pre-login webpage -usually a public https page- may be a vehicle of malware action.
In the context of strong customer authentication, the authentication element of “possession” could be either in a physical form (i.e. customer’s mobile device as smartphone, OTP generator (token) or the possession of a data linked to a device (app/software security library).
For example, if in a simple data form (as a username or a static password), the category matches the ‘knowledge’.
Moreover, data (i.e. payee, amount) can be linked to a possession element (device, OTP generator, software library) to create a unique OTP (possession + knowledge).
Although still in its infancy, there are some new developments that could provide some behaviour-based characteristics, such as the interaction of the user through the device/keyboard, or the use of the smartphone which could be considered in the context of ‘inherence’.
Other customer behaviour-based characteristics (i.e. geographic area, device fingerprint, IP address, operative system used, etc) are important key factors that could be used as additional controls or as an element(s) to be considered within the list of exemptions. However these should not be considered as an alternative to biometric authentication.
The elements used in “authentication phase” should be different from the elements used in “authorization phase”.
For the list of payments or “bulk orders” dynamic elements linking the payee and the amount of the transaction could be an algorithm considering all the payments, or a random selection of one among the list of payments.
Regarding point “D” on low-risk transactions based on transaction risk analysis, criteria based on customer behaviour could be taken into account.
An efficient fraud risk engine - besides switching low risk transactions to the list of exemptions, scoring the risk for raising alerts and additional controls and other related actions within the payment antifraud engine -could also be extended to help the business sharing the user experience and thus creating best practices for other activities.
We are of the view that user’s personalized security credentials must be properly treated, in particular when the user selects a third party provider. Also, in this case it is very important that the Payment Service Providers (as owner of the user’s credential) should be alerted and warned on real time.
Protection of credentials is also important on e-IDAS perspective which would allow the use of the same credentials either for online payment services or for e-identity purposes.
In addition, we would recommend the EBA to clearly specify the list of “sensitive payment data”.
Another critical phase is when data is accessed by a third party payment service. (TPP).
• Regarding point A, in our view standard “common” and “open” definitions, should not be defined from scratch. Definitions could be stated using international standards already consolidated.
• Regarding point B, RTS should clarify which existing methods for identification of entities could be used (e.g., certificates issued from a Certification Authority) in order to avoid an additional burden on future implementation.
• Regarding point C, RTS should specify or suggest a list of secure (by design) encryption algorithms and a list of secure communication protocols.
• Regarding point D, RTS should definitely include a specific list of which the available services (split for AIS and PIS) should be (not only as examples)
• Regarding point E, RTS should include details on when, how and who can access operation/transaction data to perform the security control, in order to ensure privacy of the payment service user (PSU) and avoid internal threat. Moreover, existing international standard frameworks should be leveraged as far as possible.
• Regarding point F, RTS should include requirements to evaluate the adoption of a communication middle-layer technology that may ease the interoperability between existing systems while reducing efforts for implementation.
This body could also organize scheduled workshop initiatives, with round tables, propose/discuss changes on requirements to enhance them or to ensure that they can integrate new business models. The round table should be composed by market players, ISPs (internet service providers), big IT players (i.e. well-consolidated leading vendors of IT solutions, vendors of IT products and solutions) and Universities.
In the case that AIS and PIS choose to make use of “qualified trust services” which are not compliant with the requirements set up by the RTSs, then the use of qualified trust services by the AIS and PIS could represent a vulnerability within the payment’s supply chain thus effecting the functioning of the entire system.”
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.
According with subparagraph (b) of the final text of the Payment Services Directive 2 , Payment Services Providers (PSPs) are obliged to use Strong Customer Authentication (SCA) when a payer 'initiates an electronic payment transaction'. According with paragraph 2 of Article 97 electronic payment transactions include also ‘remote electronic payments’, which as indicated in the definition (Article 4), refers to any payment transaction initiated via internet or through a device that can be used for distance communication.Therefore, e-commerce/online card payments should also be considered as an additional example to be subject to SCA as they are considered risky transactions. In terms of actions implying risk, we are of the view that the editing (update) of personal data, as physical and digital addresses such as phone number, e-mail address, and customer’s personal data should be subject to SCA. The rationale behind this is that information can be used by the fraudster for theft identity purposes.
Another consideration is the use of Strong Customer Authentication at “Login” phase. If strong customer authentication would be required for the display of sensitive payment data (i.e. personal e-mail or mobile number), then SCA in login phase (access the online account) should not be necessary.
In addition, another action zone that implies risk is “pre-login”, which is the webpage that takes the customer to his online home baking login’s page. The pre-login webpage -usually a public https page- may be a vehicle of malware action.
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?
First of all, we deem necessary the clarification of the meaning of ‘data” in the context of this question. For example, are software library and digital certificate considered as data?In the context of strong customer authentication, the authentication element of “possession” could be either in a physical form (i.e. customer’s mobile device as smartphone, OTP generator (token) or the possession of a data linked to a device (app/software security library).
For example, if in a simple data form (as a username or a static password), the category matches the ‘knowledge’.
Moreover, data (i.e. payee, amount) can be linked to a possession element (device, OTP generator, software library) to create a unique OTP (possession + knowledge).
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?
The authentication element of “Inherence” (something the user is) must be something that cannot be reproduced, as biometric characteristics.Although still in its infancy, there are some new developments that could provide some behaviour-based characteristics, such as the interaction of the user through the device/keyboard, or the use of the smartphone which could be considered in the context of ‘inherence’.
Other customer behaviour-based characteristics (i.e. geographic area, device fingerprint, IP address, operative system used, etc) are important key factors that could be used as additional controls or as an element(s) to be considered within the list of exemptions. However these should not be considered as an alternative to biometric authentication.
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)?
The challenge is the combination of independent factors that allows to strongly identify the user and the device (mobile or PC). For example: a two factor authentication and the device fingerprint.The elements used in “authentication phase” should be different from the elements used in “authorization phase”.
5. Which challenges do you identify for fulfilling the objectives of strong customer authentication with respect to dynamic linking?
For electronic remote payments, in case it is not possible to dynamically and unambiguously link the transaction to both the amount of the payment and payee, at least the payee then must be linked (e.g. when the transaction amount is unknown). In general, when one of the two elements is not available, another different element related to the event could be linked.For the list of payments or “bulk orders” dynamic elements linking the payee and the amount of the transaction could be an algorithm considering all the payments, or a random selection of one among the list of payments.
6. In your view, which solutions for mobile devices fulfil both the objective of independence and dynamic linking already today?
The new generation of smartphones could fulfil both the aforementioned objectives. The objective of independence can be guaranteed by “separating” the authentication from the validation by using two different devices or, if in a full mobile mode, by using two different mobile channels.7. Do you consider the clarifications suggested regarding the potential exemptions to strong customer authentication, to be useful?
Yes, we agree on the list provided in paragraph 42 (page 16) which provides features or criteria for strong customer authentication exemptions.Regarding point “D” on low-risk transactions based on transaction risk analysis, criteria based on customer behaviour could be taken into account.
8. Are there any other factors the EBA should consider when deciding on the exemptions applicable to the forthcoming regulatory technical standards?
Other factors that could be considered when deciding the exemptions are transactions for a known beneficiary or a specific type of transaction, which do not necessary fall into the “white list” of the customer but that may come from a “white list” of the system, as well as those transactions in line with customer’s behaviour factors. For example, the white list of the system can be dynamically created and periodically re-evaluated from the common characteristics of genuine payments identified by a specific payment institution.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?
An additional criteria could be the combination of key factors, also considering the behaviour based characteristics detected through specific tools.An efficient fraud risk engine - besides switching low risk transactions to the list of exemptions, scoring the risk for raising alerts and additional controls and other related actions within the payment antifraud engine -could also be extended to help the business sharing the user experience and thus creating best practices for other activities.
10. Do you consider the clarification suggested regarding the protection of users personalised security credentials to be useful?
The clarification regarding the protection of users' personalized security credential is welcome.We are of the view that user’s personalized security credentials must be properly treated, in particular when the user selects a third party provider. Also, in this case it is very important that the Payment Service Providers (as owner of the user’s credential) should be alerted and warned on real time.
Protection of credentials is also important on e-IDAS perspective which would allow the use of the same credentials either for online payment services or for e-identity purposes.
In addition, we would recommend the EBA to clearly specify the list of “sensitive payment data”.
11. What other risks with regard to the protection of users’ personalised security credentials do you identify?
Additional risks, with regard to the protection of personal data, are related to the user’s ability/knowledge/awareness to identify cases or situations such as phishing or fake/fraudulent third party websites. The user may not be able to recognize the clone site in which he is entering his personal security credentials.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?
A subset of personal data transmitted through different channels to the owner of the personalised security credentials (in this case the PSP) helps for a safe transmission.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?
In our view, the use of a certification or evaluation by third parties in this situation should not be the only or the best alternative. We believe that payments institutions should not be constrained or obliged to share their security solutions to a third party. We are of the view the use of guidelines and/or an audit/assessment of the payment institution’s security solutions would be preferable.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?
The most critical phase is during the execution of the payment: in this phase the user does not lose control of his/her credentials but allows the payment to be redirected, and properly authorized (e.g. action of MITM (man in the middle) malware).Another critical phase is when data is accessed by a third party payment service. (TPP).
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?
In addition to the abovementioned points, in terms of security we would like to highlight the “API layer” (the concept of Open Bank) which is a topic that is getting now more attention although still in its infancy. We deem that clarifications in terms of reference standards, models, technologies and implementation practices for API layer are necessary.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?
The future RTS should clarify the following points:• Regarding point A, in our view standard “common” and “open” definitions, should not be defined from scratch. Definitions could be stated using international standards already consolidated.
• Regarding point B, RTS should clarify which existing methods for identification of entities could be used (e.g., certificates issued from a Certification Authority) in order to avoid an additional burden on future implementation.
• Regarding point C, RTS should specify or suggest a list of secure (by design) encryption algorithms and a list of secure communication protocols.
• Regarding point D, RTS should definitely include a specific list of which the available services (split for AIS and PIS) should be (not only as examples)
• Regarding point E, RTS should include details on when, how and who can access operation/transaction data to perform the security control, in order to ensure privacy of the payment service user (PSU) and avoid internal threat. Moreover, existing international standard frameworks should be leveraged as far as possible.
• Regarding point F, RTS should include requirements to evaluate the adoption of a communication middle-layer technology that may ease the interoperability between existing systems while reducing efforts for implementation.
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?
The “NIST Special Publication 800-53 Revision 4” should be taken into account. It’s an open and common framework for implementing security and privacy controls in US Federal Systems and Organization, which properly complies with security requirements for the Financial Sector.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)?
In order to securely integrate other innovative business models than the one explicitly mentioned under article 66 and 67, we recommend that a European body is appointed in order to allow proper governance and manage such a need as appropriate.This body could also organize scheduled workshop initiatives, with round tables, propose/discuss changes on requirements to enhance them or to ensure that they can integrate new business models. The round table should be composed by market players, ISPs (internet service providers), big IT players (i.e. well-consolidated leading vendors of IT solutions, vendors of IT products and solutions) and Universities.
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.
In general, it should be considered that the adoption of a common open standard of communication can bring benefits, however it could also be exposed to system’s vulnerabilities: by their nature, a possible native bug or vulnerabilities of the standards can affect the entire system at the same time. Therefore, it should be permitted to each PSP to extend/customize the standard, within specific or pre-established limits, in order to contrast possible vulnerabilities (i.e. Open standard SSL encryption).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.
In this case the “qualified trust services” are not under the control of PSPs, which means that the system is not aware about the security level of these kinds of services, therefore PSPs have to trust “qualified trust services”. Hence, the “qualified trust services” should comply with strict requirements and certifications included in the EBA’s RTS as well as to be subject to an authority who guarantee their services.In the case that AIS and PIS choose to make use of “qualified trust services” which are not compliant with the requirements set up by the RTSs, then the use of qualified trust services by the AIS and PIS could represent a vulnerability within the payment’s supply chain thus effecting the functioning of the entire system.”