Response to consultation on RTS specifying the requirements on strong customer authentication and common and secure communication under PSD2
Go back
The draft guidance places disproportionate barriers to customer authentication and risks stifling the development of the e-commerce sector in Europe. Data shows that overly cautious measures, which add too much complexity for consumers, result in fewer e-commerce transactions. The draft rules have the potential of diverting investment away from the development of innovative and secure products and services in the EU because the scope for creative solutions is much reduced.
We strongly recommend reconsidering the current approach to take into account the criteria set in the PSD2 mandate to the EBA (Art. 98). We expect that the measures proposed on SCA should (i) not adversely affect the user and merchant experience, and (ii) remain business-model and technology neutral.
1. Impact of Strong Customer Authentication on the user and merchant experience
PayPal recommendation
The RTS’s proposed approach to Strong Customer Authentication (SCA) is likely to have a negative impact on the customer and merchant experience, and hence on e-commerce activity. Mandating a blanket application of SCA does not reflect the actual risk for customers when using payment services online and introduces unnecessary friction in consumers’ shopping experience. Usability for consumers must be a core consideration in the draft guidance to promote the e-commerce agenda. PayPal recommends an approach which balances security concerns with the customer experience, using all available evidence.
Rationale
• The application of Strong Customer Authentication, regardless of the actual security risk of the service provided, is disproportionate, introduces undue friction in the setup and payment process for customers and decreases merchants’ ability to customize the check-out process in a secure and user-friendly way, as demanded by customers. The data shows that the consequences are 1) customers are less likely to complete the authentication process for simple transactions, 2) digital merchants will see greater transaction abandonment and 3) merchants’ eagerness to invest to improve the check-out flow (and therefore the customer experience) will decrease because they will be obliged to apply SCA to all their transactions. This would negatively impact the development of digital payments and e-commerce - rather than promote its growth - contradicting the policy objectives of the EU Digital Single Market strategy.
• In the case of e-wallets such as PayPal, consumers will be faced with two back-to-back requests to perform Strong Customer Authentication: first for the link to the wallet from the user’s bank account or card, and second for the payment transaction from the wallet to the merchant. This unnecessary complexity risks jeopardizing the usage and development of digital wallets across the EU, despite the fact that they are increasingly popular with consumers and merchants.
• PayPal’s data on the application of 3DS security on e- and m-commerce transactions in Q1 2016 demonstrates that, on average, an additional 40% of transactions were abandoned following the introduction of 3DS. In Germany – a country familiar with SCA – this figure rises to 51%. The numbers clearly show customers’ frustration with the cumbersome authentication procedure. In PayPal’s experience, company data on the application of PayPal’s ‘One Touch’ (which allows for a seamless payment experience by staying logged in on a specific device: see https://www.paypal.com/webapps/mpp/one-touch-checkout) indicates that massive user adoption of a streamlined procedure did not result in higher fraud. In fact, the fraud levels of that product have been consistently lower than the (already low) fraud level for the regular PayPal product. This can be explained by the fact that PayPal deploys extensive risk management procedures specific to One Touch to ensure its security, while providing increased convenience to customers and merchants alike.
• Payment security rules must consider the impact on consumers and merchants. By making it overcomplicated to pay for goods and services online, there is a real risk that consumers will be less prepared to purchase online, potentially shopping only for goods unavailable offline, or by limiting their purchase to the merchants that frame their transactions as recurring payments, thereby ultimately neglecting smaller merchants, which will be unable to attenuate the friction caused by the SCA rules. In this scenario, consumer choice and competition will pay an unduly high price to security. Eventually, the most secure transaction will be the one that never goes through.
2. Strong Customer Authentication should be business-model neutral (Art. 98. 2 (d))
PayPal recommendation
Payment Service Providers should be allowed to develop innovative authentication solutions that are both secure and convenient for users, by 1) making the use of an authentication code optional, in line with the requirements in the PSD2, and 2) allowing behavioural data to be used as an inherence element within the SCA framework. A one size fits all approach should not be pursued unnecessarily. This smart and nimble deployment of SCA would benefit both consumers and merchants, ensure that payment security integrates new technologies, and ultimately help achieve the EU Commission’s goals of creating a dynamic and attractive Digital Single Market in the EU.
We suggest redrafting Art. 1 as such:
Article 1 - Authentication procedure and authentication code
1. For the purposes of the application of strong customer authentication in accordance with Article 97(1) of Directive (EU) 2015/2366 the authentication procedure may result in the generation of an authentication code each time that the payer accesses its payment account online, initiates an electronic transaction or carries out any action through an interactive remote channel which may imply a risk of payment fraud or other abuses.
2. Where appropriate, the authentication code shall be characterized by security features ensuring that no information on any of the elements of strong customer authentication categorized as knowledge, possession and inherence can be derived from the disclosure of the authentication code.
3. The strong customer authentication procedure shall include mechanisms to:
(a) ensure that any of the elements of strong customer authentication can be identified as incorrect, where the authentication procedure has failed to generate an authentication code for the purposes of paragraph 1;
(b) determine the maximum number of failed authentication attempts that can take place consecutively within a given period of time and after which the access to an online payment account, the initiation of an electronic payment transaction or the possibility of carrying out any action through a remote channel which may imply a risk of payment fraud or other abuse are temporarily or permanently blocked. Where the block occurs during the course the current session, the number of retries and the time period of the block shall be established taking into account the characteristics of the service provided to the payer and all the relevant risks involved. Where the block is permanent, a secured procedure must be established allowing the payer to regain access to and unblock the electronic payment services;
(c) protect communication sessions against the capture of data transmitted during the authentication procedure or manipulation by unauthorised parties, including but not limited to by relying where applicable on HTTP over TLS;
(d) prevent, detect and block fraudulent payment transactions before the PSP’s final authorisation. These mechanisms shall take into account, but not be limited to:
i. parameterised rules, including black lists of compromised or stolen card data,
ii. signs of malware infection in the session and known fraud scenarios,
iii.an adequate transaction history of the payer to evaluate its typical spending behavioural patterns,
iv. information about the customer device used,
v. a detailed risk profile of the payer and/or the payer’s device.
Rationale
• The draft guidance is disproportionate relative to the specific requirements set out in the Payment Services Directive 2 (PSD2). The RTS goes beyond the requirements in the level 1 text by requiring that SCA result in the generation of an authentication code that is accepted only once for any given Payment Service User: authentication codes are not mandated in art. 97 of the PSD2, and recital 96 notes that strong customer authentication “may result in authentication codes such as one-time passwords”: they are therefore mentioned as just an example. Strong Customer Authentication as defined in the PSD2 can be delivered through the combined use of independent, secure, static authentication elements (e.g. passwords, device-specific certifications or credentials, biometrics etc.) without the need for one-time authentication codes. Requiring their use simply adds friction to the customer experience, with no commensurate security benefits.
• The PSD2 mandates the RTS to be neutral towards different business models. This can only be achieved by catering for the payment industry’s heterogeneous and competitive nature: different Payment Service Providers have access to different data sets to implement the three elements supporting the SCA procedure. Banks, for instance, can authenticate users based on their direct relationship with the user. At PayPal, our data algorithms and risk management capabilities, coupled with our ability to see both ends of the transaction (the accounts of the payer and the payee are held by the same PSP), provide us with invaluable data to identify and authenticate users.
• A one size-fits-all approach to payment security is not appropriate in the heterogeneous EU payments market: such an approach will have the adverse effect of decreasing competition in the payment market, to the detriment of smaller players who may not be able to make the necessary investments and adjustments to smoothen SCA inconveniences. The one-size-fits-all approach in the RTS moreover favours PSPs who also provide computing hardware, while disadvantaging banks and wallets. Such an approach makes it easier for fraudsters to attack with large scale effects, given that all EU payment providers will use exactly the same SCA toolkit.
• We therefore strongly disagree that behavioural data is just an “additional tool for fraud prevention” (point 29 of the rationale). Behavioural data is already successfully used for authentication purposes and is a crucial tool to meet the EBA’s declared goal to allow for “the development of user-friendly, accessible and innovative means of payments” (point 28 of the rationale). In fact, there is no real distinction between user authentication and the prevention of authentication fraud: several payment providers have developed sophisticated risk management systems that analyse specific behavioural patterns that effectively match the identity of the payer with its ‘consumer’ profile, in order to both authenticate users and detect fraud. This removes customer friction and enables smoother secure online transactions.
• Behavioural characteristics can include transaction history, habitual location, device used, preferred retailers, and other consumer habits that the PSP is able to collect, in accordance with EU data protection and privacy rules. Because behavioural attributes can be collected and assessed over a period of time, they are less susceptible to theft, malware, spoofing, or malicious replication than something the user has, knows, or is. Behaviour-based characteristics have been successfully used by PSPs to identify cases where control of an account has been lost or compromised, and it is increasingly common and accepted throughout the industry that behavioural evidence can be used as an independent inherence element. See, for example, DARPA’s “active authentication” programme summarised at http://www.darpa.mil/program/active-authentication.
3. Strong Customer Authentication should be technology-neutral (Art. 98. 2 (d))
PayPal recommendation
The RTS should support a SCA process that is technology-neutral and future-proof, by defining the security objectives to be met, rather than the specific solutions. The current drafting is so narrow that only one existing technology qualifies. True technology neutrality would enable more innovative and comprehensive approaches to payment security, independent of the respective channel, platform or method. It will also let PSPs take account of all the evidence relevant to authentication, including behavioral data. This approach would significantly stimulate PSPs’ ability to detect and respond to new security threats as they adapt their risk models to an ever-changing security landscape.
Rationale
• The current drafting of Articles 1 and 2, by specifying the SCA procedure in a way that neglects the other technologies that allow for SCA (and dynamic linking) to be performed as securely, is detrimental to innovation as it removes the incentive and even the possibility to develop and invest in these innovative technologies.
• The RTS points towards processes and techniques that reflect the world that existed long before the SecuRe Pay Forum first started looking at the security of online payments. Since then, the industry has developed authentication techniques that reflect more accurately the current state of the payments market. The approach in the RTS regrettably ignores the data-rich environment of modern e-commerce, as well as the sophisticated digital technologies currently in use, which are moving away from binary authentication methods towards more comprehensive approaches that minimize the burdens on consumers, while ensuring greater nimbleness to face ever-changing security threats.
• The diversity of authentication and security methods in the digital financial area is probably the strongest protection from a holistic point of view. Defining very specific technical security parameters forces payment providers to deploy the same few authentication methods, on which fraudsters would be able to focus their efforts to reach a large consumer segment. To that point, David Emm, principal security researcher at Kaspersky, recently told the BBC (see at the end of this article: http://www.bbc.com/news/technology-37585247) that banks should consider applying a multitude of cybersecurity solutions to minimise unauthorized access to such information".
• More generally, the draft RTS focusses on the traditional e-commerce environment, where buyer and seller typically do not meet (i.e. electronic payments that are remote are treated differently than those occurring at the point of sale). However, the distinction between online and offline transactions is increasingly obsolete. This change is accelerated by the development of services available via mobile devices, including payments. The development of mobile and omni-channel commerce and the ensuing blurring of commercial channels, which used to be clearly distinct, create obvious challenges for regulators. However, we expect these new models to be reflected in a future-proof legislative framework, which enables safe and efficient commercial transactions.
• In addition, the provisions on SCA force payment providers to host cryptographic algorithms in users’ hardware or software. Yet, the weakest link in the authentication procedure is often the user (devices or passwords can be lost or stolen for instance) (e.g. HBCI in Germany).
To conclude, the recent Dutch experience demonstrates that online fraud can be effectively fought with a mix of measures which do not necessarily involve only the deployment of restrictive Strong Customer Authentication. A study by the Dutch Banking Association and the Payments Association shows that the damage caused by fraud in online banking during the first half of 2016 decreased by 82 % compared to the last six months of 2015. Reasons include greater cooperation between the payments industry and regulators, better consumer education and the deployment of detection systems based on transaction monitoring (https://www.betaalvereniging.nl/nieuws/nauwelijks-fraude-internetbankieren/). This experience not only demonstrates that authentication outcomes are measurable, but also that a broader approach to SCA can yield excellent results."
PayPal recommendation
We suggest reviewing Art. 2(1) to highlight the distinction between the authentication code and the authorisation code.
We suggest redrafting Art. 2(1) as such:
Article 2 - Strong customer authentication procedure with dynamic linking
1. For the purposes of the application of strong customer authentication in accordance with Article 97 (2) Directive (EU) 2015/2366, the authentication procedure shall provide that:
(a) The payer is made aware at all times of the amount of the transaction and of the payee(s);
(b) The authorisation code shall be specific to the amount of the transaction and the payee agreed to by the payer when initiating the transaction.
Rationale
• We are concerned that Art. 2 mixes up the concepts of the authentication code and the authorisation code: the authentication code referred to in Art. 1, and which we suggest should be optional, simply allows customers to authenticate themselves. The authorisation code, and the subsequent dynamic linking requirement, applies only to remote electronic transactions (PSD2 Art. 97(2)) and its aim is to authorise the transaction after the customer has authenticated. In practice these two processes are distinct, even if they occur simultaneously.
• We would welcome clarifications regarding the reference to “authenticity” in Art. 2.2(a): does this refer to the payee or the data regarding the payee? If the former, we would like to point out that the authentication procedure provided by the ASPSP can only ensure the confidentiality and integrity of transaction data. Ensuring the authenticity of the payee is only possible if the information is verifiable during authentication by the user or the ASPSP, which is not the case.
2. The requirement that the “channel, device or mobile application through which the information linking the transaction to a specific amount and a specific payee is displayed is independent or segregated from the channel, device or mobile application used for initiating the electronic payment transaction” is concerning.
PayPal recommendation
The viability of using mobile devices’ separate trusted elements depends on the openness of the device’s operating system, which must be ensured to prevent device makers from abusing a strong market position by foreclosing access to payment providers. We would recommend the EBA to introduce a fair access clause to that effect.
Rationale
• As drafted, the RTS will require each payment provider to distribute a separate trusted element to each consumer: either as a separate token or within the user’s mobile device. While the first option is burdensome on the consumer – they will need to have one separate, trusted element for each payment provider that they choose to use – the latter is only viable if the device makers provide payment providers with access to the separate trusted element on the device. Indeed, technologies currently in use can easily guarantee independence within the same mobile phone or tablet, with no need for additional devices, through the use of separate trusted elements or ‘host card emulation’ technologies. For example, a user could confirm a transaction by introducing a PIN (something only he knows) or using his fingerprint (something he is) on a mobile device that can be recognised and validated, receiving on his previously enrolled authentication application (the same device, or a different one) a dynamic code that identifies the transaction, amount, payee, etc. This however effectively rules out devices other than mobile phones or tablets: personal computers, for example, do not have separate secure environments.
• It is therefore not clear that payment providers will be able to rely on the user’s available secure device, their mobile phone or tablet, without having to distribute separate secure environments (e.g. tokens) for non-mobile users, devices which are far more likely than a phone to be forgotten or lost. Indeed, tokens come at a cost that will tend to be passed onto the consumer. Also, consumers will have to be educated to enable them to use the token, and they will need to quickly notify it as invalid if it is lost. In many cases, activation, setup and usage fail because tokens are difficult for consumers to manage and loss of tokens will go unreported and quite likely unnoticed.
• Digital payments users legitimately expect to access whichever account they choose from their devices, and to initiate, pay and confirm a transaction using the same device (i.e. mobile phone). Besides creating an unsustainable customer experience and extra expense - with no additional security benefit - this requirement is not cost-effective for payment providers unless the secure environment that most consumers already have is available on a fair, non-discriminatory basis to all authorised PSPs.
Behavioural data should be included amongst the requirements for Strong Customer Authentication, as part of the inherence element (something that the user is).
We suggest redrafting Art. 5 as such:
Article 5 - Requirements related to authentication elements categorised as inherence
1. Authentication elements categorized as inherence shall be characterized by security features such as algorithm specifications, biometric sensor and template protection features ensuring resistance against the risk of sensitive information related to the elements being disclosed to unauthorised parties. These security features shall also guarantee a sufficiently low likelihood of an unauthorised party being authenticated as the legitimate payment service user.
2. The use of elements categorized as inherence shall be subject to measures ensuring that the devices and the software provided to the payer provide resistance against unauthorised use of the elements through access to the devices and software.
And we suggest the following new recital:
[new] (5) Relating to the inherence element, modern authentication technologies can minimise the inconvenience of the authentication process by effectively leveraging the multiple elements related to the digital interaction of users, including users’ behavioural-based characteristics. These technologies have been successfully used by PSPs to identify cases where control of an account has been lost or compromised. Behaviour is a robust indicator of identity and can be very effective to authenticate the PSU within the framework of strong customer authentication.
Rationale
• See response to Q1 for the rationale.
• We would also like to point out that behavioural and transactional data do not suffer from the vulnerabilities of the other factors (possession and knowledge) because they are recorded by the payment provider as events occur, and are stored beyond the reach of the user’s ability to manipulate or unintendedly compromise them. Under a number of EU regulations – including the Network and Information Security Directive and the General Data Protection Regulation – the payment provider is moreover obliged to store such data in a secure way.
• We suggest replacing the phrase “guarantees” in Art. 5(2) as no technology or security measures can guarantee 100% resistance against security threats: instead, we would suggest using the term “provide”.
PayPal recommendation
We recommend aligning the provision on remote electronic payments with the reality of digital payments by ensuring a robust risk-based approach, together with exemption thresholds that are aligned with the PSD2 and reflect the e-commerce market reality.
Rationale
• We do not understand the basis and the rationale for the remote electronic transactions exemption thresholds in Chapter 2. A limit of 10 EUR per transaction (and 100 EUR cumulatively) would oblige users to go through the unfriendly experience of SCA for almost any digital payment, regardless of the actual risk posed. This approach will have a detrimental impact on e-commerce, which would be at odds with the EU Commission’s efforts to foster the digital economy’s growth in the EU. We therefore suggest aligning these thresholds to those for low-value transactions in Art. 42 of the PSD2.
• We also wonder what the rationale is behind the two sets of exemption thresholds under Art. 8.1 (contactless transactions) and Art.8.2 (remote transactions), knowing that fraud can occur both in a contactless and online environment. It is also difficult to reconcile the thresholds of Chapter 2 with those of Art. 3 (l) (the so-called digital exemption) of the PSD2. Indeed, telecom providers are exempted from the PSD2 (and therefore the RTS) for transactions up to 300 EUR. This means that consumers can purchase digital content through their telecom provider free of Strong Customer Authentication for an amount 30 times higher than that of consumers making the same purchase via a PSP.
• From a security perspective, the value of the transaction taken in isolation is only one factor out of many that describe the actual level of risk posed by the transaction: other elements need to be taken into account, such as location, the device used or the user’s usual pattern of behaviour, the IP address, etc. An exemption based only on the transaction value is flawed and ignores the complexity of modern digital payments, where the risk presented by the exemption can be mitigated using technologies that analyse all the information provided by the user to ensure the transaction is low risk.
2. On the exemption allowing whitelists:
PayPal recommendation
Clarifying that the whitelists mentioned in Art. 8(2)a can also be created by the Account Servicing Payment Service Provider: at the moment only the Payment Service User can generate such a list.
Rationale
• ASPSPs should be able to generate their own whitelists to reflect ongoing customer behaviour, the risk-profile of the payee, the frequency of such payments etc. This would allow for the ASPSP to apply its risk management practices to the benefit of customers’ convenience, thereby mitigating the negative impact of SCA on the customer and merchant experience.
3. On the EBA’s rationale in point 54 for its decision not to propose a transaction-risk analysis:
PayPal recommendation
The RTS should allow for exemptions that focus on effectiveness and outcomes, and encourage PSPs to develop and put in place risk-based authentication capabilities that would allow payment providers to select the most effective authentication challenge, based on the level of risk of transactions.
Rationale
• Art. 98 (2)a and (3)a of the PSD2 explicitly stipulate that the RTS should be based on “risk-based requirements” and that the exemptions should take into account “the level of risk involved in the service provided.” This mandate is not fulfilled in the draft RTS and there is no basis for the EBA’s conclusion that a transaction risk analysis would not adequately protect consumers. The EBA offers no justification in its impact assessment or cost/benefit analysis as to why it considers that reliance on a transaction-risk analysis by PSPs “would likely not sufficiently protection consumers and […] possibly harm fair competition in the payment service market”. In fact, the EBA cost/benefit analysis provides little evidence or argumentation for any of the proposed exemptions in Art. 8, nor - more generally - for all the provisions in the RTS. This approach ignores the recent developments in risk management that the payment industry has invested in to reconcile strong risk controls with a good customer experience, in compliance with the current EBA Guidelines on the security of Internet payments.
• There are multiple benefits to introducing an exemption based on risk-based authentication: (i) it makes the context assessment measures more difficult for fraudsters to understand and attack, (ii) it incentivises payment providers to continue investing in robust risk-management systems, (iii) it ensures the security response evolves to meet the ever-changing security threats, and (iv) it fosters the growth of e-commerce by deploying secure and customer-friendly solutions.
• A risk analysis approach – by making better use of the data-rich environment on the Internet and the user’s history and behaviour as evidence for authentication – would also help reduce dependence on unsophisticated users. These are usually the weakest link in the authentication procedure. A risk-based algorithm that takes into account hundreds or thousands of independently collected behavioural, locational, and habitual data points in order to authenticate a user does not depend on the user carrying out complex procedures and is significantly harder for a fraudster to manipulate or misuse.
Proposal for an efficient transaction-risk analysis process
The RTS should define auditable risk management procedures measuring outcomes (based on comparable industry standards such as ISO 27005) and enabling home state regulators to evaluate the effectiveness of methods using metrics reported by payment providers they supervise.
We believe that the payment providers’ home regulator has an essential role to play in a risk-based model: periodic reviews with the home state regulator would ensure that the fraud rate remains at acceptable levels in view of the risk. In the 4th Anti-Money Laundering Directive, for instance, the risk-based approach is based on an ongoing dialogue with the supervisors.
1) Payment providers would put in place risk management systems to effectively detect and mitigate the risks of transactions, taking into consideration a number of factors such as:
a. The level and type of risk of the underlying payment instrument, system or service provider,
b. The risk profile of the payer and payee, including their transaction history, behaviour patterns and the device / browser & IP used,
c. The context of the transaction (e.g. low value, vertical of purchase, riskiness of merchandise, habitual location of the user, frequency of security compromises, habitually used device, riskiness of IP, etc.).
2) Payment providers would then either deploy SCA or alternative methods of authentication, based on the level of the risk of the transaction.
3) Periodic reviews with the home state regulator would ensure that the fraud rate remains at acceptable levels in view of the risk. Some of the metrics that payment providers can share with regulators to measure authentication outcomes and the level of risk include:
a. Claims for lack of authorization,
b. Success in refuting such claims,
c. Authenticated cases that resulted in loss,
d. Financial loss rates,
e. Loss catch rates,
f. Transaction failure due to insufficient or invalid authentication, abandonment by customer of an authentication procedure, and other causes for the transaction not to complete.
4) With this approach, SCA would be triggered on the basis of a pre-approved level of risk, while less risky transactions would be covered by the exemption.
4. A note on the liability shift:
PayPal recommendation
We strongly disagree with the EBA’s interpretation of the application of Art. 74(2) in the PSD2. We believe that the liability shift is the backbone of payment security and the RTS should not make it a transitional measure.
Rationale
• The PSD2 does not state that Art. 74(2) only applies during the transitional period between the application date of PSD2 (13 January 2018) and the application date of the RTS under consultation (October 2018 at the earliest). We believe that the draft guidance contradicts the spirit of the level 1 text.
• Digital payment providers and merchants have developed and apply sophisticated risk management systems that allow them to calibrate the security of transactions with the actual level of risk they pose. Using the data-rich digital environment, they can effectively single out low-risk transactions from higher risk transactions, thereby triggering the authentication challenge more accurately. This greatly enhances convenience for customers, while also ensuring greater security and transaction success for merchants. Art. 74(2) provides payment providers and merchants with a huge incentive to ensure their management systems are effective: trust is a crucial element in the online space, so suffering a fraud does not only entails financial consequences (the obligation to refund customers), but most relevantly jeopardizes brand reputation and customer trust. Removing the ‘liability shift’ (and therefore imposing a blanket application of SCA) has several implications:
o Payment providers will be forced to reject transactions should the merchant fail to support SCA, at the expense of payment users. Transaction rejection is often a concerning experience for users, who are not sufficiently informed to understand the reason behind it. They might actually blame the payment service for failing to complete their online purchase!
o Payment providers and merchants alike will lose any business incentive to invest to further develop their proprietary risk management systems, leaving them unprepared to meet future security threats. For instance, there will no longer be any incentive to proactively monitor for fraudulent activity transactions above 10 EUR, as long as SCA is mandated. This will quickly make the EU payment system obsolete and more vulnerable.
o While large merchants might be able to adjust their systems to minimise the frictions of SCA, smaller merchants may not be able to make the same investments, and will therefore lose customers at check-out, which in turn will have a negative impact on customer choice and competition in the EU market.
We therefore suggest redrafting Art. 8 as such:
Article 8 - Exemptions to strong customer authentication
1. The application of strong customer authentication in accordance with Article 97(1) of Directive (EU) 2015/ 2366 is exempted where the PSP, or the payee, has elected not to apply strong customer authentication and agreed to bear any resulting financial loss unless the payer has acted fraudulently, under article 74.2 of directive (EU) 2015 / 2366.
2. The application of strong customer authentication in accordance with Article 97(1) of Directive (EU) 2015/ 2366 is exempted where:
(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 one month after the last day in which strong customer authentication was applied and no specific timeframe was agreed with the payer.
(b) the payer initiates a contactless electronic payment transaction at a point of sale within the limits of both the following conditions:
i. the individual amount of contactless electronic payment transaction does not exceed the maximum amount of 50 EUR;
ii. the cumulative amount of previous non-remote electronic payment transactions initiated via the payment instrument offering a contactless functionality without application of strong customer authentication does not exceed 150 EUR.
3. The application of strong customer authentication in accordance with Article 97(2) of Directive (EU) 2015/ 2366 is exempted where:
(a) the payer initiates a payment online where the payee is included in a list of trusted beneficiaries previously created by the payer with its account servicing payment services provider, or by the account servicing payment provider based on their risk analysis.
The application of strong customer authentication shall not be exempted where the payer creates for the first time or subsequently amends the list of trusted beneficiaries with its account servicing payment services provider.
(b) the payer initiates online a series of payments with the same amount and the same payee.
The application of strong customer authentication shall not be exempted where the payer initiates the series of payments for the first time or amends the series of payments.
(c) the payer initiates a payment online a where the payer and the payee are the same natural or legal person and the payee’s payment account is held by the payer’s account servicing payment services provider;
(d) the payer initiates a remote electronic payment transaction where all the following conditions are met:
i. the individual amount of the remote electronic payment transaction does not exceed the maximum amount of 30 Euros; and
ii. the cumulative amount of previous remote electronic payment transactions initiated by the payer without application of strong customer authentication does not exceed 150 EUR.
3. The application of strong customer authentication in accordance with Article 97(2) of Directive (EU) 2015/ 2366 is exempted where:
(a) the payment service provider can demonstrate the use of risk management systems to effectively detect and mitigate the risks related to the payment service, based on factors such as:
i. The level of risk of the underlying payment service and payment service provider,
ii. The risk profile of the payer and payee,
iii. The specific risk posed by a transaction type.
(b) National authorities shall ensure regular reviews and audits of the application of this exemption and the effectiveness of payment service provider’s risk management systems in ensuring outcomes on par with strong customer authentication.
(c) Payment service providers shall submit to the national authorities specific risk metrics for measuring the effectiveness of their risk management systems in authenticating customers. These metrics can include factors such as:
(i) Claims for lack of authorization,
(ii) Success in refuting such claims,
(iii) Authenticated cases that resulted in loss,
(iv) Financial loss rates,
(v) Loss catch rates,
(vi) Transaction failure due to insufficient or invalid authentication, abandonment by customer of an authentication procedure, and other causes for the transaction not to complete.
We recommend that the list of exemptions proposed in Chapter 2 (i) is kept optional and (ii) is reviewed on a regular basis to avoid it becomes obsolete in the fast-paced Internet environment.
Rationale
We understand that this question asks if the exemptions to SCA identified in Chapter 2 should be mandatory or optional. We consider that:
• Payment Service Provides (PSPs) should be allowed to modulate deployment of SCA according to the actual risk of the transaction, given that the PSD2 identifies the “level of risk involved by the service provided” as the first criteria based on which the exemptions to SCA should be determined by the RTS (Art. 98.3).
• PSPs should be able to apply more or less stringent security based on specific and pre-approved risk-metrics. Since fraudsters are extremely sophisticated and increasingly fast in breaching security methods, it is key that payment providers are allowed the ability and the incentive to adapt their security response to outsmart the cyber threat.
We support the objective of protection of the confidentiality and the integrity of the Payment Service Users’ (PSU) personalised security credentials (PSC) in Chapter 3. We would however appreciate greater clarity on a number of concepts, and the inclusion of a risk-based approach.
Rationale:
• The concept of “data” in Art. 9.1(a) is unclear and might lead to different interpretations. We would suggest removing the reference and simply referring to PSCs. We would also suggest introducing a risk-based approach allowing users to get a time-sensitive view of what they type into the authentication field: this would improve the consumer experience.
• The term “tamper resistant” in Art. 9.1(c) should be clarified, taking into consideration the costs and impact for payment providers of having to store all cryptographic material used to encrypt PSCs in tamper-resistant environments (typically Hardware Security Modules, smartcards or other hardware tokens). Also, the approach suggested is hardware specific, and therefore lacks technology neutrality. This precludes the use of other popular methods, such as secret key fragmentation with no single-party access.
• The reference to “digitally signed” in Art. 13(b) suggests that PSPs can only use a single technology: we would recommend amending the wording in a technology neutral perspective, to allow payment providers to deploy other technologies to achieve the same result.
• Art. 14 raises different risk scenarios: from a risk perspective, the use case of scheduled renewal of expired credentials is different from the replacement/reactivation of credentials that may have been compromised. We would recommend an approach based on risk to modulate the security response accordingly.
We would welcome additional clarification on how the requirements for secure and open communication would apply in the case of an Account Service Payment Service Provider (ASPSP) acting as a Payment Initiation Service Provider (PISP) or Account Information Service Provider (AISP). In addition, we recommend that Art. 17 does not apply to the communication between the ASPSP and consumers, as that would place undue burdens on consumers and introduce new security threats.
We suggest redrafting Art. 17 as such:
Article 17 - Requirements for identification
1. Payment services providers shall ensure secure bilateral identification when communicating with payment initiation and account information services.
We would also suggest a new article to clarify the requirements when an ASPSP acts as a PISP or AISP:
Article 23 - Applicability of requirements
1. Where, in a given transaction, a PSP provides payment initiation services, while another PSP provides the payment account, the PSP initiating the transaction is not mandated to comply with the authentication requirements applicable to the account service payment service provider in that transaction, even if it provides a payment account to the same payer for other transactions.
2. Where a PSP provides account information services for a user, while another PSP provides the payment account, the account information PSP is not mandated to comply with the authentication requirements applicable to the account service PSP for that payment account, even if it provides a payment account to the same payer for other transactions.
Rationale
• We would recommend clarifying how the requirements for secure communication would apply if an ASPSP were to act as a PISP or AISP: we understand that PIS/AIS status is to be transaction-based, which means that an ASPSP can provide a purely PIS/AIS service, separate from its relationship with the payer as an ASPSP.
• The requirements in Art. 17 seem to mandate bilateral two-way authentication over Transport Layer Security (TLS) for consumer devices as well as for connections between PISPs/AISPs and ASPSPs: this is excessive as customers’ devices generally do not have public key certificates ready for use to identify themselves to merchants’ servers, and asking them to obtain certificates would be a complex and burdensome process: Good (EV) certificates are costly, and require a personal appearance by the consumer to the certificate issuer. In addition, the requirements in paragraph (2) are only feasible if the PSP has the necessary permission to control the communication configuration on the consumer device: this is not, and should not be, the case. Allowing such access to payment providers would pose serious security issues, and may interfere with other applications on the consumer’s device that are not within the payment provider’s reach. We recommend that Art. 17 be limited to connections between PSPs (PISPs, AISPs, and ASPSPs) but not apply to connections from an end user’s device to a payment provider. Instead, the display of the security of the connection by the browser is now a familiar sight to the consumer and should be maintained.
• The reference to the Network Time Protocol (NTP) in Art. 18(c) is neither technology neutral nor future proof: we recommend removing it or only mentioning it as an example. Indeed, technology alternatives exist, such as the Precision Time Protocol (PTP). The focus of this provision should be the objective (i.e. the synchronisation of timestamps), rather than the instrument (in this case a protocol) used to achieve it.
• Art. 21(6) seems to mandate compliance with ISO 27001, which is currently not a requirement for credit institutions, e-money institutions or payment institutions. It is unclear why this should be made mandatory for PIS and AIS providers. We strongly recommend flexibility on the type of standard that payment providers can deploy to meet the objective of ensuring the processing and routing of personalized security credentials take place in secure environments.
We recommend removing the reference to the ISO 20022 standard or clarify it is only an example amongst other standards that Payment Service Providers (PSPs) can use.
Rationale
While nominally an international standard, in other geographic areas ISO 20022 is not as widely adopted. Moreover, ISO 20022 is only used for credit transfers or direct debits, and at that only for bank-to-bank communication. It would be difficult for payment providers that offer payment services of another nature (e.g. PISPs and AISPs) to also apply ISO 20022. We are concerned that an explicit reference to a standard that is very limited in the online PSP world would lead to these PSPs being disadvantaged in their choice of communication interface. The risk is isolating Europe from the global payments industry while imposing increasing costs and complexity for EU payment providers.
We recommend using website certificates issued by a general Certificate Authority (option 2). We suggest clarifying that the reference to the e-IDAS certification is only an example of the alternatives available to payment providers.
Rationale
• Only tying authentication of service providers to e-IDAS certification risks isolating Europe from the global payments industry because eIDAS is a Europe-centric solution. In fact, it is unclear and untested at scale whether e-IDAS certificates will be interoperable with existing standards across the world (e.g. EV certification) and recognized and accepted by non-EU web users. In addition, there is no justification as to why trust service providers based outside the EU are less trustworthy than those operating in the EU under the e-IDAS.
• If e-IDAS certification were to be norm, then the term “identification” is ambiguous and needs to be clarified. From an e-IDAS perspective, there is a clear distinction between authentication and identification (e-IDAS Art. 3.1 and 3.5). Solutions suitable for one are not necessarily suitable for the other. In addition, the scope and timeline of the adoption of e-IDAS by the private sector and by different EEA countries is unclear.
We would recommend keeping this provision flexible so as to foster innovative business models in the Account Information Service (AIS) space.
Rationale
The frequency with which AIS providers can request information should match the frequency with which the Payment Service Provider updates the account information - in practice this can happen anytime from once a day to every few minutes. In the case of real time updates of the account – such as is the case for instant payment schemes – the Account Service Payment Service Provider (ASPSP) should define reasonable limits within the API functionalities (subscriptions, access limits, etc.).
Question 1: Do you agree with the EBA’s reasoning on the requirements of the strong customer authentication, and the resultant provisions proposed in Chapter 1 of the draft RTS?
The guidance on Strong Customer Authentication (SCA) provided in the draft RTS will hamper the development of e-commerce in Europe. In its current form, the draft is overly narrow and prescriptive. It will hinder customer experience and place additional burdens on merchants and Payment Service Providers (PSPs).The draft guidance places disproportionate barriers to customer authentication and risks stifling the development of the e-commerce sector in Europe. Data shows that overly cautious measures, which add too much complexity for consumers, result in fewer e-commerce transactions. The draft rules have the potential of diverting investment away from the development of innovative and secure products and services in the EU because the scope for creative solutions is much reduced.
We strongly recommend reconsidering the current approach to take into account the criteria set in the PSD2 mandate to the EBA (Art. 98). We expect that the measures proposed on SCA should (i) not adversely affect the user and merchant experience, and (ii) remain business-model and technology neutral.
1. Impact of Strong Customer Authentication on the user and merchant experience
PayPal recommendation
The RTS’s proposed approach to Strong Customer Authentication (SCA) is likely to have a negative impact on the customer and merchant experience, and hence on e-commerce activity. Mandating a blanket application of SCA does not reflect the actual risk for customers when using payment services online and introduces unnecessary friction in consumers’ shopping experience. Usability for consumers must be a core consideration in the draft guidance to promote the e-commerce agenda. PayPal recommends an approach which balances security concerns with the customer experience, using all available evidence.
Rationale
• The application of Strong Customer Authentication, regardless of the actual security risk of the service provided, is disproportionate, introduces undue friction in the setup and payment process for customers and decreases merchants’ ability to customize the check-out process in a secure and user-friendly way, as demanded by customers. The data shows that the consequences are 1) customers are less likely to complete the authentication process for simple transactions, 2) digital merchants will see greater transaction abandonment and 3) merchants’ eagerness to invest to improve the check-out flow (and therefore the customer experience) will decrease because they will be obliged to apply SCA to all their transactions. This would negatively impact the development of digital payments and e-commerce - rather than promote its growth - contradicting the policy objectives of the EU Digital Single Market strategy.
• In the case of e-wallets such as PayPal, consumers will be faced with two back-to-back requests to perform Strong Customer Authentication: first for the link to the wallet from the user’s bank account or card, and second for the payment transaction from the wallet to the merchant. This unnecessary complexity risks jeopardizing the usage and development of digital wallets across the EU, despite the fact that they are increasingly popular with consumers and merchants.
• PayPal’s data on the application of 3DS security on e- and m-commerce transactions in Q1 2016 demonstrates that, on average, an additional 40% of transactions were abandoned following the introduction of 3DS. In Germany – a country familiar with SCA – this figure rises to 51%. The numbers clearly show customers’ frustration with the cumbersome authentication procedure. In PayPal’s experience, company data on the application of PayPal’s ‘One Touch’ (which allows for a seamless payment experience by staying logged in on a specific device: see https://www.paypal.com/webapps/mpp/one-touch-checkout) indicates that massive user adoption of a streamlined procedure did not result in higher fraud. In fact, the fraud levels of that product have been consistently lower than the (already low) fraud level for the regular PayPal product. This can be explained by the fact that PayPal deploys extensive risk management procedures specific to One Touch to ensure its security, while providing increased convenience to customers and merchants alike.
• Payment security rules must consider the impact on consumers and merchants. By making it overcomplicated to pay for goods and services online, there is a real risk that consumers will be less prepared to purchase online, potentially shopping only for goods unavailable offline, or by limiting their purchase to the merchants that frame their transactions as recurring payments, thereby ultimately neglecting smaller merchants, which will be unable to attenuate the friction caused by the SCA rules. In this scenario, consumer choice and competition will pay an unduly high price to security. Eventually, the most secure transaction will be the one that never goes through.
2. Strong Customer Authentication should be business-model neutral (Art. 98. 2 (d))
PayPal recommendation
Payment Service Providers should be allowed to develop innovative authentication solutions that are both secure and convenient for users, by 1) making the use of an authentication code optional, in line with the requirements in the PSD2, and 2) allowing behavioural data to be used as an inherence element within the SCA framework. A one size fits all approach should not be pursued unnecessarily. This smart and nimble deployment of SCA would benefit both consumers and merchants, ensure that payment security integrates new technologies, and ultimately help achieve the EU Commission’s goals of creating a dynamic and attractive Digital Single Market in the EU.
We suggest redrafting Art. 1 as such:
Article 1 - Authentication procedure and authentication code
1. For the purposes of the application of strong customer authentication in accordance with Article 97(1) of Directive (EU) 2015/2366 the authentication procedure may result in the generation of an authentication code each time that the payer accesses its payment account online, initiates an electronic transaction or carries out any action through an interactive remote channel which may imply a risk of payment fraud or other abuses.
2. Where appropriate, the authentication code shall be characterized by security features ensuring that no information on any of the elements of strong customer authentication categorized as knowledge, possession and inherence can be derived from the disclosure of the authentication code.
3. The strong customer authentication procedure shall include mechanisms to:
(a) ensure that any of the elements of strong customer authentication can be identified as incorrect, where the authentication procedure has failed to generate an authentication code for the purposes of paragraph 1;
(b) determine the maximum number of failed authentication attempts that can take place consecutively within a given period of time and after which the access to an online payment account, the initiation of an electronic payment transaction or the possibility of carrying out any action through a remote channel which may imply a risk of payment fraud or other abuse are temporarily or permanently blocked. Where the block occurs during the course the current session, the number of retries and the time period of the block shall be established taking into account the characteristics of the service provided to the payer and all the relevant risks involved. Where the block is permanent, a secured procedure must be established allowing the payer to regain access to and unblock the electronic payment services;
(c) protect communication sessions against the capture of data transmitted during the authentication procedure or manipulation by unauthorised parties, including but not limited to by relying where applicable on HTTP over TLS;
(d) prevent, detect and block fraudulent payment transactions before the PSP’s final authorisation. These mechanisms shall take into account, but not be limited to:
i. parameterised rules, including black lists of compromised or stolen card data,
ii. signs of malware infection in the session and known fraud scenarios,
iii.an adequate transaction history of the payer to evaluate its typical spending behavioural patterns,
iv. information about the customer device used,
v. a detailed risk profile of the payer and/or the payer’s device.
Rationale
• The draft guidance is disproportionate relative to the specific requirements set out in the Payment Services Directive 2 (PSD2). The RTS goes beyond the requirements in the level 1 text by requiring that SCA result in the generation of an authentication code that is accepted only once for any given Payment Service User: authentication codes are not mandated in art. 97 of the PSD2, and recital 96 notes that strong customer authentication “may result in authentication codes such as one-time passwords”: they are therefore mentioned as just an example. Strong Customer Authentication as defined in the PSD2 can be delivered through the combined use of independent, secure, static authentication elements (e.g. passwords, device-specific certifications or credentials, biometrics etc.) without the need for one-time authentication codes. Requiring their use simply adds friction to the customer experience, with no commensurate security benefits.
• The PSD2 mandates the RTS to be neutral towards different business models. This can only be achieved by catering for the payment industry’s heterogeneous and competitive nature: different Payment Service Providers have access to different data sets to implement the three elements supporting the SCA procedure. Banks, for instance, can authenticate users based on their direct relationship with the user. At PayPal, our data algorithms and risk management capabilities, coupled with our ability to see both ends of the transaction (the accounts of the payer and the payee are held by the same PSP), provide us with invaluable data to identify and authenticate users.
• A one size-fits-all approach to payment security is not appropriate in the heterogeneous EU payments market: such an approach will have the adverse effect of decreasing competition in the payment market, to the detriment of smaller players who may not be able to make the necessary investments and adjustments to smoothen SCA inconveniences. The one-size-fits-all approach in the RTS moreover favours PSPs who also provide computing hardware, while disadvantaging banks and wallets. Such an approach makes it easier for fraudsters to attack with large scale effects, given that all EU payment providers will use exactly the same SCA toolkit.
• We therefore strongly disagree that behavioural data is just an “additional tool for fraud prevention” (point 29 of the rationale). Behavioural data is already successfully used for authentication purposes and is a crucial tool to meet the EBA’s declared goal to allow for “the development of user-friendly, accessible and innovative means of payments” (point 28 of the rationale). In fact, there is no real distinction between user authentication and the prevention of authentication fraud: several payment providers have developed sophisticated risk management systems that analyse specific behavioural patterns that effectively match the identity of the payer with its ‘consumer’ profile, in order to both authenticate users and detect fraud. This removes customer friction and enables smoother secure online transactions.
• Behavioural characteristics can include transaction history, habitual location, device used, preferred retailers, and other consumer habits that the PSP is able to collect, in accordance with EU data protection and privacy rules. Because behavioural attributes can be collected and assessed over a period of time, they are less susceptible to theft, malware, spoofing, or malicious replication than something the user has, knows, or is. Behaviour-based characteristics have been successfully used by PSPs to identify cases where control of an account has been lost or compromised, and it is increasingly common and accepted throughout the industry that behavioural evidence can be used as an independent inherence element. See, for example, DARPA’s “active authentication” programme summarised at http://www.darpa.mil/program/active-authentication.
3. Strong Customer Authentication should be technology-neutral (Art. 98. 2 (d))
PayPal recommendation
The RTS should support a SCA process that is technology-neutral and future-proof, by defining the security objectives to be met, rather than the specific solutions. The current drafting is so narrow that only one existing technology qualifies. True technology neutrality would enable more innovative and comprehensive approaches to payment security, independent of the respective channel, platform or method. It will also let PSPs take account of all the evidence relevant to authentication, including behavioral data. This approach would significantly stimulate PSPs’ ability to detect and respond to new security threats as they adapt their risk models to an ever-changing security landscape.
Rationale
• The current drafting of Articles 1 and 2, by specifying the SCA procedure in a way that neglects the other technologies that allow for SCA (and dynamic linking) to be performed as securely, is detrimental to innovation as it removes the incentive and even the possibility to develop and invest in these innovative technologies.
• The RTS points towards processes and techniques that reflect the world that existed long before the SecuRe Pay Forum first started looking at the security of online payments. Since then, the industry has developed authentication techniques that reflect more accurately the current state of the payments market. The approach in the RTS regrettably ignores the data-rich environment of modern e-commerce, as well as the sophisticated digital technologies currently in use, which are moving away from binary authentication methods towards more comprehensive approaches that minimize the burdens on consumers, while ensuring greater nimbleness to face ever-changing security threats.
• The diversity of authentication and security methods in the digital financial area is probably the strongest protection from a holistic point of view. Defining very specific technical security parameters forces payment providers to deploy the same few authentication methods, on which fraudsters would be able to focus their efforts to reach a large consumer segment. To that point, David Emm, principal security researcher at Kaspersky, recently told the BBC (see at the end of this article: http://www.bbc.com/news/technology-37585247) that banks should consider applying a multitude of cybersecurity solutions to minimise unauthorized access to such information".
• More generally, the draft RTS focusses on the traditional e-commerce environment, where buyer and seller typically do not meet (i.e. electronic payments that are remote are treated differently than those occurring at the point of sale). However, the distinction between online and offline transactions is increasingly obsolete. This change is accelerated by the development of services available via mobile devices, including payments. The development of mobile and omni-channel commerce and the ensuing blurring of commercial channels, which used to be clearly distinct, create obvious challenges for regulators. However, we expect these new models to be reflected in a future-proof legislative framework, which enables safe and efficient commercial transactions.
• In addition, the provisions on SCA force payment providers to host cryptographic algorithms in users’ hardware or software. Yet, the weakest link in the authentication procedure is often the user (devices or passwords can be lost or stolen for instance) (e.g. HBCI in Germany).
To conclude, the recent Dutch experience demonstrates that online fraud can be effectively fought with a mix of measures which do not necessarily involve only the deployment of restrictive Strong Customer Authentication. A study by the Dutch Banking Association and the Payments Association shows that the damage caused by fraud in online banking during the first half of 2016 decreased by 82 % compared to the last six months of 2015. Reasons include greater cooperation between the payments industry and regulators, better consumer education and the deployment of detection systems based on transaction monitoring (https://www.betaalvereniging.nl/nieuws/nauwelijks-fraude-internetbankieren/). This experience not only demonstrates that authentication outcomes are measurable, but also that a broader approach to SCA can yield excellent results."
Question 2: In particular, in relation to the “dynamic linking” procedure, do you agree with the EBA’s reasoning that the requirements should remain neutral as to when the “dynamic linking” should take place, under the conditions that the channel, mobile application, or device where the information about the amount and the payee of the transaction is displayed is independent or segregated from the channel, mobile application or device used for initiating the payment, as foreseen in Article 2.2 of the draft RTS.
1. The RTS should provide discretion for PSPs to determine (i) how they implement dynamic linking and (ii) whether or how dynamic linking is made visible to the Payment Service User (PSU).PayPal recommendation
We suggest reviewing Art. 2(1) to highlight the distinction between the authentication code and the authorisation code.
We suggest redrafting Art. 2(1) as such:
Article 2 - Strong customer authentication procedure with dynamic linking
1. For the purposes of the application of strong customer authentication in accordance with Article 97 (2) Directive (EU) 2015/2366, the authentication procedure shall provide that:
(a) The payer is made aware at all times of the amount of the transaction and of the payee(s);
(b) The authorisation code shall be specific to the amount of the transaction and the payee agreed to by the payer when initiating the transaction.
Rationale
• We are concerned that Art. 2 mixes up the concepts of the authentication code and the authorisation code: the authentication code referred to in Art. 1, and which we suggest should be optional, simply allows customers to authenticate themselves. The authorisation code, and the subsequent dynamic linking requirement, applies only to remote electronic transactions (PSD2 Art. 97(2)) and its aim is to authorise the transaction after the customer has authenticated. In practice these two processes are distinct, even if they occur simultaneously.
• We would welcome clarifications regarding the reference to “authenticity” in Art. 2.2(a): does this refer to the payee or the data regarding the payee? If the former, we would like to point out that the authentication procedure provided by the ASPSP can only ensure the confidentiality and integrity of transaction data. Ensuring the authenticity of the payee is only possible if the information is verifiable during authentication by the user or the ASPSP, which is not the case.
2. The requirement that the “channel, device or mobile application through which the information linking the transaction to a specific amount and a specific payee is displayed is independent or segregated from the channel, device or mobile application used for initiating the electronic payment transaction” is concerning.
PayPal recommendation
The viability of using mobile devices’ separate trusted elements depends on the openness of the device’s operating system, which must be ensured to prevent device makers from abusing a strong market position by foreclosing access to payment providers. We would recommend the EBA to introduce a fair access clause to that effect.
Rationale
• As drafted, the RTS will require each payment provider to distribute a separate trusted element to each consumer: either as a separate token or within the user’s mobile device. While the first option is burdensome on the consumer – they will need to have one separate, trusted element for each payment provider that they choose to use – the latter is only viable if the device makers provide payment providers with access to the separate trusted element on the device. Indeed, technologies currently in use can easily guarantee independence within the same mobile phone or tablet, with no need for additional devices, through the use of separate trusted elements or ‘host card emulation’ technologies. For example, a user could confirm a transaction by introducing a PIN (something only he knows) or using his fingerprint (something he is) on a mobile device that can be recognised and validated, receiving on his previously enrolled authentication application (the same device, or a different one) a dynamic code that identifies the transaction, amount, payee, etc. This however effectively rules out devices other than mobile phones or tablets: personal computers, for example, do not have separate secure environments.
• It is therefore not clear that payment providers will be able to rely on the user’s available secure device, their mobile phone or tablet, without having to distribute separate secure environments (e.g. tokens) for non-mobile users, devices which are far more likely than a phone to be forgotten or lost. Indeed, tokens come at a cost that will tend to be passed onto the consumer. Also, consumers will have to be educated to enable them to use the token, and they will need to quickly notify it as invalid if it is lost. In many cases, activation, setup and usage fail because tokens are difficult for consumers to manage and loss of tokens will go unreported and quite likely unnoticed.
• Digital payments users legitimately expect to access whichever account they choose from their devices, and to initiate, pay and confirm a transaction using the same device (i.e. mobile phone). Besides creating an unsustainable customer experience and extra expense - with no additional security benefit - this requirement is not cost-effective for payment providers unless the secure environment that most consumers already have is available on a fair, non-discriminatory basis to all authorised PSPs.
Question 3: In particular, in relation to the protection of authentication elements, are you aware of other threats than the ones identified in articles 3, 4 and 5 of the draft RTS against which authentication elements should be resistant?
PayPal recommendationBehavioural data should be included amongst the requirements for Strong Customer Authentication, as part of the inherence element (something that the user is).
We suggest redrafting Art. 5 as such:
Article 5 - Requirements related to authentication elements categorised as inherence
1. Authentication elements categorized as inherence shall be characterized by security features such as algorithm specifications, biometric sensor and template protection features ensuring resistance against the risk of sensitive information related to the elements being disclosed to unauthorised parties. These security features shall also guarantee a sufficiently low likelihood of an unauthorised party being authenticated as the legitimate payment service user.
2. The use of elements categorized as inherence shall be subject to measures ensuring that the devices and the software provided to the payer provide resistance against unauthorised use of the elements through access to the devices and software.
And we suggest the following new recital:
[new] (5) Relating to the inherence element, modern authentication technologies can minimise the inconvenience of the authentication process by effectively leveraging the multiple elements related to the digital interaction of users, including users’ behavioural-based characteristics. These technologies have been successfully used by PSPs to identify cases where control of an account has been lost or compromised. Behaviour is a robust indicator of identity and can be very effective to authenticate the PSU within the framework of strong customer authentication.
Rationale
• See response to Q1 for the rationale.
• We would also like to point out that behavioural and transactional data do not suffer from the vulnerabilities of the other factors (possession and knowledge) because they are recorded by the payment provider as events occur, and are stored beyond the reach of the user’s ability to manipulate or unintendedly compromise them. Under a number of EU regulations – including the Network and Information Security Directive and the General Data Protection Regulation – the payment provider is moreover obliged to store such data in a secure way.
• We suggest replacing the phrase “guarantees” in Art. 5(2) as no technology or security measures can guarantee 100% resistance against security threats: instead, we would suggest using the term “provide”.
Question 4: Do you agree with the EBA’s reasoning on the exemptions from the application of Article 97 on strong customer authentication and on security measures, and the resultant provisions proposed in Chapter 2 of the draft RTS?
1. On the exemption on remote electronic transactions:PayPal recommendation
We recommend aligning the provision on remote electronic payments with the reality of digital payments by ensuring a robust risk-based approach, together with exemption thresholds that are aligned with the PSD2 and reflect the e-commerce market reality.
Rationale
• We do not understand the basis and the rationale for the remote electronic transactions exemption thresholds in Chapter 2. A limit of 10 EUR per transaction (and 100 EUR cumulatively) would oblige users to go through the unfriendly experience of SCA for almost any digital payment, regardless of the actual risk posed. This approach will have a detrimental impact on e-commerce, which would be at odds with the EU Commission’s efforts to foster the digital economy’s growth in the EU. We therefore suggest aligning these thresholds to those for low-value transactions in Art. 42 of the PSD2.
• We also wonder what the rationale is behind the two sets of exemption thresholds under Art. 8.1 (contactless transactions) and Art.8.2 (remote transactions), knowing that fraud can occur both in a contactless and online environment. It is also difficult to reconcile the thresholds of Chapter 2 with those of Art. 3 (l) (the so-called digital exemption) of the PSD2. Indeed, telecom providers are exempted from the PSD2 (and therefore the RTS) for transactions up to 300 EUR. This means that consumers can purchase digital content through their telecom provider free of Strong Customer Authentication for an amount 30 times higher than that of consumers making the same purchase via a PSP.
• From a security perspective, the value of the transaction taken in isolation is only one factor out of many that describe the actual level of risk posed by the transaction: other elements need to be taken into account, such as location, the device used or the user’s usual pattern of behaviour, the IP address, etc. An exemption based only on the transaction value is flawed and ignores the complexity of modern digital payments, where the risk presented by the exemption can be mitigated using technologies that analyse all the information provided by the user to ensure the transaction is low risk.
2. On the exemption allowing whitelists:
PayPal recommendation
Clarifying that the whitelists mentioned in Art. 8(2)a can also be created by the Account Servicing Payment Service Provider: at the moment only the Payment Service User can generate such a list.
Rationale
• ASPSPs should be able to generate their own whitelists to reflect ongoing customer behaviour, the risk-profile of the payee, the frequency of such payments etc. This would allow for the ASPSP to apply its risk management practices to the benefit of customers’ convenience, thereby mitigating the negative impact of SCA on the customer and merchant experience.
3. On the EBA’s rationale in point 54 for its decision not to propose a transaction-risk analysis:
PayPal recommendation
The RTS should allow for exemptions that focus on effectiveness and outcomes, and encourage PSPs to develop and put in place risk-based authentication capabilities that would allow payment providers to select the most effective authentication challenge, based on the level of risk of transactions.
Rationale
• Art. 98 (2)a and (3)a of the PSD2 explicitly stipulate that the RTS should be based on “risk-based requirements” and that the exemptions should take into account “the level of risk involved in the service provided.” This mandate is not fulfilled in the draft RTS and there is no basis for the EBA’s conclusion that a transaction risk analysis would not adequately protect consumers. The EBA offers no justification in its impact assessment or cost/benefit analysis as to why it considers that reliance on a transaction-risk analysis by PSPs “would likely not sufficiently protection consumers and […] possibly harm fair competition in the payment service market”. In fact, the EBA cost/benefit analysis provides little evidence or argumentation for any of the proposed exemptions in Art. 8, nor - more generally - for all the provisions in the RTS. This approach ignores the recent developments in risk management that the payment industry has invested in to reconcile strong risk controls with a good customer experience, in compliance with the current EBA Guidelines on the security of Internet payments.
• There are multiple benefits to introducing an exemption based on risk-based authentication: (i) it makes the context assessment measures more difficult for fraudsters to understand and attack, (ii) it incentivises payment providers to continue investing in robust risk-management systems, (iii) it ensures the security response evolves to meet the ever-changing security threats, and (iv) it fosters the growth of e-commerce by deploying secure and customer-friendly solutions.
• A risk analysis approach – by making better use of the data-rich environment on the Internet and the user’s history and behaviour as evidence for authentication – would also help reduce dependence on unsophisticated users. These are usually the weakest link in the authentication procedure. A risk-based algorithm that takes into account hundreds or thousands of independently collected behavioural, locational, and habitual data points in order to authenticate a user does not depend on the user carrying out complex procedures and is significantly harder for a fraudster to manipulate or misuse.
Proposal for an efficient transaction-risk analysis process
The RTS should define auditable risk management procedures measuring outcomes (based on comparable industry standards such as ISO 27005) and enabling home state regulators to evaluate the effectiveness of methods using metrics reported by payment providers they supervise.
We believe that the payment providers’ home regulator has an essential role to play in a risk-based model: periodic reviews with the home state regulator would ensure that the fraud rate remains at acceptable levels in view of the risk. In the 4th Anti-Money Laundering Directive, for instance, the risk-based approach is based on an ongoing dialogue with the supervisors.
1) Payment providers would put in place risk management systems to effectively detect and mitigate the risks of transactions, taking into consideration a number of factors such as:
a. The level and type of risk of the underlying payment instrument, system or service provider,
b. The risk profile of the payer and payee, including their transaction history, behaviour patterns and the device / browser & IP used,
c. The context of the transaction (e.g. low value, vertical of purchase, riskiness of merchandise, habitual location of the user, frequency of security compromises, habitually used device, riskiness of IP, etc.).
2) Payment providers would then either deploy SCA or alternative methods of authentication, based on the level of the risk of the transaction.
3) Periodic reviews with the home state regulator would ensure that the fraud rate remains at acceptable levels in view of the risk. Some of the metrics that payment providers can share with regulators to measure authentication outcomes and the level of risk include:
a. Claims for lack of authorization,
b. Success in refuting such claims,
c. Authenticated cases that resulted in loss,
d. Financial loss rates,
e. Loss catch rates,
f. Transaction failure due to insufficient or invalid authentication, abandonment by customer of an authentication procedure, and other causes for the transaction not to complete.
4) With this approach, SCA would be triggered on the basis of a pre-approved level of risk, while less risky transactions would be covered by the exemption.
4. A note on the liability shift:
PayPal recommendation
We strongly disagree with the EBA’s interpretation of the application of Art. 74(2) in the PSD2. We believe that the liability shift is the backbone of payment security and the RTS should not make it a transitional measure.
Rationale
• The PSD2 does not state that Art. 74(2) only applies during the transitional period between the application date of PSD2 (13 January 2018) and the application date of the RTS under consultation (October 2018 at the earliest). We believe that the draft guidance contradicts the spirit of the level 1 text.
• Digital payment providers and merchants have developed and apply sophisticated risk management systems that allow them to calibrate the security of transactions with the actual level of risk they pose. Using the data-rich digital environment, they can effectively single out low-risk transactions from higher risk transactions, thereby triggering the authentication challenge more accurately. This greatly enhances convenience for customers, while also ensuring greater security and transaction success for merchants. Art. 74(2) provides payment providers and merchants with a huge incentive to ensure their management systems are effective: trust is a crucial element in the online space, so suffering a fraud does not only entails financial consequences (the obligation to refund customers), but most relevantly jeopardizes brand reputation and customer trust. Removing the ‘liability shift’ (and therefore imposing a blanket application of SCA) has several implications:
o Payment providers will be forced to reject transactions should the merchant fail to support SCA, at the expense of payment users. Transaction rejection is often a concerning experience for users, who are not sufficiently informed to understand the reason behind it. They might actually blame the payment service for failing to complete their online purchase!
o Payment providers and merchants alike will lose any business incentive to invest to further develop their proprietary risk management systems, leaving them unprepared to meet future security threats. For instance, there will no longer be any incentive to proactively monitor for fraudulent activity transactions above 10 EUR, as long as SCA is mandated. This will quickly make the EU payment system obsolete and more vulnerable.
o While large merchants might be able to adjust their systems to minimise the frictions of SCA, smaller merchants may not be able to make the same investments, and will therefore lose customers at check-out, which in turn will have a negative impact on customer choice and competition in the EU market.
We therefore suggest redrafting Art. 8 as such:
Article 8 - Exemptions to strong customer authentication
1. The application of strong customer authentication in accordance with Article 97(1) of Directive (EU) 2015/ 2366 is exempted where the PSP, or the payee, has elected not to apply strong customer authentication and agreed to bear any resulting financial loss unless the payer has acted fraudulently, under article 74.2 of directive (EU) 2015 / 2366.
2. The application of strong customer authentication in accordance with Article 97(1) of Directive (EU) 2015/ 2366 is exempted where:
(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 one month after the last day in which strong customer authentication was applied and no specific timeframe was agreed with the payer.
(b) the payer initiates a contactless electronic payment transaction at a point of sale within the limits of both the following conditions:
i. the individual amount of contactless electronic payment transaction does not exceed the maximum amount of 50 EUR;
ii. the cumulative amount of previous non-remote electronic payment transactions initiated via the payment instrument offering a contactless functionality without application of strong customer authentication does not exceed 150 EUR.
3. The application of strong customer authentication in accordance with Article 97(2) of Directive (EU) 2015/ 2366 is exempted where:
(a) the payer initiates a payment online where the payee is included in a list of trusted beneficiaries previously created by the payer with its account servicing payment services provider, or by the account servicing payment provider based on their risk analysis.
The application of strong customer authentication shall not be exempted where the payer creates for the first time or subsequently amends the list of trusted beneficiaries with its account servicing payment services provider.
(b) the payer initiates online a series of payments with the same amount and the same payee.
The application of strong customer authentication shall not be exempted where the payer initiates the series of payments for the first time or amends the series of payments.
(c) the payer initiates a payment online a where the payer and the payee are the same natural or legal person and the payee’s payment account is held by the payer’s account servicing payment services provider;
(d) the payer initiates a remote electronic payment transaction where all the following conditions are met:
i. the individual amount of the remote electronic payment transaction does not exceed the maximum amount of 30 Euros; and
ii. the cumulative amount of previous remote electronic payment transactions initiated by the payer without application of strong customer authentication does not exceed 150 EUR.
3. The application of strong customer authentication in accordance with Article 97(2) of Directive (EU) 2015/ 2366 is exempted where:
(a) the payment service provider can demonstrate the use of risk management systems to effectively detect and mitigate the risks related to the payment service, based on factors such as:
i. The level of risk of the underlying payment service and payment service provider,
ii. The risk profile of the payer and payee,
iii. The specific risk posed by a transaction type.
(b) National authorities shall ensure regular reviews and audits of the application of this exemption and the effectiveness of payment service provider’s risk management systems in ensuring outcomes on par with strong customer authentication.
(c) Payment service providers shall submit to the national authorities specific risk metrics for measuring the effectiveness of their risk management systems in authenticating customers. These metrics can include factors such as:
(i) Claims for lack of authorization,
(ii) Success in refuting such claims,
(iii) Authenticated cases that resulted in loss,
(iv) Financial loss rates,
(v) Loss catch rates,
(vi) Transaction failure due to insufficient or invalid authentication, abandonment by customer of an authentication procedure, and other causes for the transaction not to complete.
Question 5: Do you have any concern with the list of exemptions contained in Chapter 2 of the draft RTS for the scenario that PSPs are prevented from implementing SCA on transactions that meet the criteria for exemption?
PayPal recommendationWe recommend that the list of exemptions proposed in Chapter 2 (i) is kept optional and (ii) is reviewed on a regular basis to avoid it becomes obsolete in the fast-paced Internet environment.
Rationale
We understand that this question asks if the exemptions to SCA identified in Chapter 2 should be mandatory or optional. We consider that:
• Payment Service Provides (PSPs) should be allowed to modulate deployment of SCA according to the actual risk of the transaction, given that the PSD2 identifies the “level of risk involved by the service provided” as the first criteria based on which the exemptions to SCA should be determined by the RTS (Art. 98.3).
• PSPs should be able to apply more or less stringent security based on specific and pre-approved risk-metrics. Since fraudsters are extremely sophisticated and increasingly fast in breaching security methods, it is key that payment providers are allowed the ability and the incentive to adapt their security response to outsmart the cyber threat.
Question 6: Do you agree with the EBA’s reasoning on the protection of the confidentiality and the integrity of the payment service users’ personalised security credentials, and the resultant provisions proposed in Chapter 3 of the draft RTS?
PayPal recommendationWe support the objective of protection of the confidentiality and the integrity of the Payment Service Users’ (PSU) personalised security credentials (PSC) in Chapter 3. We would however appreciate greater clarity on a number of concepts, and the inclusion of a risk-based approach.
Rationale:
• The concept of “data” in Art. 9.1(a) is unclear and might lead to different interpretations. We would suggest removing the reference and simply referring to PSCs. We would also suggest introducing a risk-based approach allowing users to get a time-sensitive view of what they type into the authentication field: this would improve the consumer experience.
• The term “tamper resistant” in Art. 9.1(c) should be clarified, taking into consideration the costs and impact for payment providers of having to store all cryptographic material used to encrypt PSCs in tamper-resistant environments (typically Hardware Security Modules, smartcards or other hardware tokens). Also, the approach suggested is hardware specific, and therefore lacks technology neutrality. This precludes the use of other popular methods, such as secret key fragmentation with no single-party access.
• The reference to “digitally signed” in Art. 13(b) suggests that PSPs can only use a single technology: we would recommend amending the wording in a technology neutral perspective, to allow payment providers to deploy other technologies to achieve the same result.
• Art. 14 raises different risk scenarios: from a risk perspective, the use case of scheduled renewal of expired credentials is different from the replacement/reactivation of credentials that may have been compromised. We would recommend an approach based on risk to modulate the security response accordingly.
Question 7: Do you agree with the EBA’s reasoning on the requirements for common and secure open standards of communication for the purpose of identification, authentication, notification, and information, and the resultant provisions proposed in Chapter 4 of the draft RTS?
PayPal recommendationWe would welcome additional clarification on how the requirements for secure and open communication would apply in the case of an Account Service Payment Service Provider (ASPSP) acting as a Payment Initiation Service Provider (PISP) or Account Information Service Provider (AISP). In addition, we recommend that Art. 17 does not apply to the communication between the ASPSP and consumers, as that would place undue burdens on consumers and introduce new security threats.
We suggest redrafting Art. 17 as such:
Article 17 - Requirements for identification
1. Payment services providers shall ensure secure bilateral identification when communicating with payment initiation and account information services.
We would also suggest a new article to clarify the requirements when an ASPSP acts as a PISP or AISP:
Article 23 - Applicability of requirements
1. Where, in a given transaction, a PSP provides payment initiation services, while another PSP provides the payment account, the PSP initiating the transaction is not mandated to comply with the authentication requirements applicable to the account service payment service provider in that transaction, even if it provides a payment account to the same payer for other transactions.
2. Where a PSP provides account information services for a user, while another PSP provides the payment account, the account information PSP is not mandated to comply with the authentication requirements applicable to the account service PSP for that payment account, even if it provides a payment account to the same payer for other transactions.
Rationale
• We would recommend clarifying how the requirements for secure communication would apply if an ASPSP were to act as a PISP or AISP: we understand that PIS/AIS status is to be transaction-based, which means that an ASPSP can provide a purely PIS/AIS service, separate from its relationship with the payer as an ASPSP.
• The requirements in Art. 17 seem to mandate bilateral two-way authentication over Transport Layer Security (TLS) for consumer devices as well as for connections between PISPs/AISPs and ASPSPs: this is excessive as customers’ devices generally do not have public key certificates ready for use to identify themselves to merchants’ servers, and asking them to obtain certificates would be a complex and burdensome process: Good (EV) certificates are costly, and require a personal appearance by the consumer to the certificate issuer. In addition, the requirements in paragraph (2) are only feasible if the PSP has the necessary permission to control the communication configuration on the consumer device: this is not, and should not be, the case. Allowing such access to payment providers would pose serious security issues, and may interfere with other applications on the consumer’s device that are not within the payment provider’s reach. We recommend that Art. 17 be limited to connections between PSPs (PISPs, AISPs, and ASPSPs) but not apply to connections from an end user’s device to a payment provider. Instead, the display of the security of the connection by the browser is now a familiar sight to the consumer and should be maintained.
• The reference to the Network Time Protocol (NTP) in Art. 18(c) is neither technology neutral nor future proof: we recommend removing it or only mentioning it as an example. Indeed, technology alternatives exist, such as the Precision Time Protocol (PTP). The focus of this provision should be the objective (i.e. the synchronisation of timestamps), rather than the instrument (in this case a protocol) used to achieve it.
• Art. 21(6) seems to mandate compliance with ISO 27001, which is currently not a requirement for credit institutions, e-money institutions or payment institutions. It is unclear why this should be made mandatory for PIS and AIS providers. We strongly recommend flexibility on the type of standard that payment providers can deploy to meet the objective of ensuring the processing and routing of personalized security credentials take place in secure environments.
Question 8: In particular, do you agree that the use of ISO 20022 elements, components or approved message definitions, if available, should be required to ensure the interoperability of different technological communication solutions implemented between PSPs for the provision of AIS, PIS or for the confirmation on the availability of funds? Do you see any particular technical constraint that would prevent the use of such industry standards?
PayPal recommendationWe recommend removing the reference to the ISO 20022 standard or clarify it is only an example amongst other standards that Payment Service Providers (PSPs) can use.
Rationale
While nominally an international standard, in other geographic areas ISO 20022 is not as widely adopted. Moreover, ISO 20022 is only used for credit transfers or direct debits, and at that only for bank-to-bank communication. It would be difficult for payment providers that offer payment services of another nature (e.g. PISPs and AISPs) to also apply ISO 20022. We are concerned that an explicit reference to a standard that is very limited in the online PSP world would lead to these PSPs being disadvantaged in their choice of communication interface. The risk is isolating Europe from the global payments industry while imposing increasing costs and complexity for EU payment providers.
Question 9: With regards to identification between PSPs, do you agree that website certificates issued by a qualified trust service provider under an e-IDAS policy would be suitable and allow for the use of all common types of devices (such as computers, tablets and mobile phones) for carrying out different payment services ?
PayPal recommendationWe recommend using website certificates issued by a general Certificate Authority (option 2). We suggest clarifying that the reference to the e-IDAS certification is only an example of the alternatives available to payment providers.
Rationale
• Only tying authentication of service providers to e-IDAS certification risks isolating Europe from the global payments industry because eIDAS is a Europe-centric solution. In fact, it is unclear and untested at scale whether e-IDAS certificates will be interoperable with existing standards across the world (e.g. EV certification) and recognized and accepted by non-EU web users. In addition, there is no justification as to why trust service providers based outside the EU are less trustworthy than those operating in the EU under the e-IDAS.
• If e-IDAS certification were to be norm, then the term “identification” is ambiguous and needs to be clarified. From an e-IDAS perspective, there is a clear distinction between authentication and identification (e-IDAS Art. 3.1 and 3.5). Solutions suitable for one are not necessarily suitable for the other. In addition, the scope and timeline of the adoption of e-IDAS by the private sector and by different EEA countries is unclear.
Question 10: With regards to the frequency with which AIS providers can request information from designated payment accounts when the payment service user is not actively requesting such information, do you agree that the proposed limit of no more than two times a day achieve an appropriate balance between allowing AISP to provide updated information to their users while not negatively impacting the availability of the ASPSP’s communication interface? If not, please indicate what would be in your view the appropriate frequency and rationale for such frequency.
PayPal recommendationWe would recommend keeping this provision flexible so as to foster innovative business models in the Account Information Service (AIS) space.
Rationale
The frequency with which AIS providers can request information should match the frequency with which the Payment Service Provider updates the account information - in practice this can happen anytime from once a day to every few minutes. In the case of real time updates of the account – such as is the case for instant payment schemes – the Account Service Payment Service Provider (ASPSP) should define reasonable limits within the API functionalities (subscriptions, access limits, etc.).