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.

In our opinion, any transaction performed online, including mobile transactions, in principle generate risk. Additional examples that can indicate fraud risk are:
• changes of authentication / authorization methods, PSU linked devices or any authentication data,
• changes of address or personal data, especially correspondence address or phone number (this way fraudsters are trying to take over authentication data),
• pairing with account of new mobile devices (mobile banking) ,
• changes of transaction limits
• launch of credit/loans applications (after taking over an account fraudsters also try to increase available funds by applying for cash loans on behalf of victim),
• mass payments / payments baskets, also uploaded as files with transactions list – usually it’s difficult to create dynamically linked authentication data in human readable form which would allow to verify all mass transactions, if strong authentication will be only for whole basket (batch) than attackers can inject fraud transactions.
Thus ASPSP on the basis of multi factor risk assessment should be able to enforce strong consumer authentication for any operation initiated by the PIS or AIS provider. This important to reduce risks related to rouge PIS (companies established with fraud in mind – i.e. providing regular services for some time and finally initiating multiple fraud transactions).
It is also crucial that PIS and AIS would not have access to PSU credentials for ASPSPs. Authentication concept for transactions placed through PIS or AIS have to ensure accountability of those transactions and to ensure it PIS and AIS have to use dedicated authentication i.e. based on tokens exchanged between ASPSP and AIS/PIS and authorized by PSU or using pay-by-link concept.

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 our opinion data on device, can be used in the context of strong consumer authentication but under condition that ASPSP is able to build risk profile for each transaction including profiling of the authentication device. Second condition is that all PSUs authentication data for ASPSP are not available for PIS or AIS. PSU authentication data should also be properly protected on ASPSP side (like in case of sensitive payment data in SecuRe Pay). As mentioned earlier PIS and AIS should use additional, separate credentials (like tokens exchange between ASPSP and AIS/PIS after authorization by PSU) or using pay-by-link concept.
Additionally possession elements in the context of strong authentication should be:
• linked to physical device – token or in case of data on mobile device, implementation should ensure that data can’t be moved/cloned on different device (at least not easily),
• protected by strong cryptography using knowledge (PIN) or inheritance elements, in case of data on mobile device at least one element (i.e. PIN) should not be stored on the same device but on ASPSP side,
• for transactions authorization and in authentication process there should be independent channel used – it can be on the same device, but has to be protected by different set of data (i.e. separate channel to authorization system using own certificate set), this channel should also allow to send back from ASPSP to PSU full details of transaction for confirmation

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 should be used only as additional (supporting) authentication method, not as a only one. In fact behaviour-based characteristics should be part of risk analysis and considering also additional factors (like type of the transaction, authentication method used, amount etc.) give a combined risk score which can be used to accept, reject or exact additional authentication.
To make behaviour-based characteristics reliable (and to build proper risk profile for the transaction) ASPSPs have to receive from PIS required transactions details like true beneficiary, description etc. and not transaction internal id generated by PIS.
Use behaviour-based characteristics as an only strong authentication is in our opinion not recommended approach. There are no standards defining what elements of such characteristics should be considered as minimum, what parameterization should be applied, what algorithms, scores etc. If too simple characteristics will be used than there is high probability of attacks circumventing such authentication mechanism (i.e. simulation, also learning of mouse movements, keyboard strokes, using proxy and tunneling to perform attack from typical IP address space etc.).

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

Main challenge would be aversion of customers to use additional devices (tokens) which would impact their mobility. Another factor would be cost of additional devices/elements.
Additional factor is that there are many different standards and solutions on the mobile market (not every device has biometric capabilities, not every uses SIM card, not every SIM card will have secure element that can be used etc.).
Because of that it should be possible to use data on the device as a possession element (as described in comments to the 2nd question) considering that:
• transactions will have reasonable limits (different in case of one device and different in case 2 separate device are used)
• mobile application is used that has implemented measures against modification (data or memory) and uses strong cryptography (as in comment to 2nd question)
• there is independent (different than channel used for transaction) channel for authentication (as described in comment to 2nd question)
• PSP uses behavioral antifraud solution

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

