Joint response from Payments UK, Financial Fraud Action UK and The UK Cards Association

• 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.
• We have sought to highlight where the draft RTS appear to be out-of-line or seem to contradict these aims and the EBA’s stated preferred options.
• In some areas we think the draft RTS are:
• Insufficiently flexible to accommodate future developments
• Too prescriptive
• Require approaches which are already outmoded or go against current convention or industry best practice.
• In some cases we do not fully understand the terminology used or how the requirement should be applied.
• The EBA RTS need to be clearer about the scope and scenarios to which they apply and those activities or transactions which are deemed to be entirely out of scope. We have some questions as to how certain types of transaction should be treated.
• The EBA RTS need to differentiate more clearly between the requirements for card payments and non-card payments as well as remote versus proximity. 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).
• 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). We are also concerned about the potential impact on 3D Secure.
• We note that several points of interpretation and clarification in the rationale have not been reflected in the draft RTS.
• We challenge the interpretation of the application of PSD2 Article 74(2) although we appreciate that this is based on the EBA’s understanding of joint discussions held with the European Commission and competent authorities of the Member States as part of the transposition process.
• We have concerns about the EBA’s approach to the exemptions and the omission of risk profiling/a risk-based approach which we detail in our response to question 4, alongside some suggested alternatives for the EBA to consider.
• We are unclear as to how quickly the EBA can adapt and update the RTS provisions in reaction to changing market conditions.

We elaborate on these general points in sections 1.1 of our response to question 1 before focusing, in section 1.2, on specific comments and questions relating to RTS Articles 1 to 7.

