Response to consultation on RTS specifying the requirements on strong customer authentication and common and secure communication under PSD2

Go back

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?

We support the RTS objectives (aligned with PSD2 Article 98(2)) and appreciate the difficulty the EBA has faced in trying to balance conflicting trade-offs, but a number of areas the draft RTS appear to be out-of-line, or seem to contradict these aims, and the EBA’s stated preferences. We believe that these will have serious implications for user convenience, which will potentially jeopardise innovation and the creation of a competitive digital economy. In places, the draft RTS seem to point towards processes and techniques that reflect the world that existed when the SecuRe Pay Forum first looked at the issue of the security of internet payments. Meanwhile, the world has moved on and multi-factor authentication techniques that may not strictly meet the EBA’s interpretation that strong customer authentication can be more effective in confirming identity, which is ultimately the purpose of authentication. As such, they should be factored in to the RTS – within the scope of the exemptions – if they cannot directly be accommodated within the SCA requirements.

In some areas, we think the draft RTS:
 Are not sufficiently flexible to accommodate future developments.
 Are too prescriptive.
 Require approaches which are already outmoded, or go against current convention or industry best practice.
 Need to differentiate more clearly between the requirements for card payments and non-card payments, as well as remote versus proximity.

Flexibility required to accommodate future developments

• Security and authentication are highly complex and are constantly developing. The risk of the EBA being too prescriptive is that the industry will be hampered from responding to cybercrime and fraud threats adequately. The requirements will quickly become outdated and it may be more difficult to innovate.

• We have concerns about the suitability and long term viability of the low-value payment limits applied in Article 8 and the extent to which they take into account experiences in different Member States. We believe that proximity card payments should not be in scope by virtue of the level one text in PSD2 Article 97(2). However, in any event, the low-value payment limits proposed in the RTS are already being exceeded in some circumstances and we see no empirical risk analysis in the consultation to justify the limits proposed. This is very likely to prevent or frustrate innovation, such as the use of contactless payment cards for transit, where the fraud levels are low. Certain Member States are looking to raise the contactless limits (e.g. so that contactless ticketing can be used in a range of medium journeys connecting with urban transport systems) to accommodate higher value transactions, which is typically a driver of contactless usage.

• We are unclear as to how quickly the EBA can adapt and update the RTS provisions in reaction to changing market conditions. We note that PSD2 Article 98(5) requires the EBA to “review and, if appropriate, update” the RTS “on a regular basis”. How frequently would these reviews take place and how quickly will the EBA be able to adapt and update the RTS provisions in reaction to changing market conditions or needs? It is also unclear how the EBA would determine whether any provisions in the RTS were hampering the market, or kerbing existing or future innovation. If the EBA decided to keep the RTS as currently drafted, we would recommend that the RTS (and particularly the limits) are reviewed, at a minimum, every 12 months to ensure that they are in line with technological developments and not restricting innovation.

A risk based approach to authentication

• We are completely aligned to the objective of reducing fraud in the e-commerce environment and ensuring that payment transactions are as secure as possible. The payments industry and the retail sector invest significantly to achieve this. However, regulatory intervention should be appropriately targeted, based on robust empirical evidence on the most vulnerable components of the payments environment, which generate the highest levels of fraud.

Need to differentiate more clearly between the requirements for card payments

• We disagree with the interpretation that card payments are initiated by the payer and thus fall within the scope of PSD2 Article 97(1) (b). PSD2 itself (e.g. PSD2 Articles 76–77 and 80 and Recital 82) makes a clear distinction regarding rules that apply to payments initiated by a payer and to another category – payments initiated by or through a payee. We believe that this classification was intentional to distinguish between “push payments” (where the payer initiates the payment without the knowledge and involvement of the payee) and “pull payments” (where the payee initiates the process where the payee has to request, through its PSP, settlement from the payer’s PSP through a series a messages).

• Direct debits and card payments fall within that latter category and should be out of scope of PSD2 Article 97(1) (b), as they are not initiated exclusively by the payer as required in the first level text. In addition, PSD2 Recital 77 sets out very clearly and helpfully the process leading up to the creation of a card payment order indicating that, while the payer may indeed be involved in the processes leading up to the creation and transmission of the payment order, the “payee transmits to the payment service provider payment orders for the collection e.g. of card payments or of direct debits...”

