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.

A physical form may not be needed in all circumstances; therefore we consider data only as a valid possibility as well.

In our opinion behavior-based elements (like determination if mobile is held in the right/left hand) combined with device characteristics are sufficient.

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)."

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.

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.

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.

No other or further criteria, but we kindly ask EBA to consider the existing data protection rules.

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.

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.

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.

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.

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.

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.

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.

At this point, without an in-depth analysis it is not possible to make any recommendations. We would rather not comment, as this seems simply not possible, without knowledge what these “other innovative business models” are supposed to be.

Unfortuntaly the e-IDAS regulation fails to provide a single clearly defined technique or means for identification of a person, but allows for a plethora of different divergent implementations, enforcing the acknowledgement within the realm of e-government applications (not caring about the costs involved). This can by no means provide an acceptable solution for pan-European e-commerce applications.

As pointed out above, using “qualified trust services” is a possibility but should be restricted to one defined CA. However, it should be ensured that there is a common standard for the integration into the different systems of all parties concerned.