According with subparagraph (b) of the final text of the Payment Services Directive 2 , Payment Services Providers (PSPs) are obliged to use Strong Customer Authentication (SCA) when a payer 'initiates an electronic payment transaction'. According with paragraph 2 of Article 97 electronic payment transactions include also ‘remote electronic payments’, which as indicated in the definition (Article 4), refers to any payment transaction initiated via internet or through a device that can be used for distance communication.
Therefore, e-commerce/online card payments should also be considered as an additional example to be subject to SCA as they are considered risky transactions. In terms of actions implying risk, we are of the view that the editing (update) of personal data, as physical and digital addresses such as phone number, e-mail address, and customer’s personal data should be subject to SCA. The rationale behind this is that information can be used by the fraudster for theft identity purposes.
Another consideration is the use of Strong Customer Authentication at “Login” phase. If strong customer authentication would be required for the display of sensitive payment data (i.e. personal e-mail or mobile number), then SCA in login phase (access the online account) should not be necessary.
In addition, another action zone that implies risk is “pre-login”, which is the webpage that takes the customer to his online home baking login’s page. The pre-login webpage -usually a public https page- may be a vehicle of malware action.

First of all, we deem necessary the clarification of the meaning of ‘data” in the context of this question. For example, are software library and digital certificate considered as data?
In the context of strong customer authentication, the authentication element of “possession” could be either in a physical form (i.e. customer’s mobile device as smartphone, OTP generator (token) or the possession of a data linked to a device (app/software security library).
For example, if in a simple data form (as a username or a static password), the category matches the ‘knowledge’.
Moreover, data (i.e. payee, amount) can be linked to a possession element (device, OTP generator, software library) to create a unique OTP (possession + knowledge).

The authentication element of “Inherence” (something the user is) must be something that cannot be reproduced, as biometric characteristics.
Although still in its infancy, there are some new developments that could provide some behaviour-based characteristics, such as the interaction of the user through the device/keyboard, or the use of the smartphone which could be considered in the context of ‘inherence’.
Other customer behaviour-based characteristics (i.e. geographic area, device fingerprint, IP address, operative system used, etc) are important key factors that could be used as additional controls or as an element(s) to be considered within the list of exemptions. However these should not be considered as an alternative to biometric authentication.

The challenge is the combination of independent factors that allows to strongly identify the user and the device (mobile or PC). For example: a two factor authentication and the device fingerprint.
The elements used in “authentication phase” should be different from the elements used in “authorization phase”.

For electronic remote payments, in case it is not possible to dynamically and unambiguously link the transaction to both the amount of the payment and payee, at least the payee then must be linked (e.g. when the transaction amount is unknown). In general, when one of the two elements is not available, another different element related to the event could be linked.
For the list of payments or “bulk orders” dynamic elements linking the payee and the amount of the transaction could be an algorithm considering all the payments, or a random selection of one among the list of payments.

The new generation of smartphones could fulfil both the aforementioned objectives. The objective of independence can be guaranteed by “separating” the authentication from the validation by using two different devices or, if in a full mobile mode, by using two different mobile channels.

Yes, we agree on the list provided in paragraph 42 (page 16) which provides features or criteria for strong customer authentication exemptions.
Regarding point “D” on low-risk transactions based on transaction risk analysis, criteria based on customer behaviour could be taken into account.

Other factors that could be considered when deciding the exemptions are transactions for a known beneficiary or a specific type of transaction, which do not necessary fall into the “white list” of the customer but that may come from a “white list” of the system, as well as those transactions in line with customer’s behaviour factors. For example, the white list of the system can be dynamically created and periodically re-evaluated from the common characteristics of genuine payments identified by a specific payment institution.

An additional criteria could be the combination of key factors, also considering the behaviour based characteristics detected through specific tools.

An efficient fraud risk engine - besides switching low risk transactions to the list of exemptions, scoring the risk for raising alerts and additional controls and other related actions within the payment antifraud engine -could also be extended to help the business sharing the user experience and thus creating best practices for other activities.

The clarification regarding the protection of users' personalized security credential is welcome.

We are of the view that user’s personalized security credentials must be properly treated, in particular when the user selects a third party provider. Also, in this case it is very important that the Payment Service Providers (as owner of the user’s credential) should be alerted and warned on real time.

Protection of credentials is also important on e-IDAS perspective which would allow the use of the same credentials either for online payment services or for e-identity purposes.

In addition, we would recommend the EBA to clearly specify the list of “sensitive payment data”.

Additional risks, with regard to the protection of personal data, are related to the user’s ability/knowledge/awareness to identify cases or situations such as phishing or fake/fraudulent third party websites. The user may not be able to recognize the clone site in which he is entering his personal security credentials.

A subset of personal data transmitted through different channels to the owner of the personalised security credentials (in this case the PSP) helps for a safe transmission.

In our view, the use of a certification or evaluation by third parties in this situation should not be the only or the best alternative. We believe that payments institutions should not be constrained or obliged to share their security solutions to a third party. We are of the view the use of guidelines and/or an audit/assessment of the payment institution’s security solutions would be preferable.

The most critical phase is during the execution of the payment: in this phase the user does not lose control of his/her credentials but allows the payment to be redirected, and properly authorized (e.g. action of MITM (man in the middle) malware).

Another critical phase is when data is accessed by a third party payment service. (TPP).

In addition to the abovementioned points, in terms of security we would like to highlight the “API layer” (the concept of Open Bank) which is a topic that is getting now more attention although still in its infancy. We deem that clarifications in terms of reference standards, models, technologies and implementation practices for API layer are necessary.

The future RTS should clarify the following points:
• Regarding point A, in our view standard “common” and “open” definitions, should not be defined from scratch. Definitions could be stated using international standards already consolidated.
• Regarding point B, RTS should clarify which existing methods for identification of entities could be used (e.g., certificates issued from a Certification Authority) in order to avoid an additional burden on future implementation.
• Regarding point C, RTS should specify or suggest a list of secure (by design) encryption algorithms and a list of secure communication protocols.
• Regarding point D, RTS should definitely include a specific list of which the available services (split for AIS and PIS) should be (not only as examples)
• Regarding point E, RTS should include details on when, how and who can access operation/transaction data to perform the security control, in order to ensure privacy of the payment service user (PSU) and avoid internal threat. Moreover, existing international standard frameworks should be leveraged as far as possible.
• Regarding point F, RTS should include requirements to evaluate the adoption of a communication middle-layer technology that may ease the interoperability between existing systems while reducing efforts for implementation.

The “NIST Special Publication 800-53 Revision 4” should be taken into account. It’s an open and common framework for implementing security and privacy controls in US Federal Systems and Organization, which properly complies with security requirements for the Financial Sector.

In order to securely integrate other innovative business models than the one explicitly mentioned under article 66 and 67, we recommend that a European body is appointed in order to allow proper governance and manage such a need as appropriate.

This body could also organize scheduled workshop initiatives, with round tables, propose/discuss changes on requirements to enhance them or to ensure that they can integrate new business models. The round table should be composed by market players, ISPs (internet service providers), big IT players (i.e. well-consolidated leading vendors of IT solutions, vendors of IT products and solutions) and Universities.

In general, it should be considered that the adoption of a common open standard of communication can bring benefits, however it could also be exposed to system’s vulnerabilities: by their nature, a possible native bug or vulnerabilities of the standards can affect the entire system at the same time. Therefore, it should be permitted to each PSP to extend/customize the standard, within specific or pre-established limits, in order to contrast possible vulnerabilities (i.e. Open standard SSL encryption).

In this case the “qualified trust services” are not under the control of PSPs, which means that the system is not aware about the security level of these kinds of services, therefore PSPs have to trust “qualified trust services”. Hence, the “qualified trust services” should comply with strict requirements and certifications included in the EBA’s RTS as well as to be subject to an authority who guarantee their services.

In the case that AIS and PIS choose to make use of “qualified trust services” which are not compliant with the requirements set up by the RTSs, then the use of qualified trust services by the AIS and PIS could represent a vulnerability within the payment’s supply chain thus effecting the functioning of the entire system.”