• Consent has to be given for all payment transactions and, for card payments, this may take a variety of forms, e.g. entering a PIN, touching a card against a reader, providing card details to a mail order provider, clicking a buy button on a website etc. That consent, however it is achieved, permits the payee to initiate the payment either immediately or at a future time or date and involves a series of underlying settlement transactions between the parties involved in the process before the payer’s account is debited. The interaction made by the cardholder in whatever form that took, is not the trigger for initiation of the payment order, which is in fact at the absolute discretion of the payee. Unlike card payment authorisation transactions which take place real time, the generation of the payment order takes place later depending on a range of factors such as when the goods and services will be delivered, when a transaction is physically capable of being submitted into clearing systems etc.

• Defining card payments as being initiated by the payer leads to conflict in the application of PSD2 Article 80. For payments initiated by the payer, Article 80(1) applies, which allows the PSU to revoke a payment order before it has been received by the payer’s PSP. However, card payments are unique in that the payer will often be provided with goods or services before receiving funds from the payer’s PSP. This is contingent on the irrevocability of the transaction under Article 80(2) “after giving consent to execute the payment transaction to the payee“.

• While we believe that point-of-sale and proximity card payments, like direct debits, should not be regarded as initiated by the payer and therefore should not be captured under PSD2 Article 97(1)(b), of course we agree that remote card payments are captured in line with PSD2 Article 97(1)(c). This is consistent with the original approach taken when the SecuRePay.

• The payments industry has invested significantly in developing secure authentication of proximity payments, based on EMV standards that have delivered a very secure environment underpinning proximity card payments .The key objective is to extend this approach into less secure, more fraud-prone channels. We see no obvious reason that that new authentication approaches would be needed in relation to proximity card payments or evidence identifying any deficiencies that need to be addressed by legislation.

