Response to discussion on RTS on strong customer authentication and secure communication under PSD2
Go back
a. With respect to the independence of the authentication elements used for mobile devices, to guarantee independence from the authentication elements a standalone secure app is recommended, so that even when working on a single mobile device 2 separate, independent channels exist (1st channel: eBanking app; 2nd channel: secure app). In such a case I have to make a login at first in the eBanking app (1. channel; 1. device) and then a login in the secure App (2nd channel; 2nd device) where I also receive the pushTAN" for subscription the transaction.
b. An independent secure app would not be required, when a separate secure channel between a virtual smartcard (SDK) in the eBanking app and a seperate secure server exist. This would be a valid solution with only 1 app (eBanking app)."
b. mobileTAN also is a method that fulfils both the objective of independence and dynamic linkage. The mobileTAN is delivered by a separate and different communication channel (SMS). mobileTANs are transaction specific TANs which are generated solely for one specific transaction that are valid for certain time and cannot be reused.
As technology evolves, innovative solutions that support the enrolment process (physical and electronic) continue to develop. An innovative solution may be video legitimation, which is already used by many banks in Germany. Video legitimation enables customers to enroll electronically by scanning a personal ID via a live video conference. Another form may be acoustic legitimation in combination with additional personal credential checks.
And concerning item “c.” we raise the question how communication and exchange of data with respect to confidentiality can take place between AISP and PISP only (i.e. without involvement of an ASPSP), as in this case there is no customer authentication at all.
Concerning item “a” it is important to clarify if common standards are useful at any time (e.g. private vs. commercial customers).
b) As a basis we need a comprehensive list of certified TTPs including an unambiguous identification number, the service the TTP is providing (AIS and/or PIS) and the certificates the TTP is using (one for TLS, one for signatures with a qualified seal). All certificates shall be issued by one single CA to reduce processing overhead. The list shall be maintained by EBA or a party acting on its behalf. All transaction data including the identification number must be signed with the qualified seal of the TTP.
c) See above TLS and qualified seal.
d) e) and f) Sorry, but without an in depth analysis of all the topics the RTSs shall cover it is not feasible to provide all the information you are requesting here and is beyond the scope of a simple questionaire.
However, it is essential that the EBA RTS regulate that AISPs may not ask for account information more often than the average customer would. Not limiting the number of requests per account for AISPs may result in excessive automatic machine-originated requests thus generating very high communication costs on the ASPSP side not to mention the additional IT-capacity needed to respond to such unlimited frequent requests.
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.
No further input, we consider the list of examples provided under 27 iii in the DP as sufficient to explain what is meant by Article 97(1) (c). As banks know how to assess risks and how to tackle them an exhaustive list seems neither necessary nor achievable when considering future developments.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?
A physical form may not be needed in all circumstances; therefore we consider data only as a valid possibility as well.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?
In our opinion behavior-based elements (like determination if mobile is held in the right/left hand) combined with device characteristics are sufficient.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 independence of the authentification elements is essential, if not provided additional risks evolve that call for additional measures to meet the objective.a. With respect to the independence of the authentication elements used for mobile devices, to guarantee independence from the authentication elements a standalone secure app is recommended, so that even when working on a single mobile device 2 separate, independent channels exist (1st channel: eBanking app; 2nd channel: secure app). In such a case I have to make a login at first in the eBanking app (1. channel; 1. device) and then a login in the secure App (2nd channel; 2nd device) where I also receive the pushTAN" for subscription the transaction.
b. An independent secure app would not be required, when a separate secure channel between a virtual smartcard (SDK) in the eBanking app and a seperate secure server exist. This would be a valid solution with only 1 app (eBanking app)."
5. Which challenges do you identify for fulfilling the objectives of strong customer authentication with respect to dynamic linking?
We want to point out that the development of dynamic linking goes along with high IT setup costs, additional running costs for sending dynamic passwords and additional costs for communication.6. In your view, which solutions for mobile devices fulfil both the objective of independence and dynamic linking already today?
a. pushTAN is a method that fulfils both the objective of independence and dynamic linkage as it is a separate and solely secured app and has a secured communication channel. The pushTAN is generated on the basis of the transaction data (hash calculation), so that the pushTAN can be used only for a single, specific transaction. The generated TANs are time limited and cannot be reused.b. mobileTAN also is a method that fulfils both the objective of independence and dynamic linkage. The mobileTAN is delivered by a separate and different communication channel (SMS). mobileTANs are transaction specific TANs which are generated solely for one specific transaction that are valid for certain time and cannot be reused.
7. Do you consider the clarifications suggested regarding the potential exemptions to strong customer authentication, to be useful?
Yes, however, they are clarifications only and should not be regarded as an exhaustive list of criteria to be enforced. So in our opinion the list is only exemplary and cannot be seen as complete.8. Are there any other factors the EBA should consider when deciding on the exemptions applicable to the forthcoming regulatory technical standards?
There are different views on this issue in the industry.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?
No other or further criteria, but we kindly ask EBA to consider the existing data protection rules.10. Do you consider the clarification suggested regarding the protection of users personalised security credentials to be useful?
Yes, they are useful, however, it is necessary to make a clear distinction between what applies to ASPSPs (like item “i”, which addresses ASPSPs only) and AIS/PIS providers, which are addressed in items “ii” and “iii” as well, and define well-balanced minimum requiremts for all parties involved in a way that does not put all the burden on one party only.11. What other risks with regard to the protection of users’ personalised security credentials do you identify?
No additional ones, however, as you point out under item “E” with the inclusion of a third party in the payment process additional risks evolve and it is essentail that the RTS provide clear and stringent regulations for the registration and certification process of these third parties and their continuous supervision in such a manner that an ASPSP can rely on the adherence of a TTP.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?
No, and by the way, we consider the enrolment process as the least problematic considering the amount of experience of the banking industry in this field.As technology evolves, innovative solutions that support the enrolment process (physical and electronic) continue to develop. An innovative solution may be video legitimation, which is already used by many banks in Germany. Video legitimation enables customers to enroll electronically by scanning a personal ID via a live video conference. Another form may be acoustic legitimation in combination with additional personal credential checks.
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, evaluation and certification of technical components or devices and their firm ware, if applicable, is a well understood process. Therefore it may be a good idea to have the RTSs EBA is producing evaluated and/or certified by an independent third party.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?
At present this is certainly the customer (social engineering as key-word), in future the TTPs will possibly share this position taking into consideration the multitude of service providers which a single ASPSP will have to deal with, thus adding a multiplication factor in the risk analysis/assessment equation. For this reason, we strongly recommend, to consider the establishment of a secure channel betwenn customer and ASPSP as part of the RTS EBA has to provide for the communication between the parties whenever users’ PSCs are involved.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 least the topics should be amended by regulations and supervision processes for TTPs equivalent to those banks have to comply with.And concerning item “c.” we raise the question how communication and exchange of data with respect to confidentiality can take place between AISP and PISP only (i.e. without involvement of an ASPSP), as in this case there is no customer authentication at all.
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) We have no idea what the authors of the PSD had in mind.Concerning item “a” it is important to clarify if common standards are useful at any time (e.g. private vs. commercial customers).
b) As a basis we need a comprehensive list of certified TTPs including an unambiguous identification number, the service the TTP is providing (AIS and/or PIS) and the certificates the TTP is using (one for TLS, one for signatures with a qualified seal). All certificates shall be issued by one single CA to reduce processing overhead. The list shall be maintained by EBA or a party acting on its behalf. All transaction data including the identification number must be signed with the qualified seal of the TTP.
c) See above TLS and qualified seal.
d) e) and f) Sorry, but without an in depth analysis of all the topics the RTSs shall cover it is not feasible to provide all the information you are requesting here and is beyond the scope of a simple questionaire.
However, it is essential that the EBA RTS regulate that AISPs may not ask for account information more often than the average customer would. Not limiting the number of requests per account for AISPs may result in excessive automatic machine-originated requests thus generating very high communication costs on the ASPSP side not to mention the additional IT-capacity needed to respond to such unlimited frequent requests.