1.1.1 We support the policy objectives referred to in point 3 of the Consultation Paper (CP), which are taken from PSD2 Article 98(2). We also fully appreciate the conflicting trade-offs the EBA has tried to balance. However, we feel that in some places the draft EBA RTS appear to be out of line with, or contradictory to, these aims and the EBA’s stated preferred options as summarised on pages 48-49.
• We take the view that wherever possible, the EBA RTS should be principles-focused, centred on openness, transparency, accessibility, usability, user control, security, extensibility and interoperability.
• 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 PSD2 definition of strong customer authentication and the EBA’s interpretation thereof can be just as effective if not 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.
• 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 and reacting to cybercrime and fraud threats adequately and the requirements will quickly become outdated (indeed some are already out of date), and it may be more difficult to innovate.
• We appreciate that one of the trade-offs considered was customer convenience versus a high degree of safety and security (point 6) but would like to understand the extent to which the EBA has factored in the increased amount of friction that the RTS will bring (where merchant shopping card abandonment is a significant issue) – especially when coupled with the limited list of SCA exemptions in Article 8 - against the fraud protection benefits. Ultimately, our concern is that European consumers are denied the opportunity to conduct e-commerce in a frictionless but secure way to the detriment of the development of the European digital economy and innovative payment products and mechanisms.
• 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.
• Payments UK is supporting the UK industry in its response to the UK Competition and Market Authority’s proposed remedy that an open banking API standard should be developed ( The EBA’s RTS will have a significant impact on the functionality of this open banking environment, some of which will be implemented in advance of the rest of Europe, with the dates aligned to the transposition date of PSD2 (13 January 2018). Many of the issues that will need to be worked out in the context of PSD2 will be addressed through the CMA work. As there are strong inter-linkages, we would be happy to share learnings from this with the EBA as the process matures over the coming weeks and months. In our response to the consultation we have tried to highlight where there seem to be discrepancies between the stated requirement and the overarching aims or where there appear to be risks of unintended consequences.

1.1.2 In a number of areas we do not consider that the RTS are sufficiently flexible to accommodate future developments, i.e. they are not ‘future proof’.
• For example:
a. We have concerns about the suitability and long term viability of the low-value payment limits applied in Article 8 versus application of SCA and the extent to which they take into account experiences in different Member States. We set out later in our response why 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 (e.g. the extension of Contactless Ticketing on the Gatwick Express). We see no evidence of empirical risk analysis in the CP 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 expand on these concerns in our comments on RTS Article 8 and our response to question 4. (

b. Wearable payments technology does not even have SCA fall-back, i.e. it cannot be inserted into a chip and PIN machine and the cumulative ‘counter’ and limits in the contactless SCA exemption would be problematic. The RTS could eradicate this type of innovation.

c. Looking further to the future, what would be the strong authentication requirements for internet of things-based devices where payments are pre-authorised (in most cases) and the user has no direct input? These payments would appear to be in scope of PSD2. Is the device registration/pre-authorisation process sufficient under PSD2 or would strong customer authentication be required in each case? Developments such as the self-shopping fridge are possible in the future. However, we consider that the RTS, as currently drafted, have the potential to quash this sort of innovation and other moves towards 'invisible' payments.

d. Exclusion of behavioural data per se restricts a host of security elements (such as voice and key strokes). We expand on the subject of ‘behavioural analysis’ and the need to distinguish between ‘behavioural transactional data’ and ‘behavioural characteristics’ in our comments relating to RTS Article 5 and in our response to question 4.

e. Consumers will likely use their fingerprint to unlock their mobile device (e.g. to access text messages) as well as use it to login to online banking. The ability to use fingerprint technology for SCA may be called into question depending upon the meaning of ‘segregation of channel, device or mobile application’.
• 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.

1.1.3 The EBA RTS on strong customer authentication (SCA) and secure communication apply across all payment service users and, as such, the framework needs to be workable for businesses as well as consumers.

• Paragraph four of the Executive Summary of the CP states: “The draft RTS proposed in this consultation paper, together with the provisions already stated in the PSD2 itself, set out a harmonized framework that is aimed at ensuring an appropriate level of security for consumers and Payment Service Providers...”. Our understanding is that whilst there is a strong emphasis on consumer protection within PSD2, the scope of the RTS applies across all types of payment service user (including businesses as well as consumers) since Articles 65, 66, 67 and 97 to which these RTS relate are not listed in the ‘corporate opt-out options’ set out in PSD2 Article 61(2).
• At the EBA Public Hearing on 23 September the EBA appeared to acknowledge that the focus of work to date had been on consumers and asked for further information about the corporate experience. We set out below some issues for the EBA to consider and where clarification is needed to understand whether and how the SCA requirements apply.

Business/Corporate Scenarios
• The draft RTS do not address how corporate mandates (which may often involve dual approval requirements) should be handled. This will be especially important to understand in the context of PIS and AIS, provision of which is not limited to consumers. Similarly, the draft RTS (including RTS Article 2(4)) do not sufficiently cater for scenarios such as (i) authorising a file of imported payments; (ii) bulk authorisation of multiple single payments in a single request; and (iii) bulk authorising multiple single international payments involving different currencies.
• Corporate products and services are used and operated in ways that differ to those provided to consumers as the relationship with the end user is often one step removed. Virtual, Prepaid and Embedded solutions are designed to make specific payment scenarios easier for the corporate (such as paying suppliers or temporary staff). Applying SCA would be extremely difficult to achieve without severely damaging or restricting ease of use of the product.
• We believe that file transfer solutions (where corporate banking systems connect straight to a PSP via a host-to-host connection) should be exempt from the SCA requirements for the following reasons:
• The information is exchanged between one machine and another with no human interaction – there is no concept of end user - thus the concepts of knowledge, possession and inherence would not apply between machines;
• Where files exchanged are created using electronic forms to capture (payment) data from individual users, the screens, processes and entitlement frameworks to do so reside under the full responsibility and within the protected environment/infrastructure (e.g. premises, intranet) of a corporate client and are not exposed over the internet. Thus the host-to-host environment is very tightly controlled;
• Secure communication with encryption or corporate seal is part of a unique host-to-host connection set up between the corporate and the PSP and the risk is low. For example, a virtual connection will be opened in order for information to be shared between machines. Before this connection is made, the corporate’s machine will provide a user ID and password (which is specific to that corporate and only known by that machine) to their PSP’s machine. If these credentials are correct, the two machines will swap virtual ‘keys’. The keys are specific to the corporate and the PSP. If these keys are correct, the information is then sent through the virtual connection from the corporate machine to the PSP’s machine. The information has a digital signature applied to it, which allows the PSP’s machine to detect whether the information has been changed since leaving the corporate machine.
• Certain AS PSPs who provide services to corporate customers with large Treasury functions may, in addition to the treasury staff, have multiple third party providers utilising view only access to their payment accounts. Applying SCA in this situation would be quite onerous and challenging to implement and maintain. It would also provide a poor customer experience for customers to be required to have each of their registered users set up for SCA where those registered users only require view access. Many banks operating in this space will offer their clients the ability to create user hierarchies, specifically so that they can control who has access to payment data only versus those with authority to initiate payments, etc.
• Similarly, some banks may fulfil particular roles that require them to have access to client transactional data and other reporting information.
• In business/corporate scenarios there is a clear distinction between user authentication at the time of logon (which uses SCA) and the approval/authorisation of the transactions or activities, which may be a multi-stage and multi-user process (which may also use SCA).

1.1.4 Use of terminology: ‘payer’ versus ‘payment service user’
• The draft RTS do not always differentiate between SCA requirements where it is appropriate to use the term ‘payer’ and those where a distinction might usefully be made using the term ‘payment service user’ where the activity (such as accessing the payment account online or utilising an account information service) does not necessarily involve payment initiation and thus a ‘payer’, for example in Articles 8(1)(a) and 17(1).

1.1.5 The terminology used in the Articles (particularly in Chapter 1) seems to confuse authentication (the process of proving the identity of the payment service user) with authorisation (the process of approving the execution of a payment or specific action). We are also concerned at the potential impact on 3D Secure.
• The requirements for strong customer authentication mix elements of what the industry considers to be part of the authorisation process with the authentication process. The PSD2 definition of “authentication” (PSD2 Article 4(29)) makes it clear that authentication is limited to a “procedure which allows the PSP to verify the identity of a PSU or the validity of the use of a specific payment instrument, including the use of the user’s personalised security credentials”.
• The problem is best illustrated in the requirement in RTS Article 1(1) that the authentication procedure “shall result on the generation of an authentication code that is accepted only once by the PSP each time that the payer [PSU] making use of the authentication code accesses its payment account online, initiates an electronic transaction or carries out any action through a remote channel which may imply a risk of payment fraud or other abuses”. While RTS Article 1(3)(e) explicitly makes reference to authorisation.
• Typically in the UK, PSPs’ processes often involve a clear separation between authentication of the PSU and the approval/authorisation of a transaction/activity which may be a two stage process.
• 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 of 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 Public 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 underlying card protocols might also require updating to accommodate the new authentication codes to be carried through card processing interchanges correctly – where interoperability is critical for the smooth processing of transactions across the industry. We would expect updates to take a considerable amount of timed to ripple though. By way of illustration, the implementation of 3D Secure itself took a decade to gain universal support in the UK market alone. 3D Secure is triggered by the merchant. Even if steps could be taken within the EU to mandate 3D Secure for all card transactions, given the view that the requirement applies to one-leg payments, this would be difficult to mandate globally.

1.1.6 The draft RTS do not appear to differentiate sufficiently between the requirements for card payments and non-card payments.
• The EBA RTS requirements need to be workable in the context of a global payment mechanic where universal interoperability is expected by card-holders and is vital to the success of cards in a retail payments environment. Having to adhere to regional requirements at the expense of this global interoperability would be counter-productive and it may have unacceptable consequences for international retailers and payment service users who transact on such retailers’ websites. It is likely that, to avoid the obligations set out in the RTS, some merchants will offshore their operations in order to maintain their existing business processes, although at the EBA Public Hearing on 23 September, the EBA and European Commission’s view appeared to be that if the issuer/payer’s PSP was located in the EEA, SCA was applicable irrespective of the domicile of the merchant/service provider.
• 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.

1.1.7 Several points of interpretation and clarification have not been reflected in the actual draft RTS.
• We note that, as part of the rationale, the EBA has included several points of interpretation and clarification of the PSD2 provisions, notably in points 15-19. While we appreciate the underlying intention, we have a number of comments and questions in this regard. We also think it is important, and in the absence of any official communication in this regard from the European Commission (e.g. in the form of FAQs), that appropriate clarifications are included in the RTS Recitals or in the exemptions in RTS Article 8.

1.1.8 In relation to the EBA’s interpretation of the payment types in scope of PSD2 Article 97(1)(b) we question the view that point-of-sale and proximity card payments fall into the category of payer initiated electronic payment transactions, although we agree that remote card payments are captured under PSD2 Article 97(1)(c).
• PSD2 does not define the term “electronic payment transaction”, which is used in PSD2 Article 97(1)(b). Yet it is crucial to understanding the scope of application of SCA (including the dynamic linking requirement) and any exemptions. When interpreting the term “electronic payment transaction” the EBA indicates in rationale point 17 that the scope of payment instruments to which PSD2 Article 97(1)(b) applies is “electronic payments initiated by the payer, such as credit transfers or card payments, but does not apply to electronic payments initiated by the payee only, such as direct debits”. We also note that In point 52, the EBA refers to preserving “the safe authentication of the user and the high level of security currently achieved for cards payment transactions at point of sale by the EMV Chip & Pin technology”.
• 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“.
• The payments industry has invested significantly in developing secure authentication of card present payments, based on EMV standards that have delivered a very secure environment underpinning card present payments. The key objective is to extend this approach into less secure, more fraud-prone channels. We see no obvious reason 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.

1.1.9 Understanding what is in or out of scope of PSD2 Articles 97(1)(a) 97(1)(c)
We are keen to understand what is or is not in scope of the RTS as this is not made entirely clear and we have set out below our current understanding.

Direct Debits
• According to point 17 (although this is not made clear in the RTS), “electronic payments initiated by the payee only, such as direct debits” are out of scope of PSD2 Article 97(1)(b). Point 18 seems to be saying that if the payer’s consent for a direct debit is given in the form of an electronic mandate “wherever PSPs are involved in the signature of the e-mandate, either through direct communication with the payer or via the payee’s PSP”, it falls within the category of activities covered by PSD2 Article 97(1)(c). We note that at the EBA Public Hearing on 23 September the EBA seemed to indicate that this was a specific reference to the electronic mandate option as set out in Annex VII of the SEPA Direct Debit Core and Business-to-Business Scheme Rulebooks (or equivalent). Nevertheless, we remain unclear what this means in practice and some illustrative examples would be helpful.
• We currently assume that direct debits set up from paper or telephone mandates or via online processes in a creditor mandate flow model where there is no direct involvement of the payer’s PSP with the payer (and thus no ability to apply SCA) would be out of scope entirely of the RTS.

ATM balance and transaction checking and ATM cash withdrawals and payments
• We assume that the EBA has no expectation that the RTS should be applied to balance and transaction checks, cash withdrawals or payment initiation via ATMs although this is not made clear in the CP.
• While the networks that support these machines use phone lines, internet access and central computers to distribute information and facilitate transactions, there are specific fraud protections that apply to ATMs. ATM networks are walled ecosystems where operators have to adhere to robust requirements to protect the physical security of their devices and user credentials. This means that the risks associated with activity that happens on them are vastly different, for example, to online activity (in the commonly used sense of the term).
• Also, as we have noted elsewhere, we believe that proximity/face-to-face transactions using a card should be out of scope of PSD2 Article 97(1)(b).
• If the EBA holds a different view then clearly the RTS proposals around dynamic linking and the exemptions would not be workable as currently written when applied to ATM activities.

Remote card payments
• 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), we agree that remote card payments are captured in line with PSD2 Article 97(1)(c).

1.1.10 Use of the PISP’s own credentials versus reliance on the AS PSP’s authentication procedures is not reflected in the RTS Articles or Recitals
• From our reading of point 19a, we assume the expectation is that, in the majority of cases, the PISP is expected to rely on the authentication procedures provided by the AS PSP, which would also be in line with RTS Article 19(1)(c). However, should the PISP issue its own credentials, we welcome the statement that this would “require a prior contractual agreement between the PIS [sic] and the AS PSP on the acceptance of such credentials by AS PSP”. This would be very much in line with our own view that AS PSPs and TPPs should own and control the methods by which they authenticate their own customers. We also understand this to mean that there would need to be a formal contract between the AS PSP and the PISP whereby the AS PSP would agree to accept the PISP authenticating the PSU subject to clear liability agreements being in place. However, we note that this point of interpretation in rationale point 19a has not been explicitly reflected in the text of the draft RTS in either the Recitals or the Articles. Nor has the European Commission issued any clarification in this regard.

1.1.11 We challenge the interpretation of the application of PSD2 Article 74(2).
• The EBA made it very clear at the Public Hearing on 23 September that its interpretation of the application of PSD2 Article 74(2) as stated in rationale point 19b derives from joint interpretation between the European Commission and the competent authorities of the Member States during transposition discussions. We intend to raise our concerns directly with these parties but have nevertheless set out below our reasoning in this regard.
• According to point 19b, in the context of remote card payments, card acquiring PSPs (“acquirers”) “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”. In our opinion, the SCA requirements concern issuers of payment instruments and AS PSPs but does not bind acquirers or merchants. Rather, acquirers and merchants may make a deliberate decision not to apply SCA and to bear the risk of ultimate liability pursuant to PSD2 Article 74(2) instead. A payment transaction may not only be authorised prior to the execution of a payment transaction, but may also be authorised by the payer after the execution of a payment transaction (cf. PSD2 Article 64(1) sentence 2). The clear wording of PSD2 Article 64(1) shows that there can be transactions where a payee initiates a payment transaction without a formal authorisation by the payer.
• The first sentence of PSD2 Article 74(2) makes it clear that if the payer’s PSP fails to apply SCA, the payer will only be liable for fraudulent activities. The second sentence allows the payee or the payee’s PSP the option not to accept SCA, by providing a liability shift where SCA is not used in order to protect payers from damage through unauthorised payments and to allocate liability to the responsible party. The payer's PSP is therefore indemnified by the acquirer and the merchant. Conversely, a payee or the payee's PSP may – at their own discretion – accept and process payment instructions even where neither the payer nor the payer's PSP have requested SCA. Article 74(2) is also necessary to allocate risk and liability as well as to ensure consumer protection even in cases of technical malfunction of authentication systems or discretionary acceptance of payment instructions without SCA. This mechanism provides for an equitable solution since payers are protected against the consequences of unauthorised transactions while maintaining a risk-based (and cost-efficient) application of SCA by acquirers and merchants.
• The EBA argues that PSD2 Article 74(2) 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
• We are seeking confirmation of the payment transactions in scope of the dynamic linking requirement.
• We found the wording of the question somewhat confusing but support the idea that requirements should remain neutral as to when the “dynamic linking” should take place. We take the view that the RTS should provide discretion for PSPs to determine (i) how they implement dynamic linking of a transaction and (ii) whether the dynamic linking of a transaction is made visible to the PSU.
• We are seeking further clarification about the meaning of the terms “segregated” and “independent” as used in RTS Article 2(2).

2.1 Understanding the payment transactions in scope of the SCA dynamic linking requirement
• Please see the comments (in section 1.2.9) in our response to Question 1.

2.2 Understanding the question and the issue of how and when dynamic linking takes place
• We found the question somewhat confusingly worded. However, we support the idea that requirements should remain neutral as to when the “dynamic linking” should take place. We take the view that the RTS should provide discretion for PSPs to determine (i) how they implement dynamic linking of a transaction and (ii) whether the dynamic linking of a transaction is made visible to the PSU.

o We note that rationale point 24 indicates that “the authentication code can be either a single piece of data that is being input by the payer on the interface of the relevant PSP or can be generated from several pieces of data, such as a one-time password that is being input by the payer on the interface of the relevant PSP, the amount, and the payee of the transaction. Alternatively, the authentication code can take the form of digital signatures of such data using keys stored in the authentication elements”. We found the final sentence in this paragraph particularly helpful (as an example) as the basis for allowing more innovative solutions and would like to see it reflected in the final version of the RTS. While the reference to digital signatures is too specific, alternative wording along the lines of “digital signatures or other cryptographically underpinned validity assertions” (e.g. Hashed Message Authentication Codes (HMAC)) would be preferred.
o In relation to mobile banking applications, we believe that the use of cryptographic keys associated with the mobile app can be used as part of the dynamic linking process. These provide, by way of comparison, considerably greater security than one-time passcodes.
o Rationale point 25 states: “This clarification means, for example, that the one-time password (OTP) linked to the amount and payee may be alternatively generated by the payer’s PSPs with or without any action required by the payer itself, according to the technological solution adopted”. We support the flexibility this approach appears to allow. In our view, solutions where the user has to input this data do not offer any fraud prevention benefit over and above those that do not require payer intervention - a nefarious actor would just input the same data twice - but the customer journey contains far more friction, which in turn would have a negative impact on e-commerce.
o If the payer initiates a payment via the Mobile Application and the PSP must provide information linking the transaction to a specific amount and a specific payee (as part of the authentication procedure) we assume there is no expectation that the PSU would be required to temporarily exit the Mobile Application to review the information prior to SCA being applied as this would mean that biometric capabilities will not be provided to the PSU as part of the authentication procedure which would undermine one of the strongest authentication options available.

• 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.
o This may be problematic in the context of card transaction processing, if cards are deemed to be in scope of the dynamic linking requirement (please see our earlier comments e.g. in section 1.1.8 as to why we think that card payments fall outside the scope 97(1)b and of 97(2)). Where a solution is deployed that relies on a customer generated code in a 'card not present' scenario, there needs to be a standard way of identifying the payee across the industry.
o 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.
• As highlighted in our earlier comments on RTS Article 2(4) guidance is needed for authorisation of different types of batch payments (e.g. authorisation of a file of payments/batch authorisation of multiple single payments/authorisation of a single debit with multiple credit payments/authorisation of payments in different currencies) especially if it expected that details will be shown to the payer in the authorisation request.

2.3 Understanding the meaning of “segregated” and “independent” as used in RTS Article 2(2)
• We agree with RTS Article 2(2)(b) that the authentication procedures should ensure “the confidentially, authenticity and integrity of the information displayed to the payer through all phases of the authentication procedure including generation, transmission and use of the authentication code”.
• The following statement in RTS Article 2(2)(b) is not clear: “The channel, device or mobile application through which the information linking the transaction to a specific amount and a specific payee is displayed shall be independent or segregated from the channel, device or mobile application used for initiating the electronic payment transaction”
• We note that in rationale points 30 and 31, the EBA appears to recognise that mobile devices such as a mobile phone or tablet can be used as an authentication element as well as the device used to read or store another authentication element and that technical solutions exist to mitigate risk of compromise. We seek further clarification on the meaning of “segregated” and “independent” as used in RTS Article 2(2) as to whether different channels or different applications on the same device would be considered compliant, although rationale 26 seems to suggest that using separate channels is sufficient: “This can be done, for example, via an independent channel to prevent any manipulation of the transaction details through the initiation process of the payment transaction.” We also believe that clarification is required as to whether access to each channel or mobile application must also be segregated. For example, fingerprint enabled phones are becoming increasingly common and AS PSPs are utilising this technology for access to their mobile banking applications. However, the way in which the device is unlocked (and subsequently allows access to text messages) would be same way in which the mobile application is accessed. Would they still be deemed to be segregated?
• In particular, the requirement is confusing if looked at from a Mobile banking perspective, when the definition of “independent…from the channel” becomes crucial. If it means a separate device, then it will be an issue for Mobile banking and clearly can’t be achieved in practice without the introduction of a separate device, although we note that at the Public Hearing the EBA stated that there was no intention of requiring PSUs to have two mobile phones. However, if it means a payment can be initiated in a Mobile app and it is validated through a push notification or one time code via SMS to the same device then it is possible to achieve the same outcome. We think the standard can work for internet banking but will need updating for mobile banking scenarios taking in to account advances in security technologies including device profiling, biometric and behaviometric solutions.
• Many current electronic banking systems will feature channel generation of an authorisation challenge code based on the payments being authorised that is entered into a device which is independent of the channel (such as a card and reader with separate PIN). The resulting response code is displayed on that independent device and then entered back into the channel.
• We think the key threats have been identified. However, the ultimate 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 or though social engineering (e.g. scams) or 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 (see also our comments in our response to Question 6).
• We note that the threat of repudiation (where a PSU denies that they were responsible for a transaction) i.e. first party fraud is not addressed in the RTS.
• We do not think the EBA should be prescriptive about the threats against which authentication elements should be resistant.
• The validity of the list of exemptions hinges on the interpretation of the terms “electronic payment transaction” and “remote payment transaction” where we have a different interpretation from the EBA, particularly the application of SCA or exemption thereof in the context of proximity (contact and contactless) card payments.
• We have significant concerns about the EBA’s approach to the exemptions and the omission of risk profiling/a risk-based approach as well as some suggested alternatives.
• We are seeking further clarification about the term “sensitive payment data” and whether the ECB “Assessment Guide for the Security of Internet Payments” (February 2014) remains valid.
• We have some questions and potential concerns about the detailed RTS Article 8 provisions, especially in connection with access to information and the treatment of the contactless payments and remote electronic payments exemptions.
• We believe the exemptions need to take into account services designed to promote financial inclusion and equality and also services designed for corporates.

4.1 Interpretation of the terms “electronic payment transaction” and “remote payment transaction”
• 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;
• The interpretation of the PSD2 Article 4(6) definition of “remote payment transaction” as used in PSD2 Article 97(2) and RTS Article 8(2)(d).
• In this connection please see our earlier comments (e.g. in sections 1.1.8, 1.2.9. and 1.2.11).
• 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.
• As mentioned in section 1.1.9, we assume that the EBA has no expectation that the RTS should be applied to balance and transaction checks, cash withdrawals or payment initiation via ATMs. If not then the exemptions (for instance Article 8(1) and 8(2)(d)) would need to be adapted to be workable in an ATM scenario.

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

Areas of Concern
• We see from rationale points 43 and 44 that the EBA was faced with trying to balance divergent views, particularly between AS PSPs and PISPs, with the latter seeking “a high level of security, transparency, a level-playing field, and to expose the payer to SCA on a regular basis”. We note in section D on page 47 of the consultation document that the EBA considered two options when considering its approach to the exemptions: option 2.1: “develop an exhaustive list of scenarios and criteria which would prescribe exemptions”; and option 2.2: “develop a non-exhaustive list of scenarios and criteria …allowing [the] PSP to apply additional exemptions based on the PSP’s own transaction risk analysis”. On page 48 the EBA confirms that it has gone ahead on the basis of option 2.1, namely an exhaustive list, “which specifies a list of conditions to apply exemptions from SCA”. We strongly believe that option 2.2 would constitute a more effective approach for customers and providers alike. The danger of publishing an exhaustive list is that it provides a target for fraud as fraudsters will know what types of transaction may avoid SCA and will focus their attention on these areas.
• In rationale point 41, the EBA acknowledges that the exemptions “constitute a part of the authentication procedures performed by the …AS PSP”. If the AS PSP is responsible for the authentication procedures, it should also have a degree of control over how it applies any exemption, bearing in mind that the AS PSP is also first in line to take the liability risk in the event of a claim of, for example, an unauthorised or incorrectly executed payment transaction.
• 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, the level-playing field issue should only be considered a relevant argument where a third party provider is actually involved.
• At the Public Hearing on 23 September, it appeared the expectation is that the payer’s/issuer’s PSP/AS PSP should apply SCA first (unless the transaction falls within the exemptions) and afterwards can, in addition, apply a risk-based approach before final authorisation.
• 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.
• Our concern about the omission is mainly customer experience related. Our Members have successfully used risk profiling on e-commerce transactions for some time. By way of a specific example, one member has used this approach for the last six years with no uplift in fraud levels and estimates that it has allowed the authorisation of approximately 95% of transactions in a way that is invisible to the customer. This is better for the customer and the merchant, who experiences fewer drop-outs. Such profiling is advanced and assesses multiple elements to decide whether to either: (a) allow the transaction to pass, (b) interrupt for additional information or (c) block it all together. In addition, PSD2 itself includes a number of provisions, which provide significant protection to the PSU against fraud, possible abuses and payment incidents regardless of whether SCA is applied or not.
• Underlying remote card fraud in the UK are considerable differences in the fraud performance of various retail sectors. This means for example that of the over 700 separate unique retail merchant sectors for which fraud data is collected, the top 10 of e-commerce fraud prone merchant sectors represent over 50% of the total UK domestic e-commerce fraud, and over 45% of the total international e-commerce fraud. In contrast, the 10 merchant sectors with the least fraud represent less than 0.01% of domestic and international e-commerce fraud combined. The RTS, as currently drafted, would apply the same authentication model to all of these merchants.
• Differing businesses and business models present an inherently different risk, which means that a one size fits all approach to authentication is unnecessary and inappropriate. Even in high fraud prone sectors, for example, betting/gaming, which represents circa 5% of all domestic e-commerce fraud, it is important to note that, for the retailer, fraud would also only crystallise as a loss when winnings are paid away. In common with other digital content or service providers, where no physical goods are involved this is likely to increase merchant appetite to risk.
• It is also important to note that it has been calculated that prevented fraud totalled £1.76 billion in 2015. This represents incidents that were detected and prevented by PSPs and is equivalent of over 70% of attempted fraud being stopped. This demonstrates the effectiveness of existing approaches.
• Removing the PSP’s ability to risk profile certain products (prepaid and virtual card), where fraud levels are almost non-existent, will mean that these products will be removed from sale as there is no way to manage the strong customer authentication process on these products. Such an outcome is hardly in line with the stated PSD2 of allowing or encouraging “innovative means of payment”. These are corporate products where the PSP has no direct relationship with the end cardholder, making strong customer authentication impossible. See also point 4.10 below.
• Risk-based authentication (risk profiling on e-commerce transactions) is pretty much the industry standard now, and almost every UK card issuer employs this technology. So it is a step backwards 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 what they term “targeted authentication techniques”. For further detail please refer to the following hyperlink:

Alternative approaches for the EBA to consider
• As noted in our comments in point 1.1.11, we believe merchants should also be allowed to apply risk-based approaches as the flip side of accepting liability. Thus an exemption akin to the following should be considered:
“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”.
• In rationale point 54 the EBA acknowledges that “there is merit in implementing a transaction risk analysis as part of the SCA procedure … [but] “was not able to identify which minimum set of information the RTS should require for such transaction risk analysis to be sufficiently reliable to allow a specific exemption from the application of SCA”. We understand that the EBA is interested in examples of criteria used in risk-based systems and we set out below some suggestions:
• User and Device Information: (i) user behaviour/profiling; (ii) device ID (genuine customers use the same device time and time again, which allows a lower risk score to be given to what is seen as a trusted device. If the device changes the score would reflect this); (iii) browser (much like device ID); (iv) device type (e.g. iPhone, iPad, Android, PC); (v) geo location (IP address/IP routing type, region).
• Transaction information: (i) payee type; (ii) payee name; (iii) payee location; (iv) transaction amount; (v) transaction amount; (vi) payee URL.
• Wording for an exemption on this basis could be along the following lines:
“The application of SCA… is exempted where the transaction is deemed to be low risk by the AS PSP based on criteria such as: the level of frisk of the transaction; previous spending patterns; use of behavioural indicators such as device ID, IP address…”
• Such risk-based processes must incorporate a mechanism so that where the criteria are not met, SCA is invoked instead. PSPs must satisfy themselves on a frequent basis that their risk profiling framework is effective. Such an approach may be used provided that PSPs are able to evidence to their competent authority that they are monitoring and regularly adjusting their risk-based model to manage fraud risk.
• Conceivably, the RTS could state that PSPs can use a risk-based profiling exemption provided their fraud level does not exceed X%. Given more time we could probably give a better indication of what ‘X’ should be.
• Alternatively, a fixed value threshold might be used to force the default to SCA. While we think this would be straightforward to include in the RTS and to enforce, we do not believe that it would be successful in practice. This is because an appropriate value limit would vary considerably from PSU to PSU and from payee to payee (no one size fits all) which could undermine the benefits. However, if the EBA was minded to take this route, we could suggest a high threshold (measured in thousands of euro) where SCA always has to be used with a duty on the PSP to revert to SCA in circumstances where the risk profiling suggested a transaction was risky.

4.3 RTS Art 8(1)(a) – interpretation of “sensitive payment data”
• PSD2 Article 4(32) defines “sensitive payment data” as “data, including personalised security credentials which can be used to carry out fraud. For the activities of PISPs and AISPs, the name of the account owner and the account number do not constitute sensitive payment data”.
• In rationale point 49 there is recognition that sensitive payment data “may differ from one payment instrument to another” and in point 50 the EBA notes that it has decided not to provide further clarification. The implication is that PSPs are left to interpret what payment data is sensitive and what is not, with the result that exemption RTS Article 8(1)(a) will be applied in a fragmented manner.
• We note that the ECB “Assessment Guide for the Security of Internet Payments” (February 2014 - goes into some depth (on page 8) about the definition of sensitive payment data “that could, depending on the circumstances under which the data are used, be considered as sensitive payment data” and provides an indicative list of elements, which include:
• data enabling a payment order to be initiated, e.g. payment account identifiers of the customer stored at the PSP (such as IBAN but not BIC), payment card data (PAN, expiry date, CVx2);
• data used for authentication (e.g. customer identifiers such as client number/login name; passwords, codes, PINs, secret questions, reset passwords/codes; phone number, certificates);
• data used for ordering payment instruments or authentication tools to be sent to customers (e.g. client’s address, phone number, e-mail address);
• data, parameters and software which, if modified, may affect the legitimate party’s ability to verify payment transactions, authorise e-mandates or control the account (e.g. “black” and “white” lists, customer-defined limits, etc.).
The Assessment Guide was intended for use by supervisory/competent authority staff. Can it continue to be used as guidance in the context of PSD2 and the EBA RTS?

4.4 RTS Art 8(1)(a) points (i) and (ii) – access information online and frequency of access
• For the purposes of SCA can two elements be from the same category? If not then we have some concerns as many AS PSPs only require user name and password for login only purposes to view balances and transactions (assuming this is what is meant by “consultative services” as used in rationale point 48 and described as “information of its payment account online” in RTS Article 8(1)(a). Further clarification in this regard would be welcome). Indeed, some PSUs, who do not require access beyond this extent as they do not carry out payments, are not issued with any additional authentication tools. Forcing use of a form of SCA where the two elements must each come from two different categories for payment account access will mean issuing all customers with card readers, tokens or equivalent regardless of whether they are ever going to make an online payment/perform a high risk action. There will be significant concomitant costs related not just to the need for additional cards/readers/tokens but also a reengineering of roles, privileges models and other application logic changes. In addition, if authentication codes are needed constantly for routine events like logging in, it potentially opens up new social engineering opportunities for fraudsters and, at the same time, customers become de-sensitised to the use and importance of SCA. For example, if a security device (possession) is used at login, the fraudster can exploit this step to fool the user into authorising a fraudulent transaction through a message such as “your credentials have expired – you will receive a test authorisation message for £xx to account ending yy – please use your security device to approve this to complete the login process”.
• RTS Article 8(1)(a) point (ii) exempts SCA where the PSU has logged in during the past month with SCA. The requirement to complete SCA at least once a month, especially where multiple accounts are involved, risks destroying the AISP proposition which, to be successful, must provide a simple and efficient experience. If this requirement remains then we would prefer a longer length of time (e.g. six months) to be specified.

4.5 RTS Art 8(1)(b) - 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.
• Card counters typically monitor the number/value of offline transactions. Upon reaching set limits, a request for online authorisation is triggered. To amend this to trigger CVM, significant development would be required to card and terminal specifications. This would pose additional challenges - where the amount is not known in advance or where the contactless terminal cannot support CVM (e.g. transit) - as would the scenario of one-leg transactions, where an EU Issuer would have to influence terminal specifications of non-EU merchants in order to comply. Additionally, the no CVM limit is set on POS, the expectation that the mandatory SCA exemption must apply to one leg transactions is unachievable given that the no CVM limits are decided at a market level through alignment with domestic PSPs.
• 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”. In relation to the latter, does it mean both contactless payments and other payments made at physical point of sale? How would the following be treated in this context: purchasing a product or service face to face, but using a mobile device to make the payment through a remote channel (e.g. Zapp ( , PayPal etc.)?
• 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-based approach as explained in our comments in section 4.2.
• The limits set in Article 8(1)(b) should ideally be subject to scheme and individual PSP risk management analysis and not set by the regulator. Setting hard limits in regulation makes it harder to respond to changes in market dynamics and can lead to practical implementation issues. For example, increasingly in the UK, contactless payments are used on public transport to pay for journeys without the need to purchase a separate ticket and are designed to facilitate throughput and customer convenience, using the contactless functionality on debit and credit cards and pre-paid smartcards such as an Oyster card ( 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 turnstile. 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. On the Transport for London (TfL) system - which has been significantly enhanced so as to include Gatwick Airport routes etc. - the aggregate daily fare can already exceed £55. Other transit operators outside London are keen to extend the use of contactless for transit to cover a very broad range of journeys and imposing a limit will seriously impede these innovative developments. The exemptions do not appear to fully reflect the EBA’s desire to balance security and ease of use. There is no recognition that any party may choose not to implement SCA (and accept liability) in order to provide the friction free transaction experience that consumers demand.
• If contactless proximity payments are to be included then the RTS must recognise the additional risk management controls available in cards. Although transaction counters cannot be used to trigger CVM, they trigger online authorisation, which supports risk management.
• 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 conditions and needs (see comments in section 1.1.2). According to figures issued by the UK Cards Association, as of June 2016 – - there were a total of 92.1 m contactless cards in issue in the UK, an increase of 33.5% over the year. Meanwhile, spending on contactless cards in the first half of 2016 has already outstripped contactless spending for the whole of 2015. The average contactless transaction was £8.60 in both May and June of this year. The current transaction limit in the UK is £30 (which is akin to the EUR 50 limit envisaged in RTS Article 8(1)(b) point ii. However, the limit has been progressively increased from £10 (2007), then to £15 (2010), £20 (2012) and, most recently, to £30 (2015). These changes have been carefully considered in relation to fraud losses that are considerably lower than for card payments generally. There is no doubt that the card industry and wider stakeholder community will want to consider further increases to the limit in future yet the RTS would leave no room for national communities to make such amendments to reflect their own market experiences and conditions.
• 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 scheme level and periodically revised”. Alternatively, the EBA will need to review the limits regularly.

4.6 RTS Art 8(2) points (a) and (b) – clarifications and amendments to the wording in connection with credit transfers
• RTS Article 8(2)(a) uses the term “online” credit transfers. We assume this means credit transfers initiated via the internet. In addition, for the sake of language consistency we suggest that “list of trusted beneficiaries” is altered to “list of trusted payees”.
• We interpret RTS Article 8(2)(b) as referring to recurring credit transfers and standing orders.

4.7 RTS Art 8(2)(c) – should be widened
• We think the exemption in RTS Article 8(2)(c) should not be restricted to in-house online credit transfers only where the payer and payee are the same. It should also include online credit transfers where the payer and payee hold their payment accounts with the same AS PSP, provided that it is up to the AS PSP whether they apply this or not, rather than mandated.

4.8 RTS Art 8(2)(d) – treatment of remote electronic transactions
• A one-size-fits-all procedure is not practical and will hamper innovation and damage the customer journey. Such an approach seems to go against 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.
• Please also see our earlier comments in section 1.1.11 about allowing merchants, who in turn have accepted liability for not using SCA, to apply their own equivalent, risk-based assessments as part of their processes.
• As mentioned in 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 conditions and needs.
• Further clarity is sought regarding calculation and application of the cumulative amount and whether it refers to all remote electronic payment transactions or to a single payee?

4.9 The exemptions need to take into account services designed to promote financial inclusion and equality
• The prescriptive nature of the draft RTS in the context of usage of cards as well as online and mobile banking, threatens the ability of PSPs to comply simultaneously with requirements set around financial inclusion and equality.
• In the UK, Chip and signature cards (also known as ‘PIN suppressed’ cards), are available as both debit and credit cards to people who are unable to use a PIN. Typically, this may be because they have difficulty using the PIN pad due to dexterity issues or a visual impairment; difficulty remembering their PIN; or difficulty with mobility, making it hard to reach a PIN pad. They look identical to chip and PIN cards and can be used in all of the same places – in shops or online. Unlike a chip and PIN card, the customer is asked to use their signature to authorise the payment, rather than enter their PIN. Chip and signature cards can be provided to anyone unable to use a chip and PIN card, but still able to write their signature.
• One of our members has highlighted the example of a prepaid product they currently provide, which is used mostly by businesses to pay certain employees, and it gives those workers instant access to their funds. This is a corporate product where the PSP has no direct relationship with the end cardholder, making strong customer authentication impossible. Yet the product financially includes the employees in e-commerce and other services which they might not be able to access if the employer used a different method of payment. We consider this has a genuine social benefit. The ability to continue to offer such a product is jeopardised by the fact that the list of exemptions does not accommodate risk profiling.

4.10 The exemptions need to take into account services designed for corporates
• We have set out as part of our response to question 1 (see point 1.1.3) a number of business/corporate scenarios, which the RTS and CP do not appear to have addressed. We have also highlighted a number of situations which we believe should be exempt from application of the SCA requirements.
• 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 is to make use of security “step up” where risk triggers are hit (which could include cases of major security incidents or a new attack vector emerging). 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).
• If mobile contactless payments are deemed in scope there would also be concerns, since it would not make sense (or potentially even be possible) to prevent the use of authentication for transactions below €50 (Touch id/ device passcode).
• Mandating the exemption also opens the door for fraudsters. As we have mentioned before, low value remote transactions do not always equate to low risk.
• We wonder to what extent the EBA has taken into account personalised security credential issuance and life cycle management requirements defined at an international level.
• We highlight some points on customer guidance and messaging for the EBA to consider as part of its other work on PSD2.
• We have some questions about the interpretation and application of RTS Articles 9, 12 and 13.
• We suggest linking the review of the security measures in RTS Article 16 with the work the EBA is doing on Guidelines on the management of operational and security risks.

6.1 To what extent has the EBA taken into account issuance and life cycle management requirements defined at an international level?
• How banks 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 (

6.2 Customer guidance and messaging
• We note that, in rationale points 56-58, the EBA proposes that requirements about PSU awareness programmes, which were suggested in several discussion paper responses (including our own), would best be addressed by (i) the EBA under its mandate under PSD2 Article 95 (Guidelines on the management of operational and security risks); and (ii) via the European Commission’s leaflet to be developed in accordance with PSD2 Article 106.
• It will be important to develop simple messages and guidance to customers on using new payment services. We believe that early clarity on simple mechanisms for managing customer consent and ensuring the security of data sessions between AS PSP and TPP (i.e. identification and authentication of TPP) will be vital to earning customer trust in innovative services enabled by PSD2. We are concerned that the RTS is very strong on advice for SCA, which is arguably a tried and tested link in the security of the customer journey, and much less stringent in guidance on new and consequently weaker elements in the customer journey – validity of consent mandates for example is barely considered.

6.3 Interpretation and application of Article 9
• In relation to RTS Article 9(1), how are PSPs to meet the requirement that the data on personalised security credentials are “masked when displayed and not readable in their full extent” and PSCs “are not stored in plain text” during the process of providing the PSC to the PSU for the first time i.e. when the PSC are posted to the home address?
• RTS Article 9(1)(c) currently states that “Secret cryptographic material related to the encryption of the credentials is stored in secure and tamper resistant devices and environments”. By requiring tamper resistance rather than tamper evidence it is very difficult (if not impossible) to allow the storage of cryptographic materials in the cloud. The standard for cryptographic modules is FIPS140-2, which defines four levels of security; level two provides controls for tamper evidence, whilst level three provides controls for tamper resistance. The tamper resistant controls are physical security controls that cannot be replicated within software cryptographic modules. By requiring tamper resistance the RTS will hamper innovative solutions that AS PSPs and PISPs/AISPs may wish to introduce.
• We would like it clarified in relation to RTS Articles 9(1)(b) that personalised security credentials as well as cryptographic material can be stored in plain text if it is either stored in a tamper resistant device or in a device which is under the control of the PSU if this device is tamper evident.
• Similar clarification in relation to RTS 9(1)(c) that secret cryptographic material can be stored in a device which is under the control of the PSU if this device is tamper evident would also be welcomed.

6.4 Interpretation and application of Article 12
• What does application of RTS Article 12 mean in the context of PIS and AIS if the PISP or AISP uses screen-scraping? In that circumstance the AS PSP will have no control over the environment the PISP or AISP uses. We understand that PISPs and AISPs are under a wider obligation to comply with PSD2 and the RTS. In terms of the PSD2 liability model there is a burden of proof on the PISP “to prove that, within its sphere of competence, the payment was accurately recorded and not affected by a technical breakdown or other deficiency…” The RTS may point to a need for the PISP/AISP to be able to prove to the AS PSP, if challenged, the adequacy of its procedures and processes linked to association of the PSU’s identity with the PSC etc.
• We are unclear as to how Article 12(b) could operate. In relation to the practicality and timely execution of the one-time migration effort of the existing password based users onto strong authentication an exception should be considered. This exception should allow 1-factor password users to remotely register and activate strong authentication (e.g. a mobile app) using their existing (1-factor) credentials when setting up 2-factor authentication for the first time. Since the upgrade to strong authentication is a one off limited action the risk involved is contained.

6.5 Article 13(d) – clarification sought
• Clarification is sought regarding reference to “secure and trusted environment” in RTS Article 13(d). The activation of a mobile app or hardware device would occur in client premises and thus would be out of a PSP’s control. Article 13a, b, c should already ensure that only authorised individuals can perform the registration action.
• RTS Article 13(d) and also RTS Article 14 seem to say that activation/renewal/resetting must be in line with RTS Article 12(d), which requires SCA to be used yet there must be any number of scenarios where this would be impossible.

6.6 Article 16 – suggest linking the review of the security measures to the EBA Guidelines on management of operational and security risks
• Should this requirement (and that in RTS Article 7) be explicitly cross-referenced to, and addressed in, the Guidelines relating to the management of operational and security risk the EBA is required to deliver in accordance with PSD2 Article 95?
• Can the EBA clarify who is considered to be a certified auditor as referenced in Article 16(1)?
• While we wonder to what extent the requirements have been considered and assessed in relation to the existing requirements set by PCI-DSS, we support the pragmatic approach the EBA proposes in Article 19 such that each AS PSP is only obliged to offer one communication interface although it could offer more than one if it wished to do so.
• We have a number of questions relating to points of detail in Chapter 4 (Articles 19-22).
• Please note that any comments and concerns regarding RTS Article 20 are set out in our response to question 9.
• We conclude by outlining some of the areas which we think are missing from Chapter 4 and have not been addressed in the CP, namely consent management, GDPR considerations and dispute handling as part of the secure communication between the relevant parties.

7.1 The EBA’s approach
• 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”. RTS Recital 13 refers to the dedicated interface offering “the same service level as the online banking platform” of the AS PSP.
• To what extent have the requirements set out in Chapter 4 been considered and assessed in relation to the existing requirements set by PCI? 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.
• We also note that on page 49 paragraph two the EBA has determined “to give sufficiently concrete guidance for the communication between stakeholders involved in the payment service market” (option 4.1.2). We have long held concerns as to how thousands of AS PSPs would be able to interact with potentially hundreds of TPPs on a pan-European basis. To that end we very much support the pragmatic approach the EBA proposes in Article 19 such that each AS PSP is only obliged to offer one communication interface although it could offer more than one if it wished to do so. The EBA proposals provide a useful framework to promote pan-European alignment and collaboration where appropriate. We see the benefits of having common standards to support interoperability, efficiency, resilience, dependability and predictability as well as acting as an enabler for competition and innovation. This is very much in line with work already underway in the UK to develop an open banking standard as mentioned in our comments in section 1.1.1 while we also continue to engage closely in related European discussions on these topics.
• We agree that availability and access via the communication interface should be on a par with that available to the PSU when accessing its account directly. However, we note that there is no mention of permissions-based access, enabling the PSU itself to control the level of access it allows when using the services of a PISP or AISP.

7.2 RTS Art 17(1) – requirements for identification and language used
• RTS Article 17(1) refers to PSPs ensuring “secure bilateral identification when communicating between the payer’s device and the payee’s device…” It is not entirely clear if this requirement should be read to apply also when a TPP is involved or how it would work.
• It is particularly important to ensure that such bilateral identification not only unequivocally enables each PSP to be able to identify the other but also to be able to check each other’s authorisation status and what services the PSP is authorised or licensed to provide.
• Additionally it needs to be clarified what it means in the context of EMV, which today does not require mutual identification between cards and terminals. Similarly, while bilateral identification is workable when the payer’s device is “intelligent”, if it is, for example, a PC, it is not clear how the PSP would be able to identify without some sort of certificate on the user’s device and it is also impractical to hold this data given that each customer could use multiple devices. We therefore do not support RTS Article 17(1) at a customer level and do not believe that it is required since we have SCA. We accept that this requirement would be useful for TPP access.
• We question whether it is appropriate for Article 17(1) to refer solely to payer and payee and electronic payments when payment services and application of the RTS also apply to e.g. account information services and confirmation of availability of funds, not just payment initiation.

7.3 RTS Art 18 – Language used and overly prescriptive requirement in RTS Art 18(c)
• RTS Article 18 refers to merchants in the first sentence but alters this to “other entities including, but not limited to, merchants” in the second sentence. The first reference should match the second since the scope of payment services is not limited to interactions with merchants. For example, PIS could be offered alongside AIS.
• RTS Article 18(c) requires timestamps “using the standard NTP protocol”, which does not appear to be in line with the aim of being technologically neutral. There are alternatives to the Network Time Protocol, principally the Precision Time Protocol (PTP). The key aspect of this requirement should be the synchronisation of timestamps rather than the protocol used to achieve this.

7.4 Interpretation of Article 19(1)
• As mentioned above, we interpret the term “at least one communication interface” used in RTS Article 19(1) as meaning that while the AS PSP is obliged to provide one such communication interface it could, if it wished provided more than one.
• We take the view that adoption of an API solution would be compliant with this approach.
• Should RTS Article 19 be interpreted to mean that the only way a PISP, AISP or card-based payment instrument issuer should communicate with the AS PSP is via the AS PSP’s communication interface? Or is screen-scraping still permitted provided that the PISP/AISP finds a way to meet all of the other RTS requirements, including a means to identify itself to the AS PSP? Similarly, Rationale point 65 mentioned that AISPs and PISPs “want to remain free to access the payment account in the event that the dedicated interface is not working properly”. Would that be permitted provided that they identify themselves to the AS PSP?
• The term “accessible online” is used in RTS Article 19(1) and in PSD2 but is not explicitly defined and thus is open to interpretation. RTS Recital 9 refers to AS PSPS “that allow for the provision of online payment services”. However, that does not mean that the PSU has taken up the option of being able to access its payment account online. An exchange of views regarding the interpretation of “accessible online” took place at the FCA PSD2 Stakeholder Liaison Group meeting on 12 July 2016 – for further information please see To date we have understood the term to mean accessible through all common types of online devices, e.g. computer, mobile phone, tablet. We assume that payment accounts accessible via telephone banking or other methods would be out of scope. One member has previously suggested that a payment account should be deemed accessible online if the customer has an ‘online account agreement’ with its PSP. If a PSU has not set up online banking (and therefore does not itself have online access) then the account would not be deemed to be accessible online. It would be helpful to have clarification on these points.

7.5 RTS Article 19(4)
• RTS Article 19(4) states that protocols need to be documented. But there are no standards provided to say what such protocols must look like.
• One member has raised a concern about the risk of making the technical specification publicly available and suggests that a generic description could be published on the website but that the more detailed technical specification should be available by request only so that distribution is more limited and the requestor’s ID could be logged.

7.6 RTS Art 19(5) – the three month timeframe
• According to RTS Article 19(5) “Except for legitimate emergency situations AS PSPs shall make sure that any change to the technical specification of their communication interface is made publicly available in advance as soon as possible and, except in emergency situations, not less than 3 months before the change is implemented. PSPs shall document legitimate emergency situations where changes were implemented and make them available to competent authorities on request”. We think that the 3 months period is too long especially in an agile environment but appreciate that TPPs will need time to make any necessary adjustments to their own systems and processes.

7.7 RTS Art 19(6) – what specific statistics are AS PSPs expected to keep?
• RTS Article 19(6) requires AS PSPs to “monitor the availability” of the communication interface and “make such statistics available on demand to the competent authorities”. What precisely are the parameters for such measurements and frequency of recording?

7.8 RTS Art 20 – for comments and concerns please see our response to question 9

7.9 RTS Art 21(4)(c) and RTS Art 22(1)(c)
• Our understanding is that just because the AS PSP may have provided a ‘yes’ confirmation, it is under no obligation to allow any subsequent settlement transaction to be debited (e.g. if sufficient funds are no longer available at the time the settlement request is received. Nevertheless the response given should reflect the state of the PSU’s account at the time the request for confirmation is received.
• We believe that a clear distinction needs to be made between the confirmation process and the handling of any subsequent settlement transaction. Our current understanding is that settlement i.e. the debiting of the PSU’s account with its AS PSP may involve either a credit transfer (initiated by the PSU) or a direct debit (originated by the card-based payment instrument issuer). This part of the process will be subject to the normal PSD2 provisions governing payment transactions between PSPs, including authorisation, authentication and liability and falls enirely outside the scope of the RTS.

7.10 RTS Art 21(3) – what happens in event of dispute about the security of the communication session
• All entities (whether the AS PSP, AISP, PISP and card-based payment instrument issuer) should assure safe communication. What happens if there are different views amongst the parties as to whether the communication session is safe?

7.11 RTS Art 21(5) – clarification required
• According to RTS Article 21(5): “In case of loss of confidentiality of personalised security credentials under their sphere of competence, AISPs and PISPs have to inform the payment services user associated with and the issuer of the personalised security credentials without undue delay”. Clarification is requested as to what ‘without undue delay’ means and about the methods by which AISPs and PISPs must inform the PSU and AS PSP.

7.12 RTS Art 22(1) – definition of sensitive payment data and scope of the term “designated payment accounts”
• The lack of a further clarification regarding the definition of sensitive payment data it means that it is likely that there will be fragmentation and a lack of harmonisation concerning the information to be made available to AISPs. Please see our additional comments in relation to RTS Article 8(1)(a) in this connection.
• We believe there may be different interpretations at Member State level as to what constitutes a “payment account”. In the UK the scope is set out in the FCA’s Perimeter Guidance Manual ( Chapter 15.3 question 16, which takes the view that payment accounts" can include, for example, current accounts, e-money accounts, flexible savings accounts, credit card accounts and current account mortgages. However, other Member States would not necessarily see credit card accounts, for example, as being in scope.

7.13 RTS Art 22(2) - question
• RTS Article 22(2) refers to the AS PSP sending a notification message to the TPP “which explains the reason for the unexpected event or error”. Does there need to be standardisation (to some extent) of reason codes?

7.14 RTS Art 22(5) - questions
• What is the definition of ‘actively requesting’ and how will the AS PSP know if the PSU is actively requesting information or not? What is the definition of ‘a day’ in this context? Is it within the last 24 hours of the previous request or within a day measured from midnight to midnight in the AS PSP’s time zone?

7.15 What is missing from Chapter 4?

Consent management and GDPR considerations
• We believe that a common consent management model that also links with the EBA and Member State registries of authorised PSPs will be key to smooth and secure operation of services for PSUs.
• When a PISP/AISP or other third party makes a request to the AS PSP (e.g. bank) interface (e.g. API) to make a payment or request information, the AS PSP needs to be able to confirm that there is evidence that all of the previous authentication and authorisation steps are complete.
• There are numerous technical approaches to providing this evidence, and each AS PSP could implement a different solution. A diverse range of implementations will have a detrimental impact on innovation and customer experience. Customers would have different experiences across the market, and the PISPs/AISPs would have to accommodate all of these different methods. Existing PISPs/AISPs may be okay as they may have already invested in various distinct ‘plug-ins’ for multiple bank websites screen scraping. The detriment will be for new entrants who may be unable to invest in a diverse technical environment.
• We would suggest that the RTS need to be more specific in this particular area around how PISPs or AISPs provide evidence of authentication and authorisation.
• In connection with RTS Articles 22(3), 22(4) and 22(5), and also PSD2 Articles 65, 66 and 67, we see checking the validity of the PSU’s consent as a necessary step alongside identifying and authenticating a TPP. Solutions such as OAuth 2.0, for example, can support the management of consent with third parties and associated permissions.
• We have heard suggestions that a payment service user entering their security credentials via a TPP would be enough to capture their consent to sharing data with that TPP. We do not agree that this would be sufficient to meet data protection obligations, particularly post-implementation of the General Data Protection Regulation (GDPR). The GDPR, which comes into effect in May 2018, stipulates: “'consent' of the data subject means any freely given, specific, informed and unambiguous indication of the data subject's wishes by which he or she, by a statement or by a clear affirmative action, signifies agreement to the processing of personal data relating to him or her”. PSD2 goes further, requiring the higher standard of ‘explicit consent’ under Article 94(2).
• Where an AISP is accessing customer data via screen scraping, i.e. by “impersonation” rather than by “delegation” of authority, it is likely to be unclear to the AS PSP whether specific/explicit consent has been given. In these scenarios would the AS PSP be justified in denying access/not completing instructions from a TPP?
• Furthermore, to meet audit trail requirements of GDPR/ Data Protection Act, we believe that the audit trail for consent would need to be managed by the AS PSP rather that the AISP.
• As a result we propose that there is a need for parameterised consent:
- Specifying accounts to be shared/ from which transactions can be initiated
- Scope of account information to share
- Period of time for which consent is valid.
• A PSU’s consent could then be managed by the AS PSP in a similar way to the existing model for direct debit mandates, allowing customers to review, activate or revoke consent mandates via their online banking. We believe this would be the simplest way to fulfil data protection requirements and give customers a sense of control and security.
• We also believe guidance should be given relating to the time period after consent has been revoked that PSU data should be/can be held by TPP. Data needs to be held in order to enable historic payment investigations, but the TPP must also comply with GDPR requirements which give individuals the “right to be forgotten” and have “old” data erased. It would be useful if there was some specific guidance to the norm for data retention amongst payment service providers to give consistency of PSU experience – and assist with customer messaging on treatment of their data in this new model.

Dispute handling
• In practice there will be a requirement to securely message between AS PSP and TPP in order to carry out payment investigations to resolve disputes and the identification/authentication methods for this kind of ad hoc communication and data exchange is not sufficiently addressed in the RTS."
• We are supportive of the use of the ISO 20022 data dictionary to facilitate interoperability of technical solutions to support AIS, PIS or for the confirmation on the availability of funds. Interoperability of solutions is vital to ensure ubiquity and consistency across service provision. At its core ISO 20022 uses a data dictionary with terms and definitions for financial services represented in a standardised way, independent of syntax. Its business modelling approach allows users and developers to represent financial business processes and underlying transactions in a formal but syntax-independent notation.
• The common, open, well-defined and well-used set of data terms developed in ISO 20022 can support PSD2 implementation and ensure a level of interoperability that is necessary. As stated, the pillar of the ISO 20022 methodology is the central dictionary of common business concepts and the modelling methodology used to assemble them in syntax-neutral way. Thanks to this central dictionary, all the ISO 20022 message models share a common understanding and representation of business concepts which helps the business information to flow smoothly from one message to the other along the transaction life cycles, even if the syntax used to identify and format these concepts in the ‘physical’ messages is different.
• Adopting and leveraging existing standards, taxonomies and data lists wherever possible and practicable is to avoid duplicative efforts and maximise interoperability, is of paramount importance. It should not be underestimated the complexity and commitment that would be necessary to define a common set of standardised data to support PSD2 from scratch, particularly when used cross-border. Therefore, the principle of reuse is vital and ISO 20022 can facilitate in this regard.
• The financial services industry has heavily invested in ISO 20022, and crucially for the PSD2 context, this investment has been made at a European level due to the SEPA Regulation. Standardised data will enable greater straight-through processing while building an agile infrastructure that can quickly meet new business requirements. It will also reduce time to market for PSD2 compliant solutions as the data dictionary is already well developed and well used.
• Whilst the ISO 20022 data dictionary is well developed in the payment initiation space, further work may need to be undertaken to support AIS, particularly if there is a need to identify banking products.
• ISO 20022 has an open and accessible governance process that allows all interested parties to partake in message development, thereby facilitating adoption, distribution and participation.
• Further consideration would need to be given to the use of ISO 20022 by the cards industry as traditionally they have relied upon separate and differing global industry standards.
• To facilitate innovation and flexibility the agreed ISO model should be able to be represented in various forms as necessary to support different API implementations (e.g. SOAP and JSON).
• There are important distinctions to be made between identification and authentication and authorisation status of PSPs, all of which are necessary to support compliance and service delivery under PSD2 and the RTS.
• We have articulated some of the pros and cons to the proposed use of website certificates issued by a qualified trust service provider under an e-IDAS policy.
• We also set out the underlying link to, and reliance upon, the functionality and capabilities of the Member State Registers.
• We have additionally, set out some thoughts about a potential role that the Legal Entity Identifier could perform.

9.1 Comments concerning identification, authentication and authorisation status
• The term “identification” is ambiguous and needs further clarification. There is a distinction between electronic identity and electronic authentication as described in the e-IDAS Regulation itself:
o eIDAS Article 3(1): ‘electronic identification’ means the process of using person identification data in electronic form uniquely representing either a natural or legal person, or a natural person representing a legal person;
o eIDAS Article 3(5): ‘authentication’ means an electronic process that enables the electronic identification of a natural or legal person, or the origin and integrity of data in electronic form to be confirmed.
• Identification and authentication are two distinct processes and solutions suitable for one are not necessarily interchangeable. Some of the wording in eIDAS (e.g. the definition of electronic identification) differs from established definitions within industry. The use of eIDAS would need to be future-proof and we have concerns about whether this is indeed the case.
• As noted in the EBA’s rationale point 74, Article 20 is entirely dependent upon “whether any certification authority will apply to supervisory body for status as qualified trust service provider under eIDAS by RTS implementation deadline”. How can the RTS mandate use of something which does not exist, especially given that, as far we understood earlier this year, only four Member States have so far signed up to e-IDAS, which is aimed at public services and government?
• How are PSPs expected to comply with the RTS if no such providers emerge in time or, indeed, emerge at all? Without clarity on how this will work in the short term, the timeline to achieve compliance with the RTS will become increasingly difficult to achieve.
• Given that PSD2 mandates (in PSD2 Article 15) the EBA to maintain a central registry for authorised TPPs which is supported by Member State competent authorities, there is no mention within the RTS of this and how it will be maintained by EBA.
• We have concerns about the extent to which the Member State Registers referred to in RTS Article 20(2) are harmonised and allow for the high degree of automated access that is needed to support these requirements. There needs to be a way to identify unequivocally the parties involved (i.e. am I who I say I am?), their authorisation status, where they are authorised and what payment services are they authorised to provide. If Member States and the authorities are committed to encouraging the future payment environment envisaged in PSD2 then they need to provide the tools for which they themselves are responsible (such as the data and functionality of the Member State registers) in a manner which supports PSPs in delivering this vision.
• Qualified certificates show that the Certification Authority has confirmed the identity of the recipient of the certificate but do not provide any controls over how the private key will be secured going forward. This approach is typically used for authentication purposes for server to server communications but we are unclear how it would be used for certificates installed on the payer’s personal device.
• In the context of identification, under Article 20(2) of the draft RTS, there is a requirement for the authorisation number of a PSP to be that under Annex IV (c) of the eIDAS Regulation. “For the purpose of this Regulation, the registration number as stated in the official records according to in Annex IV (C) of Regulation (EU) No 910/2014 shall be the authorisation number of the AS PSP or the PSP issuing card-based payment instruments, and the AISP and PISP available in the public register of the home Member State defined in Article 14 of Directive (EU) 2015/2366”. What effort is being made to harmonise authorisation numbers issued to PSPs by Member States and prevent duplication?

9.2 Potential role of the Legal Entity Identifier (LEI)
• Harmonised identification will be crucial to the success of PSD2. Whilst we agree with the EBA that an identifier will be required, to ensure all parties (PISPs, AISPs and AS PSPs) can be identified, the risk of this not being standardised could pose a number of issues. A level of harmonisation is desirable to ensure a lack of ambiguity and also for persistence. We feel that the reuse of internationally recognised identifiers such as LEI could be beneficial to the ease of use and growth of the ecosystem. The use of LEI in the context of PSD2 is that of a reliable and verifiable identification of a legal entity, this would of course form part of a broader solution on secure communication, authentication and authorisation.
• The LEI will help provide a reliable means for two parties to identify each other through a trusted means, with LEI already used in many contexts across the EU and the globe, including under EMIR, CRR, AIFMD and others. This means that many PSPs that will be providing payment services under PSD2 will already have an LEI. It is worth noting that in the context of other EBA mandates, for example Professional Indemnity Insurance and Passporting that LEI may also be useful. The use in these contexts would provide a standardised way to identify parties in the ecosystem. It is worth noting that possible requirements for development and enhancement could be presented to the Global LEI Foundation for consideration.
• This view also corresponds with the Committee on Payments and Market Infrastructures (CPMI) working group on Correspondent Banking Technical Report, published in July 2016 which established a new framework for how the payments industry should assess the use of the LEI in payment messages. It acknowledged the benefit of “inclusion of the LEI in payment messages…to ensure unambiguous identification of parties to payment transactions”.
• The concern that very large, disproportionate volumes could impact the availability and resilience of AS PSPs’ core systems is a legitimate one but we are not convinced that setting an access limit of twice a day is the appropriate response for a number of reasons:
• We do not see the benefit in having specific counts for all PSU/AISP entries as this would not really protect against Denial of Service risks, would introduce significant tracking requirements and would be complex to manage.
• It is unclear how the AS PSP would know if the PSU was actively requesting the information or not and thus whether a ‘robot’ enquiry was being made. There is a need to be able to differentiate calls driven by actual PSU activity (e.g. a PSU accessing their banking app) and calls that are driven by the service providers operating the service in the background.
• The proposed limit of twice a day would potentially limit AISPs’ propositions and go against the European (and the UK) authorities’ desire to encourage competition and innovation through opening up the market to new players and offer customers more choice. Having information every 12 hours (for example) would mean that AISPs would not be able to provide first response solutions and real time notifications and warnings to customers. It is likely that AISPs would continue to use screen scraping techniques rather than use the communication interface provided by the AS PSP in accordance with RTS Article 19.
• The volume of information exchanged can affect system efficiency and availability, not just the number of information requests.

• Other options and approaches, which could be considered by the EBA:
• Standards could be developed to set out service level expectations covering availability and performance that AISPs can expect from AS PSPs, balanced with standards that enable AS PSPs to manage rates and throttle if their core systems are being overwhelmed. In the UK the Open Banking Implementation Entity will look to create standards in these areas which could be used more widely for PSD2 across the EU.
• Alternatively the EBA could simply clarify that AS PSPs are able to throttle if they are faced with disproportionate consumption.
• Otherwise, having some kind of limit could help to manage the resilience risk.
• A requirement for rate limiting on AISP requests rather than specify a specific number per day. Rate limiting is used in computer networks to control the rate of traffic sent or received by a network interface controller to avoid overload. It would ensure that access requests not directly linked to the PSU’s request is relative to the size of the AISP and the AS PSP can flexibly manage volumes. The rate limitation would need to be set by the AS PSP.
• A push mechanism where AS PSPs push data when there is movement on the account.
[Other "]"
Payments UK is a trade association launched in June 2015 (taking over from the Payments Council) to support the rapidly evolving payments industry. Payments UK brings its members and wider stakeholders together to make the UK’s payment services better for customers and to ensure UK payment services remain world-class.

Financial Fraud Action UK (FFA UK) is responsible for leading the collective fight against fraud in the UK payments industry. Its membership includes the major banks, credit, debit and charge card issuers, and card payment acquirers. Through industry collaboration FFA UK seeks to be the authoritative leader in defending consumers and businesses from financial fraud, by creating the most hostile environment in the world for fraudsters.
The UK Cards Association is the trade body for the card payments industry in the UK, representing financial institutions which act as card issuers and acquirers. Members of the Association account for the vast majority of debit and credit cards issued in the UK - issuing in excess of 56 million credit cards and 95 million debit cards - and cover the whole of the payment card acquiring market.
Payments UK’s main roles are:
• To be the payments industry’s representative body: providing an authoritative voice in the UK, Europe and globally, and working with stakeholders to share payments knowledge and expertise.
• To be a centre for excellence: supporting the UK payments industry to provide world-class payments, building on the experience, thought-leadership and project delivery expertise behind award-winning initiatives such as Paym, the Current Account Switch Service and Faster Payments.
• To deliver collaborative change and innovation: working on behalf of our members to benefit customers and UK plc, ensuring their needs are understood and met, both now and in the future.

FFA UK’s primary role is to drive collaborative action to reduce the impact of financial fraud and scams both across the industry, and with partners in the public sector, private sector, and law enforcement. It operates its own data and intelligence sharing bureau and sponsors a fully operational police unit.

The UK Cards Association promotes co-operation between industry participants in order to progress non-competitive matters of mutual interest; informs and engages with stakeholders to shape legal and regulatory developments; develops industry best practice; safeguards the integrity of the card payments industry by tackling card fraud; develops industry standards; and co-ordinates other industry-wide initiatives such as those aiming to deliver innovation. As an Association we are committed to delivering a card payments industry that is constantly focused on improved outcomes for the customer.
Joint response from Payments UK, Financial Fraud Action UK and The UK Cards Association