• The card payments industry has already addressed many of the privacy and security issues through adherence to the internationally-recognised PCI Security Standards Council’s standards ( The PCI Security Standards Council is a global open body formed to develop, enhance, disseminate and assist with the understanding of security standards for payment account security.

• It would be helpful if the EBA ensured that the considerable investment made by merchants, service providers, issuers and acquirers was recognised as providing equivalent protection of assets.

Authentication & Authorisation

• The terminology used confuses ‘authentication’ (the process of proving the identity of the PSU) with ‘authorisation’ (the process of approving the execution of a payment or specific action). For card payments, and in particular the 3D Secure process, the authentication step results in the generation of a code that reflects the results/strength of the authentication process. This is included in a subsequent authorisation request, which results in the generation of an authorisation code that binds the process to a single transaction. The two steps, whilst carried out in real time, are distinct and separate.

• At the EBA Pubic Hearing on 23 September, the impression given was that the EBA had no intention of undermining existing 3D Secure investment and implementations. However, in the context of card payments that currently use 3D Secure processes, the RTS could be read as requiring the user to enter a newly defined authentication code that provides evidence that the user has authenticated and is approving the payee and amount. The existing 3D Secure process would need to be updated to comply with this requirement to accept the new codes, which would result in significant effort and cost to re-engineer merchant websites and payment gateways.

The application of PSD2 Article 74(2)- the obligation for payees to accept SCA

• According to point 19b, of the consultation, card acquiring PSPs “should require payees to support SCA for all payment transactions, in order to allow the payer’s PSP to perform SCA in compliance with PSD2”. To justify this, the EBA argues that Article 74(2) of PSD2, which allows the payee or the payee’s PSP the option not to accept SCA, only applies during the short-time transitional period between the application date of PSD2 (13 January 2018) and the application date of the RTS under consultation (in October 2018 the earliest). During this transitional period, “where the payee or the payment service provider of the payee fails to accept strong customer authentication, it shall refund the financial damage caused to the payer’s payment service provider”.

• There is nothing within in the PSD2 text that indicates that this provision only applies until the application date of the EBA RTS. We also note that the explicit requirement is not in the draft RTS. Nevertheless, the CP seems to imply that card-acquiring PSPs must enforce merchants’ use of strong customer authentication. It suggests that they would be compelled through contractual arrangements to support an approved authentication. Since the RTS provisions are not addressed to the payee (e.g. a merchant) it is difficult to envisage how compliance with these requirements would be achieved.

• We see this as a poor outcome for merchants, who today can accept a lower level of authentication on the basis that they take the liability. This proposed approach would have a significant impact on existing payee business models, such as the ‘one-click’ solutions deployed by retailers such as Amazon, and on the PSU’s experience, resulting in an adverse impact on customer convenience. The reason a merchant may be willing to accept the liability is that it can apply its own risk-based procedures. It certainly would not be in the merchant’s interest to accept the liability and not put in place any mechanisms to counteract that risk.

• We see an inherent danger that large e-commerce retailers, many of whom are looking to develop new frictionless payment experiences for consumers (such as “Amazon Dash”) will be hampered by the inflexible approached to authentication, particularly for low value, low risk repeat orders from regular customers, not being willing to have restrictive requirements imposed upon them. In our view, there is a considerable risk that e-retailers, in these circumstances, might look for PSPs outside the EU, with a consequence for the advancement of the European digital economy.

The application of SCA with dynamic linking

• Our view is that the RTS Article 2 requirements only apply to the initiation of electronic remote payments (including PIS) in accordance with the scope of PSD2 Article 97(2). In other words, the only payment transactions which require the application of SCA with dynamic linking are remote credit transfers (including those initiated via a PISP and batch credit transfers). It would be impossible to apply dynamic linking to various categories of card payments that are not known at the point at which the payer gives consent for the a future transaction (e.g. pre-authorisations used in hotels, online shopping, car rental etc). Authentication takes place prior to a transaction value being determined. The same would be true of contactless transit ticketing, where the value of aggregated fares are computed at a much later point than when the authentication takes place at a reader.

Use of behavioural data versus behavioural characteristics

• EBA rationale point 29 states: “behavioural data cannot be considered as a standalone inherence element, but rather as an additional tool for fraud prevention”. It would be helpful if there was further clarification given on this point as we think there is a distinction to be made between “behavioural transactional data” and “behavioural characteristics”.

• We note that RTS 1(e) point (iii) makes explicit reference to “spending behavioural patterns” as a mechanism to help to prevent, detect and block fraudulent payment transactions. We would agree that, with the current state of technology, such behavioural transactional data should not be considered as a standalone inherence element, as they are not fully predictive. However, there may be a time in the future when the technology advances to a stage where this can be relied upon.

• Currently, other behavioural characteristics are already being used to confirm identity. Behavioural characteristics such as gait (patterns of movement) keystroke dynamics and, importantly, voice biometrics (which we see as closely linked to inherence) can and are being used effectively in strong customer authentication processes. Advanced biometric methods will rely heavily on behavioural data" as an intrinsic part of the process, as otherwise spoofing is likely to be trivially easy."

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.

• According to RTS Article 2(1)(b), in order to satisfy the dynamic linking requirements, the authentication code generated must be specific to the transaction amount and the payee. This will be problematic in the context of card transaction processing. It would be impossible to apply dynamic linking to various categories of card payments that are not known at the point at which the payer gives consent for the a future transaction (e.g. pre-authorisations used in hotels, online shopping, car rental etc), because authentication takes place prior to a transaction value being determined. The same would be true of contactless transit ticketing, where the value of aggregated fares are computed at a much later point than when the authentication takes place at a reader.

• In the case of a mobile contactless payment, the authentication process may be executed ahead of the transaction, so that the phone is ‘live’ before the amount is known. In this respect we welcome the neutral position on when dynamic linking should take place.

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?

• We feel that the key threats have been identified. However, the challenge we face is ensuring that PSUs do not disclose their credentials to fraudsters. The RTS does not and cannot address this risk, but it can help to minimise it. By enforcing expiry times and increasing the complexity of security elements (mainly knowledge factors), there is a risk that PSUs will write down their credentials, or use easier to guess credentials, which defeats the aims of the RTS.

• RTS Article 3(2) looks for mitigations to prevent disclosure, but it is impossible to “guarantee” resistance against unauthorised disclosure of knowledge or prevent PSUs from writing things down or disclosing their details, either deliberately, through social engineering (e.g. scams), or through coercion. The RTS should acknowledge that this risk would be outside the PSP’s control and that any mitigation would be through customer security education and awareness campaigns.

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?

The interpretation of the terms “electronic payment transaction” and “remote payment transaction” in the context of proximity (contact and contactless) card payments.

• The validity of the list of exemptions hinges on what the EBA understands to be the interpretation of the term “electronic payment transaction” as used in PSD2 Article 97(1)(b), throughout the consultation document and in RTS Article 8 but which is not defined.

• It is our understanding, based in part on the context provided in PSD2 Recitals 95 and 96, that the focus of the RTS is intended to be geared towards “ensuring the protection of users and the development of a sound environment for e-commerce” and “payment services offered via internet or via other at-distance channels, the functioning of which does not depend on where the device used to initiate the payment transaction or the payment instrument used are physically located” (PSD2 Recital 95). We have set out elsewhere in our response why we consider card payments are not initiated by the payer and therefore why proximity card payments of all types should be out of scope.

• However, if the EBA disagrees with our analysis then, in order to make the RTS workable, we need to see a much longer list of explicit card-related exemptions. These would include, for example:
 Any card payment that uses or mirrors the EMV Chip & PIN processes (either for proximity or online payments) as these processes would have equivalence for SCA.
 Fall-back transactions where the primary technology fails at the point of sale - where no mechanism exists to authenticate the transaction.
 Cards used in transit or other deferred payment use cases (hotels/ car hire etc) where the amount of the transaction is not known and therefore it is impossible for the payer to initiate the payment because it is contingent on the payee computing the amount to be included in the payment order.
 Card payments which are future dated or contingent upon certain events, e.g. a guarantee for reserving a hotel room in the event of late cancellation.
 Card-based recurring transactions to pay for subscriptions etc. which are similar in nature to direct debits.
 Based on PSD2 Recital 95, we understand that paper-based Mail Order and Telephone Order transactions are entirely out-of-scope.

Concerns about the EBA’s omission of risk profiling/a risk-based approach and some suggested alternatives

• We think that the EBA should make allowance for the fact that the majority of interactions between the PSU and the AS PSP will not involve a third party provider (PISP, AISP, or card-based payment instrument issuer) and, indeed, when one considers “contactless electronic payment transactions at point of sale” (RTS Article 8(1)(b)) it is unclear where PIS (or AIS) would be relevant in this scenario. Accordingly, a level-playing field between AS PSPs and PISPs should only be considered a relevant argument where a third party provider is actually involved.

• We are concerned that the RTS and the list of exemptions do not allow risk profiling/a risk-based approach to be used to determine exemption from SCA. For example, behaviour-based characteristics can be used to analyse the physical behaviour of the customer (e.g. location, type of device etc). By being able to assess, for instance, whether a consumer is at home, on their home computer, making the same payment amount to the same payee as last month an AS PSP can assess the risk and the level of authentication required. Such analysis can act as a kind of ‘invisible’ strong customer authentication, where customers (and criminals) are not aware of what aspects of behaviour are being utilised.

• Risk-based authentication (risk profiling on e-commerce transactions) is industry standard now. So it is a backwards step from an environment of simple yet safe risk profiling of e-commerce to one requiring multiple actions to complete transactions; this would be very visible to customers. We very much support the detailed analysis and arguments set out in the paper “Recommendations for improving European online payments regulation” commissioned by Ecommerce Europe and others which explain the benefits of they term “targeted authentication techniques”. For further detail please refer to the following hyperlink:

• As noted in our previous comments, we believe merchants should also be allowed to apply risk-based approaches as the flip side of accepting liability. We recommend that the following wording should be incorporated: “The application of exempted where the transaction is deemed a low risk by the payee initiating the payment. If the payee does not support SCA or chooses not to apply it for any given transaction, the liability for any fraud arising from that transaction shall lie with the payee who will compensate the AS PSP for any losses suffered as a result of not applying SCA”.

Treatment of contactless proximity payments

• Please see our earlier comments in section 1.1.8, where we set out why we believe proximity card payments fall outside the scope of the RTS.

• In any event, the language used in RTS Article 8(1)(b) is confusing. Point (i) uses the term “contactless electronic payment transaction” in relation to an individual transaction amount, while point (ii) uses the language “non-remote electronic payment transaction” (which is not defined) in relation to the cumulative amount”.

• It is important to note that value does not necessarily equate to the level of risk, which is why we favour application of a risk-base approach as explained in our previous comments. The limits set in Article 8(1)(b) should ideally be subject to scheme and individual PSP risk management analysis and not set by legislation. Legally imposed limits make it harder to respond to changes in market dynamics and can lead to practical implementation issues. For example, increasingly in Europe, contactless payments are being used on public transport to pay for journeys without the need to purchase a separate ticket. The card-readers used, for example, on London’s Underground service do not offer the ability for a customer whose card expenditure happens to have reached the cumulative limit of EUR 150, to switch to SCA at the gate In fact the transaction amount is not known at the point that the cardholder enters the transit system because an aggregated fare is calculated at the end of the day. There is already discussion in various Member States to set the transaction limit applicable to transit at €100 to enable contactless ticketing to extend to medium range journeys to meet consumers demand and allow a wide range of use cases that the transport industry needs. In common with the approach taken in the Interchange Fee Regulation, in relation to application selection, we consider that exemptions should apply contactless transit .

• If contactless proximity payments are to be included then the RTS must recognise the additional risk management controls available in cards. Transaction counters can be just as effective as a risk management tool as single and cumulative spend limits.

• If the EBA is determined to include limits in the RTS, the wording should be amended e.g. “the upper limit as set at a national or card scheme level and periodically revised”. Alternatively, the EBA will need to review the limits regularly.

Exemption for remote electronic transactions

• A one-size-fits-all approach is not practical and will hamper innovation and is likely to damage the customer journey. This is contrary to the principle of allowing the development of user-friendly, accessible and innovative means of payment. The value of the transaction should only form part of the decision-making process as to whether SCA is required by the PSP.

• For example, setting the maximum amount for an individual “remote electronic payment transaction” at EUR 10, would seem to have a severe impact on certain business models, such as those employed by Google Play, iTunes and Amazon and a frictionless customer experience. We noted in earlier comments that merchants, who have accepted liability for not using SCA, should be permitted to apply their own equivalent, risk-based assessments..

• In common with our comments regarding the contactless payment exemption, by setting hard limits in the EBA RTS the approach is not future-proof and it is unclear how the RTS can adapt swiftly to changing market needs.

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?

• We disagree with an approach that would prevent a PSP having the right and an ability to apply SCA as a step up, even on transactions listed within the exemptions. To support this stance, we would draw attention to a notable contradiction in the regulations between the obligations on the AS PSP in RTS Article 1(3)(e) and the potentially unintended consequences of a mandatory exemptions list. According to RTS Article 1(3)(e), the PSP is obliged via its SCA procedure to “prevent, detect and block fraudulent payment transactions before the PSP’s final authorisation”. A key tool in the prevent/detect stages are to make use of security “step up” where risk triggers are hit. Where the SCA exemptions list is made mandatory, it would limit the ability of an AS PSP to make use of step up escalations to manage risk without going to the extreme of blocking a suspect transaction. A mandatory list of SCA exemptions (as set out in RTS Chapter2, Article 8) therefore appears at odds with the objectives of RTS Article 1(3)(e).

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?

• How card issuers issue their PINs to customers is in many cases already defined elsewhere, for example, by scheme or industry rules. We agree that it is important to protect and secure sensitive customer and payment credentials. It is unclear from the draft RTS, whether the EBA has taken into account that, in the case of card payments for example, these are subject to issuance and lifecycle management requirements defined at an international level in the Payment Card Industry Data Security Standard.

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?

• We note that in rationale point 68, the EBA concluded that the RTS “must not prescribe the use of a specific industry standard of internet communication”. Instead it proposes “the requirements with which every communication solution used for secure communication …will have to comply”.

• To what extent have the requirements set out in Chapter 4 been considered and assessed in relation to the existing requirements set by PCI-DSS? The card industry has a set of established standards and requirements that would be difficult and costly to change if there are differences in what the EBA requires.

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?


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 ?


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.


Please select which category best describes you and/or your organisation

[Other "]"

If you selected "Other", please provide details

• The European Card Association is a pan-European industry association representing a broad range of European domestic card schemes and other industry trade associations that bring together industry expertise and experience to evaluate regulatory initiatives and to promote interoperability and open standards.

Please select which category best describes the services provided by you/your organisation


If you selected "Other", please provide details

• The European Card Association is a pan-European industry association representing a broad range of European domestic card schemes and other industry trade associations that bring together industry expertise and experience to evaluate regulatory initiatives and to promote interoperability and open standards.

Name of organisation

The European Card Payment Association