Considering dynamic linking as a value that is linked only for one remote transaction and can’t be used for a different one we see challenge for voice only channels. But from our perspective dynamic linking should also provide user (PSU) with clear information about transaction (like part of account number, amount etc.) so one will be able to verify it. The dynamic code itself is not enough (user is not able to decipher it and to verify that it is linked to transaction data that he intended – it’s especially important in case of man-in-the browser attacks). This can be achieved using separate digital communication channel (SMS, or separate encrypted data stream) but again is difficult in voice only environment and most secure solution would involve separate hardware token with own display (this can be not welcomed by heavy mobile users and generates additional costs).

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

Strongest one are dedicated devices with own display which are able to establish connection to authorization system in the bank using i.e. computer or mobile device only as a router/access point. Data are encrypted point-to-point (between token and bank) and device can present transaction details on the screen and ensures strong digital signature.
Cheaper variant uses dedicated, protected application on mobile device (but the risk of altering is higher than in case of dedicated hardware token).

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

EBA's clarification is useful, but the key issue is, what kind of actions really requires strong authentication and segregation of responsibilities between PIS and PIS/AIS. However, it should be emphasized that at this stage seems that any transaction involving PIS or AIS should be authenticated on ASPSP side. Additionally exemptions options should be related to risk assessment.

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

• when customer (PSU) doesn’t want to use strong authentication (like hardware token) and thus responsibility of ASPSP should be limited
• when PIS is not providing enough information about transaction and as a result risk analysis is limited
• base capital of PIS companies which should impact allowed limits and volumes of transactions

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?

• Intended authentication method
• General risk related to particular type of transaction (i.e. higher for card not present)
• Last activity (i.e. geolocation, loans applications)

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

Yes, but we would like also to emphasize again that access to authentication data should be allowed only to the user and the institution that provides the customer with this data - eg. ASPSP to its customer. This institution is also entity to decide in what kind of environment it can be used (for example: only on the transaction system of this institution).

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

Man-in-the-middle attacks (especially man-in-the-browser) and also internal fraud (especially when credentials are not properly protected). Also as stated earlier allowing access to those credential by different institution that provides the customer with this data creates high risk related to limited accountability, possibly lower security of smaller PISes and rouge PIS scenario.

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?

Physical delivery of QR-like code which is associated to particular device / application delivered or installed by the customer (so even in case of interception of code it is impossible to link another device to the customer account).

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?

We see no alternatives to certification or assessment.

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?

• User side (mobile & windows malware, social engineering including obtaining i.e. SIM duplicates)
• Merchant
• PIS/AIS (social engineering combined with many PIS/AIS services)
• Credentials enrolment process (PSP)

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?

At a general and high level we consider them to be sufficient. However, we expect that those will be further clarified in RTS.

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?

A minimal (hard) requirements, recommended (soft) requirements, guidelines. We would prefer clarification restrain from binding to specific underlying implementation, especially to vendor-specific implementations. Although we would welcome references to open and industry standards and methods.

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?

An exemplary, commercially functioning solution on the Polish market are Pay-by-link as a way to transfer the context of payment or other requests (e.g. data within AIS). Moreover, it seems reasonable to consider a European registry of all AIS or PIS for use by all ASPSP.

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

Because of responsibility of ASPSP in particular, it should be ensured the they have influence on security standards. It seems that markets should be able to develop national rules, best adjusted to their singularity, existing practices, regulations and payment practices.

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, but different maturity and availability of local (national) systems should be considered.

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.

It seems that relying on the already-developing standard, is a good approach. The new circumstances introduced by Directive PSD2 should, however, be taken into account.

Name of organisation

mBank S.A.

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

[ "]"

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

[ "]"