The purposes for which payment initiation and account information service providers may ac-cess accounts with the explicit consent of the account holder (payment service user) are well defined, notably in Recitals 28 and 29. The payment initiation service provider may access such account to provide comfort to a payee that the payment has been initiated in order for the latter to release goods or deliver the service without undue delay, and the account information service provider may do so to provide the payment service user with an overall view of its fi-nancial situation.
Whilst these transactions may trigger fraud, so may other actions initiated by the PSU to man-age his account or the payment instruments attached to it.

Possession elements to be used include connected devices registered with the ASPSP (e.g. mo-bile devices, see questions 4 and 6 below) as well as dynamic and static tokens. Possession el-ements may come in the form of data, provided there is a link with a physical device.

The use of behavior-based characteristics should certainly be allowed in the context of strong customer authentication (in particular whenever other, simpler elements are also used). Such use should however not be mandated.

The main challenge currently consists in enforcing on the PSU the independence of authentica-tion elements to be exchanged over distinct channels. A precondition for mobile devices is that these are registered with the ASPSP and thus linked to a given PSU.
It should be highlighted that there are currently solutions that fulfill the independence re-quirement of the authentication elements in mobile devices (see question 6 below).

As such dynamic linking allows to fulfill the objective of strong customer authentication, pro-vided that the communication of the code generated identifies the transaction to the PSU (e.g. kind, amount, payee, etc…) and can only be accessed by using other authentication elements (knowledge, e.g. PIN, or inherence, e.g. biometrics). Furthermore the link should be traceable in case of dispute.

The combination of dynamic linking with access by another authentication element meets both objectives. To illustrate: a PSU would only be allowed to do a transaction by introducing a PIN (something only he knows) or using his fingerprint (something he is) on a mobile device, receiving on hi previously communicated phone number (the same device as the former, or a different one) a dynamic code that identifies the transaction, amount, payee, etc. here, chang-ing the previously registered phone number should require strong customer authentication. Al-ternatively the dynamic code could be generated through an app with the same requirements, to which other security elements could be added (e.g. root control, ssl pinning, …). There cur-rently exist mobile devices that allow to use fingerprinting, keeping the information in their own key store/key chain.

Both proximity low value payments and transfers between two accounts of the same PSU held at the same ASPSP should be exempt from strong customer authentication. Recurrent pay-ments could be exempted too, provided the first of such transaction be subject to strong cus-tomer authentication.
The use of exemptions should however be at the discretion of the ASPSP, who should always retain the capacity to revert to strong customer authentication (e.g. should a PSU’s behavior become “erratic”).

EBA should acknowledge that the ultimate responsibility for customer risk evaluation resides with the ASPSP.

For e-commerce, additional criteria could be based on the risk assessment of the payee (i.e. “trusted” payees would be rated as low risk, based on experience). The main card schemes are already considering such an approach.

Opening consideration: throughout the topics covered in this section, the RTS should maintain technological neutrality in order to on one side allow for co-existence of working solutions, on the other enable innovations to be introduced.
The clarifications suggested are useful. However the uncertainty created by the conflict be-tween Recital 69 and Art. 66 (3) b and 67 (2) b with respect to keeping the personalized secu-rity credentials safe must be resolved in the RTS. Any handing over of personalized security credentials to a third party including AIS/PIS providers must translate into a shift in liability away from the ASPSP – which has system stability implications. Additionally this situation would increase the risk referred to in para. 51.E, as third parties would have access to them.
That personalized security credentials may not be handed over to third parties actually derives from the definition of sensitive payment data (“… data, including personalized security creden-tials which can be used to carry out fraud….”) and the rules applying to payment initiation ser-vices (Art. 66.3(e): “The payment initiation service provider shall: …not store sensitive pay-ment data of the payment service user”) and the account information service provider (Art. 67.2(e): “The account information service provider shall: …not request sensitive payment data linked to the payment accounts”).

Risks occur whilst personalized security credentials are:
- Sent to the PSU,
- Held by the PSU,
- Used for identification.
Such risks must be mitigated by continued PSU education and information with respect to both “health practices” and usage of the proper software. Any ambiguity regarding e.g. the pro-tection of personalized security credentials can only have adverse implications with respect to the intended consumer protection objective.

Open standards exist in the market. An attractive solution allows for access tokens to be is-sued by ASPSPs to be used for authorization by a third party app.

Going forward – in particular considering the variety of access channels – it will be increasingly important for tamper resistance to use solely disconnected hardware devices or smart (soft-ware-based) tokens, provided the latter are certified and that this certification can be validated remotely (this would not be necessary when credentials are used solely in an ASPSP’s system, with hosting/transmitting through the latter’s system/apps)

The weakest point in the chain are the PSU – both from an environment and a practices per-spective – and its relation with a AIS/PIS provider (uncertainty of AIS/PIS provider identity, risk of compromise of PSU – AIS/PIS provider relationship,…). The “banalization” of third party services introduced by PSD2 in this respect creates the prospect of “snowball” effects in terms of risk and damage. At present the main risk would be related to the capture of PSU cre-dentials via phishing or social engineering: introducing third party services in the credential chain increases that risk.

