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).
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).
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.
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.
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.
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.
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.
At the moment we don’t see any other factors that should be taken into consideration.
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.
Yes, the clarifications suggested are useful and necessary for the RTS development.
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.
No. EBA should clarify how such communication channels and technical components should be certified or evaluated by independent third parties to ensure such resistance.
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.
Yes, we consider that the clarifications provided are comprehensive and suitable.
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).
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.
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.
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.