1. ARTICLE 1.3(E): “...prevent, detect and block fraudulent payment transactions before the PSP’s final authorisation. These mechanisms shall take into account, …”
We understand and support the conclusion that risk measurements are part of the SCA procedure.

PROBLEM: We argue that the current proposed article to prevent, detect and block fraudulent payments hampers innovation and does not cater for future possibilities since it is too prescriptive and does not cater for a targeted approach of fraud prevention methods.

PROPOSAL: “These mechanisms may take into account:...”

2. AUTHENTICATION VERSUS AUTHORIZATION:
PROBLEM: There is no clear differentiation between authentication and authorization in the RTS implying confusion and uncertainty.

PROPOSAL: Include distinction between authentication and authorization

3. CONSENT MANAGEMENT:
PROBLEM: There may be conflicts between the consents given by the PSU to his ASPSP, as account keeper (as mentioned in the rationale 3b), and to a PISP/AISP. It is particularly essential in the context of exception to the SCA.
Example: the PSU has withdrawn a given consent and communicated this to his ASPSP without informing the PISP.

PROPOSAL: The consent given to the ASPSP must prevail to avoid any conflict between the instructions given by the PSU to his ASPSP and to a PISP/AISP.

4. RATIONALE 19.A) “The only situation when the transaction would be authenticated within the sphere of competence of the PISP is when a PISP issues its own personalised security credentials for the user, in place of the credentials issued by the ASPSP. This would however require a prior contractual agreement between the PIS and the ASPSP on the acceptance of such credentials by ASPSP.”

PROBLEM: If this requirement remains not specified explicitly then there would be no enforcement of this prior contractual agreement.

PROPOSAL: We suggest including Rationale 19.a) in a specific article in the RTS.

5. ARTICLE 6.3: “For the purposes of paragraph 2, the mitigating measures shall include, … the implementation of separated trusted execution environments inside the multipurpose device; …”

PROBLEM: We consider that it is better to list some examples that may be used, instead of the mechanism that shall be used. The term Trusted Execution Environment is a (too) specific defined term in the Global Platform standard.

PROPOSAL: “For the purposes of paragraph 2, the mitigating measures may include, … the implementation of secure environments inside the multipurpose device; …”

ARTICLE 2.2.B: We understood that Article 2.2 has to be read in the spirit of wanting to prevent man-in-the-middle attacks. The goal is to come to a model in which fraudulent activity is prevented by making sure that a breach during the initiation does not lead to a breach during the authorization.

PROBLEM: There are however many alternative mechanisms available to ensure the confidentiality, authenticity and integrity of the information displayed to the payer. We believe that such mechanisms are equally effective as your proposal as laid down in article 2.2.(b) in creating an adequately secured and protected environment to display the amount and the account number of the payee, and assuring the integrity of this data towards the PSU and the ASPSP.
These mechanisms could include, but are not limited to:
• Secure Element (SIM or dedicated chip) for storage of sensitive data, accessible only by PSU and authorized app
• App-separation / sandboxing
• Remote security updates, to prevent or react on possible weaknesses
• Hardening of an app / secure coding
• White-box cryptography
• Device binding (secure activation of an app for use by only one PSU on only one device), based on continually refreshed data elements or challenge/response
• Detection of mobile malware and fraud on the device
• App-store monitoring (for malicious apps)

It is very important that the Regulatory Technical Standards are future proof, technologically neutral and principle based. Our suggestion is therefore to leave all technical options open and to not prescribe just one particular mechanism to ensure the confidentiality, authenticity and integrity of the information displayed to the payer.

PROPOSAL: We therefore propose to delete the last sentence of article 2.2(b) in which EBA prescribes that the channel, device or mobile application through which the information linking the transaction to a specific amount and a specific payee is displayed shall be independent or segregated from the channel, device or mobile application used for initiating the electronic payment transaction.

Proposal as alternative regulatory option: Article 2.2 (b): “the confidentiality, authenticity and integrity of the information displayed to the payer through all phases of the authentication procedure including generation, transmission and use of the authentication code.”

PROBLEM: Limiting the exemptions to a small number of fixed rules means that a large amount of transactions will be classified as requiring SCA (eg. card transactions with contact without PIN in parkings and tollways, white list of bank for credit transfers to trusted beneficiaries eg. public institutions and utilities…) even though we would have technical means to qualify many of them as low-risk and would be willing to allow them without SCA.
The side effect of this “excessive use of SCA”, next to a negative impact on the user experience, is also a negative impact on the transaction security : the customer does not see SCA as an exception linked to a higher risk transaction deserving his full attention but as a plain annoyance which he performs without giving it a second thought.
Furthermore, the reasoning that such a risk-based approach “reduces predictability for the TPP” is flawed anyways since art 1.3 e mandates a risk scoring post SCA (or exemption) that can result in the transaction being refused.
Innovation and future developments would be blocked