Opening consideration:
As quoted by EBA, PSD2 Recital 33 (stating that “This Directive should aim to ensure continuity in the market, enabling existing and new service providers, regardless of the business model applied by them, to offer their services with a clear and harmonized regulatory framework….”) is of importance to this sec-tion of the discussion. Indeed, whilst acknowledging the entry of registered and regulated new service providers, incumbents should be allowed to continue and provide well-functioning ser-vices to payment service users without disruption to the latter and without having to revisit ex-isting business models.
a) “Common and open” standards: a common definition would be welcome – as there are cur-rently a range of definitions and interpretations available. Such definition should include a view on the required governance to evolve the standards concerned.

b) Identification of AIS and PIS providers towards ASPSPs for access: the clarifications pro-vided notably under paragraph 57 of the discussion paper are comprehensive and suitable. We recommend however that the considerations expressed in Recitals 28 and 29 be re-called when EBA drafts the RTS. The RTS should also clarify how AIS and PIS providers identify themselves unambiguously towards the payment service user, including providing evidence that they are duly registered and regulated.

c) Secure communication between ASPSPs and PSUs, and AIS/PÏS providers: a PKI archi-tecture should be used.

d) Minimum functionalities requirements for the future common and secure open standards of communication: the services that can be requested by the AIS/PIS providers are well de-fined notably in Recitals 28 and 29 – which should form the basis for that section of the RTS. The related standards should not allow for any interpretation so that processing by ASPSPs can be fully automated. The PSU’s consent must be unambiguously linked to a given payment account and a single transaction (either payment initiation, or information request), requested and provided solely through the common and open interface provided by the ASPSP.

e) Minimum security controls: there should be 3 layers of security controls:
- The PSU should be able to verify that he gives consent to a registered and regulated AIS/PIS provider;
- The AIS/PIS provider should be able to verify that he deals with a genuine PSU.
- The ASPSP should be able to verify automatically that any request originates from a registered and regulated AIS/PIS provider, on behalf (i.e. with the express consent of) a genuine PSU. The ASPSP should be able to reject any request that i.a. does not meet this test.
The PSU’s consent should be provided as stated under d) above, which enables the said PSU to withdraw consent independently from the AIS/PIS provider.

f) Minimum technical requirements for the common and secure open standards of communi-cation: taking into account remarks made notably under 11, 14, and 15 d) above, it should be noted that a wide range of market solutions already exist to supporting such secure communication. For due reasons interoperability is required. It can however not be ex-pected that all existing solutions become interoperable with each other. For practicality yet mostly for cost efficiency purposes EBA should the requirements for a small (e.g. 3) set of default secure communication standards, for interoperability purposes. Such approach would support channel independence and allow for the gradual introduction of innova-tions.

As not only innovation but market continuity (as stressed above) are to be enabled, the RTS by themselves may not necessarily prevent “divergent practical implementations” by ASPSPs, or rather AIS/PIS providers for that matter. The RTS thus should specify a small range (e.g. 3) of communication protocols, how ASPSPs and AIS/PIS providers will unambiguously identify themselves and how they will be authenticated, and a set of generic request, response and au-thentication messages. On the basis of the RTS market players will have to work on implemen-tation guidelines in order to over time achieve full interoperability.

There are a small number of well accepted market solutions in Europe which leverage the PKI architecture and which would continue to be used by AIS/PIS providers. Work on interopera-bility between these solutions should be fostered.

We would submit that for the period until the planned review of PSD2, the transposition of the latter’s new dispositions whilst maintaining customer confidence and system efficiency already constitutes a significant challenge – “other innovative business models” could be contemplated at a later stage. At any rate EBA’s requirements should allow for forthcoming evolutions.

The e-IDAS Regulation provides a blueprint for possible solutions facilitating strong customer authentication, protecting confidentiality and integrity of personalized security credentials, and common and secure open standards of communication for identification, authentication and notification. Although we understand that the e-IDAS Regulation has been drafted with mainly government services in mind, most of its definitions and dispositions could be applied to the development of market services, where identities would be issued by PSD2 registered and reg-ulated market participants within own schemes or joint schemes with government authorities (processes may however need to be adapted to the realities and obligations of a primarily commercial environment). The definition of assurance levels (e-IDAS Regulation Art. 8, as well as related Implementing Act) should be leveraged. The principle of mutual recognition furthermore provides for an appealing solution supporting interoperability, competition, and security. Actually, in a number of countries (e.g. in the Nordics), private initiatives have suc-cessfully rolled out to the population and support millions of e-IDs.

Qualified trust services as defined in the e-IDAS Regulation (Art. 3(17) and Section 3) again provide a blueprint to address risks related to the confidentiality, integrity and availability of personalized security credentials between the various parties in scope of the present discus-sion. Again PSD2 registered and regulated market participants should also be able to provide, based on their individual choice and on a commercial basis, qualified trust services meeting the to-be specified level of assurance of personalized security credentials. Mutual recognition of a range of qualified trust service schemes would here also assist in delivering EU-wide solutions, also with respect to unambiguously identifying registered and regulated AIS, PIS and ASPS providers.