Response to discussion on RTS on strong customer authentication and secure communication under PSD2

Go back

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.

Introduction:

Please find below, Romanian Banking Association's answers to EBA's discussion paper on future Draft Regulatory Technical Standards on strong customer authentication and secure communication under the revised Payment Services Directive (PSD2).

The strong customer authentication term used might need additional clarifications, according to PSD2 and definitions within the DP, is referring to (I)dentification, (A)uthentication and (A)uthorization and not strictly to the authentication as the initial term suggest. Perhaps treating the strong customer authentication by considering all three individual terms will create more clarity and less barriers to innovation (for example, the IAA concept elements coupled wisely also with a risk scoring engine could enhance the user experience more than enforcing a generic term as strong customer authentication).


First question answer:
The examples mentioned should be treated as “examples” and not as an exhaustive list of transactions or actions implying a risk of payment fraud or other abuses. It would be difficult to define a list without limiting in the future innovation of PSPs to include other type of transactions or actions which might be considered by PSPs to be provided in the future.
Other examples which can be included in the RTS are the following:
• e-shop transactions - there are banks which, besides traditional payment related transactions, are offering to clients other type of facilities like: pre-paid mobile telephony e-credit, vignette purchase;
• online loans - clients being able to request and receive a personal loan via internet banking solution (without needing to visit a physical branch).

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?

The answer is provided based on the assumption that, in this paper, one example of data possession elements is a etoken software solution like Google authenticator or a grid (printable spreadsheet of numbers and letters used to enter different values when logging in) and one example of physical possession element is a hardware token. Due to the fact that in this paper there are no examples mentioned like the other elements used for strong customer authentication, for clarity reasons we suggest that in the RTS examples to be given also for possession elements.
If the assumption is correct, then we consider that data possession elements can be in physical form and in a data form, both of the examples being appropriate to be used in the context of strong customer authentication.
In order to make sure that data can only be controlled by the PSU, the possession elements should only be in the control of the PSU (e.g. etoken software installed on a device controlled by the PSU) and PSP to have the data used for linking to PSU to the possession element encrypted (e.g. grid is encrypted so as only the PSU has access to the clear version of the grid).

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?

As the term implies, “inherence” refers to a characteristic particular to an individual. Behaviour-based characteristics, although related to the behaviour of an individual in an application, can be easily compromised/reproduced in case the device of the PSU is infected with a malware and this can be done remotely, without the fraudster needing to be physically located near its victim. This means that the number of PSUs compromised can be also significant.
“Inherence” elements are much more difficult to be compromised/reproduced and imply some sort of physical contact/presence of the PSU in order for this to happen. This also means that the number of PSUs compromised will be lower.
Due to the reasons above we believe that behaviour-based characteristics are not appropriate to be used in the context of strong customer 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)?

Besides the example provided already in the DP for mobile devices, the following challenges are also to be considered:
• in case of a desktop PC device of a PSU: if the PSU has the data possession element installed/stored in the PC and the device is infected with a malware then the data possession element is also compromised - e.g. if the grid is stored in an electronic form on the desktop PC or the software etoken is installed on the desktop PC.
• in case of online card payments - all the data necessary to perform a card payment - name of the owner of the card, card number, expiration data, CVV/CVC number and 3DSecure static password, will be compromised in case the device used by PSU to perform an online card payment is compromised. In order to mitigate this we strongly recommend the implementation of strong customer authentication for 3DSecure feature, as recommended by ECB Security of Retail Payments Guidelines document.

5. Which challenges do you identify for fulfilling the objectives of strong customer authentication with respect to dynamic linking?