PROPOSAL: We consider that the ASPSP, as account keeper, is the best placed to decide on the need for applying SCA, as it is the case today. Moreover, there would be no discrimination or a different user experience when the PSU accesses directly an ASPSP or indirectly via PISP.

We understand that the application of the exemptions is optional for the ASPSP. The mandatory character would be problematic in following cases:

1. PROBLEM for consumer clients: we agree to apply the exemptions integrally to ensure a level playing field. Applying SCA on transactions with high risk is in most of the cases much better than blocking them: it avoids extra traffic of re-initiation of the transaction and is much more customer friendly, while maintaining the high level of security.

PROPOSAL: In case of (a suspicion of) fraud the ASPSP wants to be able to apply SCA.

2. PROBLEM for non-consumer clients: we are of the opinion that applying the exemption mandatorily is not suitable. These clients have implemented authorization matrixes which are integrated in our authorisation procedures/SCA and apply to all of their payments and even to the level of access they have to electronic channels. All put in place with the rationale of enhancing the security and improving the protection against fraud seeing the interests at stake.

PROPOSAL: As a consequence we consider that ASPSPs should have the liberty to apply SCA for non-consumer clients in relation to the payments initiated through or the access granted to electronic payment channels at all times.

3. ARTICLE 8.1.A: We agree that in some rare circumstances SCA is logical and needed once every month.

PROBLEM: From market experience and user data information we however know that the large majority of our customers is checking their account information from the same location and via the same device. We consider that this information provides sufficient safeguards to allow for a period of at least one year without SCA for the consultation of account information from a security perspective.

PROPOSAL as alternative regulatory option:
Article 8.1 (a): “the payer accesses exclusively the information of its payment account online, or the consolidated information on other payment accounts held, without disclosure of sensitive payment data. The application of strong customer authentication shall not be exempted where: i. the payer accesses the information of its payment account online, or the consolidated information on other payment accounts held, for the first time, ii. the payer accesses the information of its payment account online, or the consolidated information on other payment accounts held, later than a period determined by the ASPSP based on a risk assessment.

1. ARTICLE 19.2.A: “the interface shall enable… to start the authentication procedure”

PROBLEM: In order for this fraud detection to be as efficient as possible, and in order to protect the “level playing field” principle, ASAPS must receive from PISPs transaction and contextual data mentioned in article 1.3.e and also transaction type (P2P, P2M, …) transaction mode (F2F, remote) beneficiary data (merchant name, location, activity… ) and the same contextual data that is available in the ASPSP’s own channels (device type, OS, location, network…). That set of data would allow the ASPSP to score the transaction risk from PISPs with the same level of efficiency as the risk from the ASPSP’s own channels (resulting in the same, as low as possible, rate of transaction rejections).

PROPOSAL: Include the principle of this information exchange in article 19.2.a

2. ARTICLE 19.3: “Account servicing payment service providers shall ensure that their communication interface uses ISO 20022 elements, components or approved message definitions…”
We agree that standardisation is highly needed to ensure interoperability.

PROBLEM: Several standards are available in the market and/or will be developed which can be used in the communication between PSPs.

PROPOSAL: We therefore propose that the RTS remains neutral in prescribing industry standards with one clear exemption: the usage of ISO 20022 data definitions should be the basis. ISO20022 is the only industry standard data definition for payments and can be used in all kind of standard message definitions.

Proposal as alternative regulatory option:
Article 19.3: “Account servicing payment service providers shall ensure that their communication interface uses ISO 20022 data definitions, if available ...”

ARTICLE 20.1: “For the purpose of identification, payment service providers shall rely on Qualified certificates for website authentication as per article 3(39) of Regulation (EU) No 910/2014.”

PROBLEM: As mentioned in rationale 77 we have to assume that there will be qualified trust service providers designated under eIDAS by October 2018. Febelfin assumes that identification also entails the authentication.

PROPOSAL: The concerned authorities (EBA, ECB and EC) and ENISA should follow-up the designation of qualified trust service providers under e-IDAS and make sure that there is at least one/two e-IDAS qualified trust service providers at least 6 months before the entry into force of this RTS.

Proposal as alternative regulatory option:
Article 20.1 : “For the purpose of identification/ authentication, payment service providers shall rely on Qualified certificates for website authentication as per article 3(39) of Regulation (EU) No 910/2014.”

ART.22.5.(A): “Account information service provider shall request information from designated payment accounts and associated payment transactions:…”

PROBLEM: EBA should also take into account that problems with the communication interface is not only related to the times the AISP requests information of the customer, but also to the amount of information/data that could be processed in a single request and the number of requests in a certain time window (possibly from different AISPs).

PROPOSAL: “Account information service provider shall request information from designated payment accounts and associated payment transactions of the previous day and only once the same information: … ”