We approve EBA’s reasoning. We however would like to raise the following comments.
In order to provide the best user experience, we approve EBA’s approach for the usage of a unique code that covers PSU authentication and authorizes the transaction.
In relation to rational 17 (page9) of the Consultation Paper, EBA suggests the signature of an e-mandate should fall in the category of article 97(1)(c ). This statement is actually not addressed by any of the articles of Chapter 1 of the draft RTS. This leaves the Members States with room for interpretation.
Moreover, and as pointed by EPC at the ECB Workshop on Electronic Mandates held on September 28, 2016, any obligation to run SCA on e-mandate made to PSP would create a non-level playing field with non-PSP providers of e-mandate solutions. If a complementary disposition is inserted in the RTS about e-mandate, similar obligation should be applied to non-PSP suppliers too. EBA may envisage to state that only authorized PSP are allowed to run an e-mandate service, given such a service requires an access to the payer’s information held by the ASPSP.
An alternative would be to maintain the draft RTS as it is, but erase any comment that EBA may consider qualifying that e-mandate falls under 97(1)(c ). Article 74(2) PSD2 arbitrates already the responsibilities of the players in such a case.
We agree with the EBA that the dynamic linking requirements should remain neutral. However while the channel or mobile application could be segregated there is no method to control and guarantee segregation on the device.
In relation to rationale 26 (page11) of the Consultation Paper, we are convinced that other techniques than the ones mentioned in this rationale are available to create an adequately secured and protected environment to display the amount and the account number of the payee, and assuring the integrity of these data towards the PSU, on a single smart phone with a single app. These techniques include, but are not limited to:
- Secure Element (SIM or dedicated chip) for storage of sensitive data, accessible only by PSU and authorised 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)
We would also welcome further guidance from the EBA on what would represent a valid authentication code.
We strongly believe that any exemptions should be systematically and consistently applied to all payment methods in order to secure a level playing field and avoid unintended consequences of driving payments to less-secure options.
By way of example, the RTS should ensure that ASPSPs cannot use the exemptions to preclude PIS or other providers from having access to the relevant data.
We are concerned that the EBA’s decision to exclude the provision of any SCA exemptions based on a transaction risk analysis performed by the PSP will have a very detrimental impact to existing PSP service delivery models. This EBA decision has the effect of restricting existing PSD2 text that in PSD2 Article 98 section 3 sub a supported exemptions based on “the level of risk involved in the service provided”. This could also be regarded as narrowing of the scope of a maximum harmonisation Directive, and one that is not in the gift of the EBA in Level 2 text.
We would strongly support the specification of a parameter dealing with transaction risk analysis for the exemptions as it provides ASPSPs the possibility to do a liability shift to the merchant if the risk is too high. PSPs on the acquiring side or even merchants are well-positioned to accept that liability while relying on the transaction risk analysis elements already mentioned.
At a broad level the following criteria could be considered:
• Consumer device level (device type, OS/browser, malware (not) present, rooted / jailbroken, device identification, etc.)
• Connection level (direct / indirect, IP-address, IP GeoLocation, ISP, etc.)
• Application level (language of the application, etc.)
• Payer level (profiling, user interaction profiling, click-path profiling, etc.)
• Transactional level (history, beneficiary account, amount, country, urgent/non-urgent payment, etc.)
• Payee or beneficiary level (profiling)
• Big data (data related to fraud / threat environment, customer claims).
In addition, the criteria for this transaction risk analysis should be principle-based. It is up to the PSP to decide on the exact capabilities of the fraud detection based on its own risk analysis and appetite.
Furthermore, more careful consideration should also be given to the nature of the customer. Companies might have different requirements than consumers, and do not require the same level of protection. The SCA regime should take this into consideration. Indeed, both PSD and PSD2 recognize the need to apply different levels of protection between consumers and legal persons, as emphasized in recital 53: “As consumers and undertakings are not in the same position, they do not need the same level of protection. While it is important to guarantee consumer rights by provisions from which it is not possible to derogate by contract, it is reasonable to let undertakings and organisations agree otherwise when they are not dealing with consumers.” Specifically, articles 38 and 61 permit contractual derogations to respectively all of Title III and most of Title IV for payment services provided to persons other than consumers, hence covering:
- legal persons, and
- natural persons acting for the purpose of their profession or business (which, by extension, appeals to the notion of commercial card defined in the Regulation (EU) 2015/751 on interchange fees for card-based payment transactions
Legal persons usually use internal controls mechanisms allowing to authenticate the person initiating the payment order and his/her capacity to act on behalf of the company. Such controls prove particularly robust through processes to follow, third-party signature requirements and independent controlling bodies. Furthermore, both undertakings and individuals acting on their behalf using payment instruments such as commercial cards usually also benefit from a much better protection than consumers through their insurance policies.
We hence support an exemption from SCA under article 8 for payment transactions where (i) the payer is a legal person or ; (ii) a natural person acting for the purpose of their profession or business.
We also believe that proportionality to actual risks is key in designing the standards and their exemptions. In this perspective, we support the first exemption (article 8. 1. a). Indeed, access to accounts without disclosure of sensitive payment data does not trigger risks for the payment service user, nor for the payment service provider. However, the limits to this exemption that are defined under the proposed article 8.1 (i.e. first-time access and access later than a month after last SCA) do not appear to be justified by the risk entailed by such accesses to accounts, and hence appear disproportionate.
We would therefore encourage the first exemption not to be limited by the two additional criteria.
We are concerned about the feasibility to implement such limits, notably how to inform the PISP that a given payer has reached its cumulative limit. These limits could be required on a given PISP – i.e. impose a cumulative limit per payer and per PISP, but not multi-PISP.
We believe that the transaction thresholds for remote transactions are low and should be aligned on the threshold practiced on contactless cards, or anonymous electronic money.
We believe that this area of security should be harmonized by introducing security methodology and label such as the use of the PCI certification processes.
The dedicated interface must be mandatory in order to ensure a level playing field, ensure competent authority control, and track access to payment account by AISP and PISP providers.
Indeed, ISO20022 is the standard that most of the new payment projects across the world are considering. This allows as well the complementarity with European Instant Payment project.
The scope/timeline of adoption of e-IDAS by the private sector and by different EEA countries is unclear. Some countries have not yet any qualified trust service provider.
We would have welcomed a stronger role of the EBA there, in continuation of his responsibility to maintain the authorised PSP registry. We think EBA could be this qualified trust authority. That would simplify the process of getting the rights to run such a service, and ensure the best level-playing field.
Alternatively a more ambitious / distributed cryptographic scheme could make sense (based on Blockchain for instance).
We would be in favour of increasing the number of automated AISP payment account requests that will be serviced by the ASPSP to one per hour for a given payment account. We feel that this provides appropriate balance between AISP service priorities and the desire of the ASPSP to ensure optimal performance of the communication interface it provides to a payment account management platform