Related to Article 97(2) of the DIRECTIVE (EU) 2015/2366 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 25 November 2015 on payment services in the internal market, amending Directives 2002/65/EC, 2009/110/EC and 2013/36/EU and Regulation (EU) No 1093/2010, and repealing Directive 2007/64/EC it should be taken in consideration that for all electronic remote payment transactions (card not present), it’s not possible to dynamically link the transaction to a specific payee. At this point, on the e-commerce web sites, the client doesn’t have access to destination bank account information, etc.
Nevertheless, if all the required information to dynamically link the transaction to a specific amount and payee, would be made available to the client, there is malware available that can alter the information shown on the screen to the client (fake banking accounts), in order to make him electronically sign a fraudulent transaction.
Therefore, we consider the situation described above related to electronic remote payment transactions (card not present), should be treated as an exception (Article 98 3.(c)) and the implementation of a dynamic linking solution should be left at PSPs consideration, following a risk assessment and a cost-benefit analysis. Implementation of such a solution might come with a significant cost as it may imply replacing the current authentication and authorization solution implemented at PSPs. Such a cost should be balanced with the real benefit brought by such solution.
Considering that current cyber crime attacks are focused on social engineering the PSU or having the PSU device infected with a malware, even with such a solution in place fraud can still take place - either the PSU is social engineered via the phone or even via a Man in the Browser attack to handle to the fraudster the details needed to authorize the fraudulent transaction. The malware present on the PSU device could modify online the details presented to the PSU in the internet banking interface and void the presence of such a solution.
Channels on which dynamical link (as defined in the Art. 97(2) on PSD2) is difficult to be implemented are the ATM, POS and ecommerce. Authorizing multiple payments (file or payments in a queue) is also difficult when speaking about the dynamical link as enounced in the PSD2. There are customers that have thousands of payments to authorize – basically it is impossible to implement a dynamic link considering an individual amount of the payment.

6. In your view, which solutions for mobile devices fulfil both the objective of independence and dynamic linking already today?

We did not identify any solution which can fulfil both the objective of independence and dynamic linking for mobile devices today. Maybe one possible solution could be to have the secure elements residing on SIM card used by the mobile phone.

7. Do you consider the clarifications suggested regarding the potential exemptions to strong customer authentication, to be useful?

Yes, examples are useful. If not included in paragraph 42 (C) foreign-exchange transactions between PSU accounts should also be given as an example.
In regards with paragraph 42 (B) exemptions should be also considered for outgoing payments to trusted beneficiaries included in previously established white lists by PSP. For example, accounts of the utility providers (gas, water, electricity, etc) opened with the PSP.

8. Are there any other factors the EBA should consider when deciding on the exemptions applicable to the forthcoming regulatory technical standards?

At the moment we don’t see any other factors that should be taken into consideration.

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?

Could you please clarify paragraph 45 (c) “types of service provided, transaction history) and the payees device (where applicable)” , our understanding is that the scenario is only applicable for the payees which belong to the same PSP as the PSU.

10. Do you consider the clarification suggested regarding the protection of users personalised security credentials to be useful?

Yes, the clarifications suggested are useful and necessary for the RTS development.

11. What other risks with regard to the protection of users’ personalised security credentials do you identify?

None.

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?

Sending parts or complete codes using different communication media could be a method for transmitting initial PSC to the customers. For example: user name/initial code could be sent using the email (this could be an encrypted/signed email) doubled by an activation code sent via SMS.

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. EBA should clarify how such communication channels and technical components should be certified or evaluated by independent third parties to ensure such resistance.

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 weakest link in the payment chain remain people as phishing and malware gets more and more smarter and focused. Therefore the initiation of authentication from PSU’s terminals is more likely to be compromised by above mentioned threats in the current and foreseeable future.
By also taking into account the vulnerabilities discovered during the near past like poodle, freak, Logjam, another weak link in the payment chain could be the communication channel.

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?

Yes, we consider that the clarifications provided are comprehensive and suitable.

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?

Developing RTS to cover AIS/PIS safely usage, respecting security standards and protecting the PSU is a must and such RTS must be available as soon as possible. This needs to clarify who is ensuring the compliance with PSD2 of AIS/PIS. What if the AIS is located in Australia and is not obliged to comply with EU laws and regulations …
If AIS/PIS could use the customer’s data (having PSU consent) why ASPSP must ask the customer for strong authentication to access the account balance (and hence affecting the customer experience) but share customer’s data with third parties which may not be bound to the same rules.
Good scrutiny of AIS/PIS must be in place so that customer’s data is not been shared with “shady entities” which could sell it for profit (e.g. customer buying habits).

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?

No, there are no common and open standards that 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.

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)?

N/A.

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.

Yes, we agree that using qualified certificates could be a solution for the above points but this method should be agreed by the PSP and should not represent a mandatory (imposed) solution.

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.

Yes. The use of qualified trust services could represent a solution for authentication and authorization between PSP and AIS/PIS.


We are ready to provide more details and information if necessary.

Name of organisation

Romanian Banking Association

Please select which category best describes you and/or your organisation.

[Other"]"

If you selected ‘Other’, please provide details

Banking Association

Please select which category best describes you and/or your organisation.

[Other "]"

If you selected ‘Other’, please provide details

Banking Association