To: Banking and Credit Team

HM Treasury 15 March 2017

From:

Payments UK, BBA and The UK Cards Association

RESPONSE TO HMT CONSULTATION ON THE IMPLEMENTATION OF THE REVISED EU PAYMENT SERVICES DIRECTIVE II (PSD2)

Payments UK 2 Thomas More Square London E1W 1YN

A Company incorporated in England No 6124842. Registered Office as above

INTRODUCTION We welcome the opportunity to comment on HM Treasury’s consultation on implementation of the revised EU Payment Services Directive II (PSD2). Payments UK: Payments UK is the trade association launched in June 2015 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. We currently have 48 full members, who are all payment service providers such as banks, building societies, payment institutions and e-money businesses. We also have 37 associate members with an interest in payments, including payment solutions and payment infrastructure providers and consultancies. www.paymentsuk.org.uk Payments UK’s main roles:

• 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; and

• 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.

The UK Cards Association: 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. The 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

Page 2 MEMBER CIRCULATION

committed to delivering a card payments industry that is constantly focused on improved outcomes for the customer. www.theukcardsassociation.org.uk BBA: The BBA is the leading trade association for the UK banking sector with 200 member banks headquartered in over 50 countries with operations in 180 jurisdictions worldwide. Eighty per cent of global systemically important banks are members of the BBA. As the representative of the world’s largest international banking cluster the BBA is the voice of UK banking. We have the largest and most comprehensive policy resources for banks in the UK and represent our members domestically, in Europe and on the global stage. Our network also includes over 80 of the world’s leading financial and professional services organisations. Our members manage more than £7 trillion in UK banking assets, employ nearly half a million individuals nationally, contribute over £60 billion to the UK economy each year and lend over £150 billion to UK businesses. www.bba.org.uk

SUMMARY OF OUR RESPONSE UK proposed approach to implementation • We are generally supportive of the government’s proposed approach to ‘copy-out’ the

legislative text in line with the maximum harmonisation nature of PSD2. We have highlighted some comments and concerns, especially where the draft legislation or the proposals include elements of gold-plating. We have also identified a number of apparent transposition errors.

• We support the continued application of the derogations that were exercised during the implementation of the current PSD (e.g. in relation to the SPI exemption, the thresholds set for low-value payment instruments and the treatment of micro-enterprises).

Access to payment systems and payment account services • In relation to the proposed approach to access to payment systems and access to

payment account services, we think it would be helpful if further clarification was provided regarding: (i) the interaction of the regulations with provisions in the Financial Services (Banking Reform) Act 2013 (FSBRA); and (ii) how the FCA and the Payment Systems Regulator will work together, particularly on areas such as dispute resolution.

• We think the industry’s efforts to develop the Access to Payment Systems website and development of the voluntary Code of Conduct for Indirect Access Providers already goes a considerable way towards meeting the government’s expectations with regard to access to payment systems.

• Concerning access to payment account services, we are broadly supportive of the approach that HMT has proposed. Point 3.17 of the consultation document helpfully reiterates the fact that the Article 36 provision “does not impose an absolute obligation for credit institutions to grant access”.

• We have set out in our response to question 8 our understanding of what constitutes an “enquiry”.

Page 3 MEMBER CIRCULATION

Transparency and information requirements • We do not agree that the government should extend the right of termination to overdrawn

current accounts. We see this as gold-plating, which would not be in the best interests of customers (who may not realise the negative consequences on their credit rating and future borrowing ability and who may wrongly think that they are ‘free’ from the overdraft debt) or banks (who will face potential challenges in recovering the debt).

• We do not think that HMT should exercise the ‘monthly statements’ derogation since this would remove what degree of flexibility currently exists to accommodate customers’ (consumers, businesses and corporates) own preferences to determine how and when they receive information from their PSP. This view would appear to be in line with point 75 in the consultation impact assessment published on 9 March which states: “the Government believes that this is an area which should be left to competition between providers rather than be subject to impose[d] further legal requirements”.

Conduct of business rules • We agree with government’s proposal to provide access to out-of-court procedures (in the

form of FOS) only where the complainant would usually be eligible to refer a complaint to the FOS, which we take to mean consumers, micro-enterprises and small charities. However, we found some of the statements in the consultation document, and the drafting of the regulations, somewhat confusing.

• In relation to question 15 concerning the surcharging derogation, this is a topic where we have taken a neutral position throughout the legislative process. The UK is a relatively mature card market accounting for over 30% of all card payments made in the EU. There is no single view as to whether exercising this derogation would be pro-competitive in the UK card market as it is likely to impact firms in different ways.

Account information services and payment initiation services • While statements in the consultation document provide a useful indication of government’s

preference for significant alignment of the CMA’s Open Banking API Standard and PSD2, it is important to be clear about the differences in terms of the type of accounts, the data, the mandated entities and payment service users in scope and the associated implementation deadlines which apply. There is a danger of scope creep.

• It should not be forgotten that the PSD2 provisions are not restricted to a domestic market but apply on a European basis beyond the scope of both the CMA remedy and the UK government’s open banking vision.

• We strongly believe that some form of real-time capability will be required to verify a PII’s, PISP’s or AISP’s authorisation/registration status with the FCA (and other member states’ competent authorities) both from customer protection and from a liability model perspective.

• Clarity is required from the UK authorities as to the interaction between PSD2 and the GDPR in terms of data exchange and the ‘consent’ model.

• We support the view documented in point 6.18 of the consultation that “best practice is expected to involve customers authenticating themselves directly with their ASPSP, i.e.

Page 4 MEMBER CIRCULATION

providing their login details only to their ASPSP, rather than the AISP or PISP, with confirmation then provided by the ASPSP back to the AISP or PISP”.

• The consultation (in point 6.22) helpfully sets out the government’s interpretation of the term “accessible online”, which appears to be in line with our own.

• We have always assumed that the FCA’s current interpretation of “payment account” as it applies under PSD1 - and as described in the FCA Perimeter Guidance (Chapter 15.3) - would continue to apply to PSD2. The description in point 6.23 in the consultation reflects the same view.

• We accept that credit cards are deemed to be payment accounts under the PSRs2 as they are under the current PSRs. We understand that this is not an interpretation that most other member states apply today. In general, we have assumed that third party access will be restricted to AIS only in most cases and the only payment mechanism available to a PISP would be a balance transfer and/or money transfer where this is an online service directly available to the PSU to instruct these payments. However, it is important to note that balance transfer and money transfer requests typically attract a fee imposed by the ASPSP.

• We assume that the information to be shared in relation to AIS would be minus any sensitive payment data, although we note the possible transposition error in draft regulation 70(3)(3). However, there remains a lack of clarity as to what falls into the scope of the definition of “sensitive payment data1” and, conversely, what is “non-sensitive payment data”.

• HMT has usefully underlined the fact that the extent of data an individual ASPSP may enable its customers to access online is a competitive issue, which will therefore vary from ASPSP to ASPSP and also from customer segment to customer segment.

• We have included some comments regarding the possible scope of information available to PISPs and AISPs in our response to question 18. In relation to this PSD2 makes it clear that AISPs are only permitted to request non-sensitive payment data. Drawing upon the definition of “sensitive payment data” in PSD2 Article 4(32) and indications in RTS Article 10, it would appear that non-sensitive payment data would at the very least include name, account number, current balance and payment transactions executed in the last 90 days.

• In relation to PIS, point 6.26 in the consultation includes a clear statement that “ASPSPs are expected to provide to a PISP access to the same functionality that is available to the user when accessing their payment account online directly with the ASPSP”.

• We agree that credit transfers and the creation of standing orders are in scope of PIS if the online functionality is available to the PSU itself. We note that in the feedback table accompanying the final draft RTS the EBA states a number of times that direct debits “are out of the scope of the requirement for SCA and therefore out of the scope of the RTS”. We would agree that direct debits should generally be seen as out of scope of the PIS provisions.

• We would see AIS as allowing consumers and businesses to obtain a consolidated view of their accounts and to use tools to analyse their transactions and spending patterns. We would see the purpose being to make the data available to the PSU rather than taking the information and making it more generally available to other parties (albeit this could be done with separate PSU consent, falling outside the scope of AIS). Our current understanding is that, in the context of AIS, there would likely be a direct relationship between the AISP and the PSU.

1 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 payment initiation service providers and account information service providers, the name of the account owner and the account number do not constitute sensitive payment data”.

Page 5 MEMBER CIRCULATION

• We see a risk of unintended consequences in applying a very broad and literal interpretation to the definitions of PIS and AIS. The intention of the European Commission underpinning PSD2 was to encourage and support innovation and competition in the provision of payment services, especially in the realm of ecommerce and the retail market. Another risk is that if the UK’s scope is set too broadly compared to the approach in other member states (going against the maximum harmonisation principle), it will hamper the provision of cross-border services, creating fragmentation and customer confusion.

• Point 6.33 in the consultation rightly highlights the fact that provision of access by ASPSPs comes with a (significant) cost and we note that the consultation document makes a clear statement that “ASPSPs only have to provide one mechanism”. We support this as a general principle as we have always thought that it would be unreasonable to expect all ASPSPs across Europe to support an unlimited number of PISP and AISP business models in different member states.

• Further clarity and guidance is required concerning the management and oversight of disputes between TPPs and ASPSPs and the liability model, especially in relation to the provision of AIS as this has not been articulated in the PSD2 text.

• The initial period of implementation, before the EBA RTS are fully in force gives us a number of concerns as set out in our response to question 22.

• There needs to be clarity regarding the scope of the TPP-related provisions and the entities captured (or not) - including (as appropriate) those in the upstream or downstream chain - in order to ensure that the competent authority has sufficient powers to monitor compliance and address any issues which may emerge that might lead to customer (especially consumer) detriment.

OUR DETAILED RESPONSE

1 QUESTION 1: Do you agree with the government’s proposed approach to implementation of the PSDII? Bearing in mind the maximum harmonising nature of the PSDII, do you think the structure of the regulatory regime will allow the UK’s competent authorities to enforce the regulations in a fair and equal way towards all payment service providers?

1.1 Introduction We have utilised our response to question 1 to:

• provide some general comments concerning the UK’s proposed approach to implementation of PSD2;

• highlight some comments or concerns relating to parts of the consultation document or draft regulations on areas not specifically addressed by the questions; and

• flag areas where we think there may be errors in the consultation document or the draft regulations.

1.2 General comments

1.2.1 We are generally supportive of the government’s proposed approach to ‘copy-out’ the legislative text and to build upon the existing Payment Services Regulations (PSRs), which is in line with the maximum harmonisation nature of PSD2. This should help to promote a

Page 6 MEMBER CIRCULATION

consistent implementation and provide clarity for payment service providers (PSPs) and payment service users (PSUs) while limiting fragmentation, especially where payment services are provided on a cross-border or pan-European basis. However, there are several areas which seem to be out of line with this principle. For example, it is unclear why there are proposals to alter the underlying legislation of two maximum harmonisation directives (the Consumer Credit Directive and PSD2).

1.2.2 We support the continued application of derogations that were exercised during the implementation of the current PSD.

1.2.3 There is also significant scope creep from the CMA remedies Order on Open Banking into the PSD2 transposition.

1.2.4 The ‘copy-out’ approach in relation to some of the new provisions does also give scope for different interpretations as to the meaning of certain parts of the text and thus how PSPs might implement those requirements. It remains unclear to what extent further clarification will be forthcoming via the FCA’s anticipated consultation on its approach.

1.2.5 The approach to complaints-handling is unclear from the draft regulations, especially since payment complaints have different timelines (and FOS referral times) than other types of complaints. We believe, given the industry investment, consumer satisfaction and consensus around the new DISP process, that this risks causing confusion for customers and additional costs and complexity for PSPs, which is not beneficial for either party.

1.2.6 The format of the draft PSRs (PSRs2) makes it difficult, in several cases, to track where the PSD2 text can be found or even to check whether anything may have been accidentally or intentionally omitted. For example, it is not immediately apparent that key provisions in PSD2 Article 62(3) and 62(4) are in fact referenced in Schedule 8 in relation to amendments to the Consumer Rights (Payment Surcharges) Regulations 2012. It would be helpful if the PSRs could include a table in an Annex that lists the PSD2 Articles and identifies where the equivalent provision can be found in (or referred to in) the PSRs. A tracked changes version of the draft Regulations compared to the current PSRs would also be useful to help PSPs with the gap analysis.

1.2.7 There needs to be clarity regarding the scope of the TPP-related provisions and the entities captured (or not) - including (as appropriate) those in the upstream or downstream chain - in order to ensure that the competent authority has sufficient powers to monitor compliance and address any issues which may emerge that might lead to customer (especially consumer) detriment.

1.3 Relationship between the Consumer Credit Act and the PSRs

1.3.1 We feel that the proposal to apply the pre-contract information requirements of the PSRs to regulated credit agreements is potentially problematic and introduces ambiguity in the interaction between the CCA and the draft PSRs2. We had expected that the PSRs2 would largely follow the existing PSRs as far as interaction with the consumer credit

Page 7 MEMBER CIRCULATION

regime was concerned and did not expect that HMT would use the PSRs2 to make significant changes.

1.3.2 Given the short timescale for the consultation, we have not yet had a chance to undertake a proper gap analysis of the changes and their impact. However, we are aware that in a number of instances the provisions of the CCA may be similar but not identical to the equivalent provisions in the PSRs2. Our concern would be that the changes may inadvertently diminish the current rights under the CCA, where a higher level of disclosure applies. We will, in due course, provide more analysis of this risk at a more granular level.

1.3.3 In addition, we are aware that HMT is looking separately at modernising the consumer credit regime and which provisions of the existing CCA may be repealed. Our preference, therefore, would be that HMT makes no changes to the interaction of the PSRs2 with the consumer credit regime, pending the outcome of this review, which is likely to have a significant impact on which existing provisions of the CCA are retained. We note that there have been a number of discussions about some of the outdated information provisions in the CCA and the team looking at this issue are well placed to make recommendations as to whether certain existing provisions of CCA should be repealed in favour of compensating provisions of the PSRs2.

1.3.4 Please also refer to our response to question 10.

1.4 Card pre-authorisations

1.4.1 Point 5.8(8) of the consultation document refers to the implementation of PSD2 Article 75 (Payment transactions where the transaction amount is not known in advance) by means of regulation 78. This topic has previously been discussed at the FCA PSD2 Stakeholder Liaison Group and we remain comfortable that current industry practice meets these requirements.

1.4.2 The card payments industry has a well-established framework for pre-authorised payments, as set out in the industry’s Standard 70 (this is a document that sets out requirements for acquirers, terminal manufacturers and other parties who facilitate card payments, based on the international card scheme rules). Pre-authorisation is an important facility for a number of different scenarios, including hotel bookings, vehicle hire, bar tabs and online supermarket shopping, and it is important that there is some flexibility around this.

1.4.3 Standard 70 Section 7.3 – 7.6 sets out different scenarios in which a pre-authorisation might be used. According to Standard 70, 7.3.2.2, there are two options for the amount that is entered at pre-authorisation stage. This is either a ‘unit amount’ (e.g. the costs of one night’s stay in a hotel or first day of car hire) or an ‘estimated amount’, where the retailer estimates the final amount (e.g. 3 nights in a hotel + 20%, one week’s car hire). Usually this amount will be communicated to the cardholder before they authorise it, thus meeting the requirement in PSD2 Article 75.

Page 8 MEMBER CIRCULATION

1.4.4 PSD2 Article 75 stipulates two situations in which funds should be released, namely “without undue delay after receipt of the information about the exact amount of the payment transaction and at the latest after receipt of the payment order”. Card issuers can only match transactions where the merchant has processed the transaction correctly in line with the card scheme rules, providing the reference that links the pre-authorisation to the payment order. As the value of the payment order is likely to differ from the value of the pre-authorisation this linking reference is the only way that the issuer can reliably match the transaction. In the vast majority of cases a match is successfully made and blocked funds are released during the process where the final transaction is applied to the account. However, inevitably there are some circumstances where card issuers cannot match the payment order to the pre-authorisation, where it has not been flagged correctly by the merchant. To address this, issuers automatically release funds held under a pre-authorisation.

1.4.5 Standard 70 does not specify the timescales for release of the funds. However, it is common industry practice for funds to be released within 5 days for debit cards and 7 days for credit cards. We believe this fits within the specified timescale of ‘without undue delay’. It is important to note that where a pre-authorisation has been sought by the merchant and granted by the issuer, the payment is guaranteed by the issuer and cannot subsequently be declined. This is why the issuer ring-fences funds to meet a future transaction. Accelerating the release of blocked funds would mean cardholders potentially exceeding overdraft and credit limits, incurring additional costs and would expose issuers to increased risk.

1.5 Interpretation of Article 2 and related articles

1.5.1 The scope of PSD2 has been extended to include intra-EEA payments in non-EEA currencies (PSD2 Article 2(3)) and one-leg transactions in any currency (PSD2 Article 2(4)) as noted in point 2.23 in the consultation. Depending upon the scenario only certain of the PSD2 provisions apply. We also note the statement in consultation point 2.25, which says: “Whether foreign currency transactions are cleared and settled abroad is not considered relevant. The EU part of the transaction will be in scope if at least one of the PSPs is within the Union”. It is important to have consistency and clarity as to: (i) how Article 2 should be applied by PSPs, especially in the context of correspondent banking; (ii) the meaning of the “EU part”.

1.5.2 Our current understanding is in line with the interpretation set out in the European Banking Federation’s (EBF’s) PSD2 Guidance published in September 2016. This makes it clear, for example, that the process of conversion between an EEA currency and a non-EEA currency, or between two non-EEA currencies, falls outside the scope of PSD2 (beyond the transparency and information requirements set in e.g. Articles 52, 57, 58 and 59 relating to exchange rates and charges) as it is separate to the payment. In addition, as with PSD1, PSD2 does not apply to the inter-PSP space (so the intermediary PSP is not subject to the obligations) but simply to the customer-to-PSP relationship. PSD2 applies only to the part of the transaction that is taking place within the EU.

Page 9 MEMBER CIRCULATION

1.5.3 We anticipate that application of the PSD2 Article 2 provisions at a more detailed level than that described in points 2.22-2.25 in the consultation will be addressed as part of the work on the FCA’s approach to PSD2. We would welcome confirmation that the UK authorities support the EBF’s interpretation.

1.6 Liability and authentication

1.6.1 Regulation 91(7) requires that, when requested by the payer's PSP (on behalf of the payer) when a transaction has been executed late, the payee's PSP must ensure that value is given to the payee as if the transaction had been executed correctly. Regulation 91(2) provides further clarity such that the payer's PSP is liable to the payee's PSP in this case, and regulation 95 goes further to say that the payee's PSP should receive compensation for the same action. Where we require further clarity is how this will work in practice. Are there restrictions on the reasonable nature of the compensation? Should the payee's PSP receive both the funds and the compensation before they are obliged to act upon the payer's PSP's request?

1.6.2 Strong customer authentication (SCA) is to be used where, according to regulation 100(1)(c) a PSU “carries out any action through a remote channel which may imply a risk of payment fraud or other abuses”. This is a direct copy-out of PSD2 Article 97(1)(c). It is unclear whether this includes telephone banking. However, we note that in the table of comments accompanying the final draft of the EBA RTS on SCA and secure communication, the EBA has stated that it “is of the view that anything initiated via paper or telephone is out of the scope of SCA under PSD2 and therefore out of the scope of the RTS”. We assume the UK authorities share the EBA’s interpretation.

1.6.3 PSD2 Article 74.2 states that “Where the payer’s payment service provider does not require strong customer authentication, the payer shall not bear any financial losses unless the payer has acted fraudulently”. Regulation 77(4)(c) PSRs2 states, “Except where the payer has acted fraudulently, the payer is not liable for any losses incurred in respect of an unauthorised payment transaction … where the payer’s payment service provider does not require strong customer authentication”. What this does not clarify is the extent to which a PSP which does not require SCA because of exemptions in the EBA RTS is also caught by this.

1.6.4 In addition, regulation 77 itself will come into force on 13 January 2018 (in accordance with regulation 1(5)) but regulation 100 (the requirement to apply SCA in accordance with the RTS) only comes into effect 18 months after the RTS come into force (regulation 1(4) transposing PSD2 Article 115(4)) i.e. November 2018 at the earliest. As a result, it is unclear to what extent a PSP can hold a PSU liable for an unauthorised transaction (absent fraud) during this interim period where no SCA is required. We assume that PSD2 Article 74(2) is relevant in terms of determining where liability ultimately lies in the event that no SCA is applied. We would query whether regulation 77(4)(c) should also be subject to delayed implementation under regulation 1(4). By extension we would also query point 6.38 of the Consultation (in relation to access to AISPs and PISPs) which sets out an

Page 10 MEMBER CIRCULATION

expectation that the draft RTS on SCA (now the final draft, subject to European Commission adoption) be followed in the interim period.

1.7 Possible Drafting/Transposition Errors

1.7.1 We have identified what appear to be some possible transposition errors to which we would draw your attention as follows:

Implementation of PSD2 Article 2 • According to PSD2 Article 2(4) certain Title III (information requirements) and Title IV

(rights and obligations) provisions do not apply to one-leg payments in any currency. More specifically, PSD2 Article 2(4) makes it clear that Article 89 (PSPs’ liability for non-execution, defective or late execution of payment transactions) and Article 92 (right of recourse) do not apply to one-leg payments in any currency.

• This is not reflected in draft regulation 63(3)(b), which should show that regulations 91, 92 and 94 (implementing PSD2 Article 89) and regulation 95 (implementing PSD2 Article 92) do not apply.

• PSD2 Article 2(4) clearly states that the provisions in PSD2 Article 62(4) do not apply to one-leg transactions but this is not readily apparent from a reading of the draft regulations (and especially draft regulation 63(3)(b)) since the relevant reference is in fact somewhat buried in Schedule 8(7)(6)(6B) concerning amendments to the Consumer Rights (Payment Surcharges) Regulations 2012.

Limited network exclusion • PSD2 Article 3(k) refers to such services “that meet one of the following conditions…”

whereas the text in Schedule 1 Part 2(k) does not make it clear whether the sub-clauses are alternatives or cumulative conditions that a service would need to meet.

Draft regulation 2 – definition of ‘strong customer authentication’ • There are subtle differences between how ‘strong customer authentication’ is defined in

PSD2 Article 4(30)2 and in draft regulation 23. We should like to understand why HMT has not just copied out the PSD2 definition and would like confirmation that there is no intention to extend or alter the scope and meaning of the PSD2 definition. In view of the significance and interdependence in relation to the EBA RTS on strong customer authentication and secure communication, we would advocate that the PSD2 definition is adopted.

2 According to PSD2 Article 4(30) ‘strong customer authentication’ (SCA) means “an authentication based on the use of two or more elements categorised as knowledge (something only the user knows), possession (something only the user possesses) and inherence (something the user is) that are independent, in that the breach of one does not compromise the reliability of the others, and is designed in such a way as to protect the confidentiality of the authentication data”; 3 According to PSRs draft regulation 2 SCA means “authentication based on the use of two or more independent elements, the reliability of each element not being compromised by the breach of any other element, and designed in such a way as to protect the confidentiality of the authentication data, with such elements falling into two or more of the following categories— (a) something known only by the payment service user (“knowledge”); (b) something held only by the payment service user (“possession”); (c) something inherent to the payment service user (“inherence”);

Page 11 MEMBER CIRCULATION

Draft regulation 66(3) - Charges • According to PSD2 Article 62(3), the PSP “shall not prevent the payee from requesting

from the payer a charge, offering him a reduction or otherwise steering him towards the use of a given payment instrument”. The implication is that payees can request a charge or offer a reduction or steer the payer in some other way whereas the wording of draft regulation 66(3) seems to combine requesting a charge with offering a reduction since it says ”(a) requesting payment of a charge by; (b) offering a reduction…”. Was this intentional?

Draft regulation 68(4) – Confirmation of availability of funds • There are a number of references in regulation 68 to “a request under paragraph 1”; we

think these references need to be amended to “a request under paragraph 2”. • Similarly references to “paragraph 3” should instead refer to “paragraph 4”.

Draft regulation 69(2) – Access to payment accounts for PIS • We think the reference to “explicit consent in accordance with regulation 66” should be

amended to “explicit consent in accordance with regulation 67”. Regulation 66 relates to charges whereas regulation 67 deals with consent and withdrawal of consent.

Draft regulation 70 – Access to payment accounts for AIS • PSD2 Article 67(2)(e) clearly states that the AISP shall “not request sensitive payment

data linked to the payment accounts”. However, draft regulation 70(3)(e) has incorrectly replaced the word “request” with “store”.

• PSD2 Article 67(2)(f) indicates that the AISP shall “not use, access or store any data for purposes other than for performing the account information service explicitly requested by the payment service user, in accordance with data protection rules”. This is largely reflected in draft regulation 70(3)(g) albeit not word for word. We would, however, query why reference to “data protection rules” has not been included. We also note what appears to be an additional but similar provision has been added in draft regulation 70(3)(f) which says that the AISP must “not request any information from a payer except information required to provide the account information service”.

Draft regulation 72 – Obligations of the PSU in relation to payment instruments and personalised security credentials • The way in which draft regulation 72(2) has been drafted makes it look as if proportionate

terms cannot be enforced against the customer. 72.—(1) A payment service user to whom a payment instrument has been issued must— (a) use the payment instrument in accordance with the terms and conditions governing its issue and use; and (b) notify the payment service provider in the agreed manner and without undue delay on becoming aware of the loss, theft, misappropriation or unauthorised use of the payment instrument. (2) Paragraph (1)(a) does not apply in relation to any term that is not objective, non-discriminatory and proportionate.

Page 12 MEMBER CIRCULATION

Draft regulation 75 - Evidence on authentication and execution of payment transactions • Draft regulation 75(3) introduces extra text that is not included in PSD2 (in Article 72) to

define the term “authenticated”4, which conflicts with the actual PSD2 definition of “authentication” in PSD2 Article 4(29)5. The purpose is unclear and risks causing confusion.

• References to the PISP have been missed out in draft regulation 75(4) and 75(5).

Draft regulation 76 - PSP’s liability for unauthorised transactions • According to consultation point 5.8(6) “Article 73 states that PSPs must immediately refund

the amount of an unauthorised transaction…” although the actual PSD2 is more contradictory since it says the payer’s PSP should refund the payer “immediately, and in any event no later than the end of the following business day”. We note the language ‘immediate’ no longer exists in draft regulation 76(2), which instead uses the language “as soon as practicable, and in any event no later than the end of the business day following the day on which it becomes aware of the unauthorised transaction”.

• We would welcome clarity on whether this has been done to overcome the ambiguity in the PSD2 text and if HMT expects this change in language to have a material impact to a PSP’s operation, particularly in light of the introduction of PIS which may add an additional layer of complexity to any investigation of an unauthorised claim.

Draft regulation 77 – Payer or payee’s liability for unauthorised payment transactions Draft regulation 77(4)(b) cross references regulation 72(1)(c) which does not exist. Should

this refer instead to regulation 73(1)(c)? Draft regulation 77(5) has an incorrect cross reference to 5(3)(d) which should be 5(4)(d)

and contains definitions for the specific paragraph which are not required in the directive. Draft regulation 82(3) – Refusal of payment orders • Draft regulation 82(3) states that the PSP may charge for “notification” of the refusal

“where the refusal is reasonably justified”. PSD2 Article 79(1) on the other hand states the PSP “may charge a reasonable fee for such a refusal if the refusal is objectively justified”. So PSD2 seems to apply to the fee for refusing a payment order and the draft PSRs to the fee for notifying the customer of the fact that a payment order has been refused. Is this intentional as a fee for refusing a payment order and a fee for notifying the customer of a refusal could be different?

Draft regulation 89(1) - Value date and availability of funds • We think regulation 89(1) should end with “payee’s payment service provider’s account” to

be fully consistent with the text in PSD2 Article 87(1).

4 Draft regulation 75(3): “In paragraphs (1) and (2) “authenticated” means the use of any procedure by which a payment service provider is able to verify the use of a specific payment instrument, including its personalised security credentials”. 5 PSD2 Article 4(29) definition of “authentication” – “means a procedure which allows the payment service provider to verify the identity of a payment service user or the validity of the use of a specific payment instrument, including the use of the user’s personalised security credentials”.

Page 13 MEMBER CIRCULATION

Draft regulation 91(3) - PSPs’ liability for non-execution, defective or late execution of payment transactions • Consultation point 5.8(12) refers to the payer’s PSP refunding the payer “without undue

delay”, which is in line with the wording used in PSD2 Article 89. Draft regulation 91(3) has replaced “without undue delay” with the term “immediately” which is arguably a higher standard. Is this intentional?

Draft regulation 92(8) – Non-execution or defective or late execution of payment transactions initiated by the payee • Two words have been accidentally repeated as flagged below:

“If the payer’s payment service provider proves that the payee’s service provider has received the amount of the payment transaction, paragraph (6) does not apply and the payee’s payment service provider must value date the amount on the payee’s payment account no later than the date the amount would have been value dated if the if the transaction had been executed correctly.”

Draft regulation 100 - Authentication • Draft regulation 100 refers to “account information services” when it should be payment

initiation only for point (b). 100.—(1) A payment service provider must apply strong customer authentication where a payment service user directly or through an account information service provider— (a) accesses its payment account online; (b) initiates an electronic payment transaction; or (c) carries out any action through a remote channel which may imply a risk of payment fraud or other abuses.

Draft regulation 101 - Dispute resolution • Draft regulation 101(5) has omitted a word ("and at the latest 15 business days [?] the day

on which..."). Confirmation is required as to whether this is 15 days from the receipt of the complaint or 15 days after the receipt of the complaint.

• A similar question also arises in connection with PSD2 Article 101(2), which states that “the deadline for receiving the final reply shall not exceed 35 business days”. The final sentence in draft regulation 101(6) says “Such deadline must not be later than 35 business days after the day on which the payment service provider received the complaint”.

1.8 References to Euro versus Sterling amounts

1.8.1 In point 5.23 of the consultation reference is made to implementation of PSD2 Article 74 (regulation 77) concerning the payer’s or payee’s liability for an unauthorised payment transaction. In PSD2 a maximum of €50 is set (previously €150 in the original PSD) and we accept that member states have flexibility to reduce this sum where the payer “has neither acted fraudulently not intentionally failed to fulfil its obligations…”. We note that HMT is proposing to amend the amount from the current figure of £50 set in UK law to £35. We wonder to what extent HMT has given consideration to the current volatility of the exchange rate environment when setting this figure.

Page 14 MEMBER CIRCULATION

1.8.2 Conversely we note that as regards the thresholds for low-value payment instruments, as highlighted in the consultation document in relation to questions 12 and 16, the values are set in Euro. We think it would be helpful to adopt a consistent approach. We note that PSD2 Recital 104 explicitly states that where PSD2 makes reference to amounts in Euro “these amounts have to be intended as the national currency equivalent as determined by each non-Euro Member State”. Using euro equivalents is far from ideal, especially when foreign exchange rates are very volatile, and runs the risk of incurring extra costs if processes or terms and conditions need amendment. We would strongly support GBP amounts being specified in the regulations.

1.9 Transparency and information requirements

1.9.1 Consultation point 4.2 is incorrect as the information requirements do not have to be included in customer terms.

1.9.2 Consultation point 4.5(5) should refer to both “payee” and “payer” in the penultimate line.

2 QUESTION 2: A consultation stage impact assessment of the proposed changes will be published before the end of the consultation. Do you have any comments on the impact of the PSDII set out in the impact assessment?

2.1 Due to the delayed publication of the consultation impact assessment (IA), unfortunately we have not had an opportunity to review and discuss the contents with our members. However, we believe that our responses to other questions in the consultation document have identified areas where we see potential impacts – both positive and negative on - PSPs and customers.

3 QUESTION 3: Do you agree that the government should continue to exempt the institutions listed above from the PSDII?

3.1 We are not aware that exemption of certain UK institutions (e.g. National Savings Bank, credit unions and municipal banks) has created any problems so we are supportive of the government’s proposal to continue to exercise the derogation in a similar manner under PSD2.

4 QUESTION 4: If you intend to make use of the electronic communications networks and services exemption, how do you intend to track the €50 and €300 spending limit?

4.1 We have no comment or input to provide.

Page 15 MEMBER CIRCULATION

5 QUESTION 5: Is the approach on cascading useful to intermediaries given the limits on the exemption and the potential need for authorisation or registration for other services provided? What types of business models would benefit?

5.1 We have no comment or input to provide.

6 QUESTION 6: Do you agree with the government’s interpretation of the limited network and commercial agent exemptions? Which business models do you think may now be brought into scope that were previously exempt?

6.1 Please see our comments under question 1 regarding a possible transposition error in relation to the limited network provision.

7 QUESTION 7: Do you agree with the proposed change to safeguarding to ensure funds can be deposited with the Bank of England?

7.1 We are supportive of options which promote competition and accessibility to appropriately authorised PSPs.

8 QUESTION 8: Do you agree with the government’s proposed approach to access to payment systems and payment account services?

8.1 Access to payment systems (Article 35)

8.1.1 In relation to Article 35(2) we welcome the clarification provided in point 3.12 of the consultation that the cheque clearing system, while designated, is deemed to be out of scope.

8.1.2 We understand in relation to point 3.12 that while Article 35(2) “introduces a new requirement that participants in payment systems designated under the SFD should provide any indirect access services…” there is no intention to extend this right to securities settlement systems, which are also designated under the SFD.

8.1.3 We also support the clear statements made in point 3.13 that Article 35(2) “does not impose an absolute obligation for participants to grant indirect access to all PSPs that request it. The decision to work with a given PSP is still a commercial one, with participants able to take into account cost and risk”. If this language cannot be expressly reflected in the draft regulations, it would be helpful if this point is made clear as part of the FCA’s approach/guidance.

8.1.4 The document usefully acknowledges that not all direct participants in a payment system will choose to offer indirect access services (“where a PSP does provide indirect access”) as this is also a commercial decision.

Page 16 MEMBER CIRCULATION

8.1.5 We see in point 3.14 that the government is proposing that the PSR continues to be the competent authority for enforcement of the access to payment systems provisions. We are aware that the PSR also has certain powers under sections 56 (Power to require granting of access to payment systems) and 57 (Variation of agreements relating to payment systems) of the Financial Services (Banking Reform) Act 2013 (FSBRA) and it would be helpful if further clarity was provided regarding the interaction of the PSRs with the FSBRA provisions and any other relevant regulatory initiatives in this area to facilitate PSPs’ understanding of the holistic requirements.

8.1.6 There is a concern that the draft PSRs2 gold-plate as, rather than following the wording in PSD2 Article 35(2), draft regulation 104(2)(b)(ii) duplicates text used in point 1.14 of the Payment Systems Regulator’s consultation6 on its draft guidance concerning its approach to handling applications under sections 56 and 57 of FSBRA.

8.1.7 We agree that access to the UK's payment systems is necessary for organisations providing payment services to their customers. We note government’s expectations (as set out in point 3.13) that PSPs are required to “Have in place appropriate internal processes to be able to consider decisions on providing indirect access services on a case-by-case basis, and provide their criteria for indirect access clearly to current and prospective customers”. To help meet this need, and in collaboration with the UK's primary payment schemes, a website has been created to serve as an online focal point for any organisation that needs to access payment systems. The Access to Payment Systems website7 is designed to improve the disclosure and transparency of information for participants in payment systems. The Access to Payment Systems website also hosts the Code of Conduct for Indirect Access Providers8 (IAPs). This voluntary Code of Conduct has been developed in response to the findings of the Payment Systems Regulator’s consultation paper CP14, “A New Regulatory Framework for Payment Systems in the UK”.

8.1.8 The Code sets out standards of best practice for key elements of the commercial arrangements between IAPs and Indirect PSPs (IPSPs). Its principle aim is to improve the experience of IPSPs by clearly setting out the responsibilities of IAPs who subscribe to the Code. Specifically, the Code is designed to meet the requirements of IPSPs for: o clarity on the contractual arrangements that govern the supply of Indirect Access

Services they receive; o security of the supply of Indirect Access; o confidentiality of commercially sensitive information shared with IAPs; o support in establishing Indirect Access and in switching between providers; and o appropriate and timely communication between IAPS & IPSPs regarding the

availability of services and planned changes. We believe that the website and Code provide a vital support to meeting the government’s expectations and the Article 35 objective.

6 PSR CP 16/4: Our approach to handling applications under sections 56 and 57 FSBRA https://www.psr.org.uk/psr-publications/consultations/PSR-CP164-consultation-paper 7 http://www.accesstopaymentsystems.co.uk/ 8 http://www.accesstopaymentsystems.co.uk/code-of-conduct

Page 17 MEMBER CIRCULATION

8.1.9 It should also be understood that, in granting indirect payment systems access to PSPs, the direct participant is required to ensure that the indirect participant can comply with any relevant scheme rules regarding indirect participation and, potentially, this could impact on access. For example, the CHAPS Rules have been recently updated to include requirements for indirect participants to incorporate certain obligations in their own customer terms and conditions and for direct participants to monitor their indirect participants in order to confirm that they are meeting their contractual obligations. The requirements of the payment scheme rules could therefore impact on the ability of a direct participant to provide access, particularly if they go further than the requirements of PSD2.

8.2 Access to payment account services (Article 36)

8.2.1 The acknowledgement in point 3.17 of the consultation document helpfully reiterates the fact that the Article 36 provision (to be implemented via regulation 105) “does not impose an absolute obligation for credit institutions to grant access”. We support this assertion since ‘payments on behalf of’ do inherently have an impact on the risk profile of the credit institution’s payments profile9. We believe that it is important that credit institutions retain the right to take reasonable commercial and risk decisions.

8.2.2 We are broadly supportive of the approach that HMT has proposed, albeit that the wording of regulation 105 (especially in 105(1)(a) – (c) and 105(3)) goes well beyond the requirements set by PSD2 Article 36. We should like to understand why HMT has chosen to gold-plate.

8.2.3 Point 3.10 of the consultation explicitly refers to the “new provisions, in Article 36, regarding access to payment account services by payment institutions”. This is in line with the PSD2 text, according to which member states are required to “ensure that payment institutions have access to credit institutions’ payment accounts services on an objective, non-discriminatory and proportionate basis”. However, we note that the transposition into regulation 105 refers to granting access to all types of PSP, not just payment institutions. Is this an intentional expansion of the scope?

8.2.4 Regulation 105(b) refers to an enquiry about access being made. We think care is needed as to what constitutes an “enquiry”. We would interpret this to mean a stage where there is formal engagement and application of a due diligence process. Where, for example, a PSP has expressed an interest but chooses not to progress their application, we would not expect this to be considered as an enquiry that is required to be reported.

8.2.5 We note that regulation 105(b) indicates that the credit institution should “include in the response to the enquiry the criteria that the credit institution applies”. We are pleased to see that there is no expectation for public disclosure by credit institutions of their criteria for

9 Credit institutions are unable to apply the same levels of control and KYC to customers of entities that they bank, rather than their own direct customers. The credit institution has to be able to validate the ultimate remitter against relevant AML etc. lists and trust that the entity initiating the payment (i.e. the direct customer of the credit institution) on behalf of another person or entity, has sufficient processes in place to ensure that the information is valid.

Page 18 MEMBER CIRCULATION

granting access, which might otherwise have had anti-competitive impacts. We accept the need for objective criteria that take account of the credit institution’s need to meet its management of financial crime obligations and reflect the firm’s risk appetite. We are interested to understand how this will be assessed by the competent authorities.

8.2.6 Regulations 105(3) and (4) set the requirements for notification of the competent authority in the event that it refuses a request for access. These go beyond the requirements in the PSD2 text but we would hope that any such notifications are treated in confidence and are sensitive to other regulatory or legal obligations. However, the process and timing for these notifications, and how credit institutions should manage scenarios with customers where there is law enforcement or regulatory involvement in the context of 'tipping' off etc. is currently unclear. We would welcome further clarity from the FCA in this respect.

8.2.7 In points 2.5 and 2.6 of the previously-mentioned PSR consultation10 - on its draft guidance concerning its approach to handling applications under sections 56 and 57 of FSBRA - it expressly states that the PSR “will not consider applications involving access to bank accounts if: o the bank account is not used to send and receive payments using a regulated

payment system; o the applicant is not using the regulated payment system for the purposes of

transferring funds on behalf of its customers”. In addition, in point 2.6, it says the PSR “will not consider applications for access to bank accounts intended to be used solely to enable a PSP to operate its business (for example, to make salary payments or to pay suppliers)”. It will be important for there to be clarity regarding the interaction of these various regulatory proposals. We would welcome further clarification as to how the FCA and PSR will work together, particularly on areas such as dispute resolution. Furthermore, we would welcome clarity on how the PSR/FCA will see the notice of termination/refusal of applications under Regulations 105(4)(a) and (b) working with their powers under sections 56 and 57 of the FSBRA.

8.2.8 In point 3.16 of the consultation HMT has set out the government’s interpretation of “payment account services” as including “payment accounts used for the purposes of making payment transactions on behalf of clients, safeguarding accounts, and operational accounts”. In connection with the latter two types of account it would be helpful to understand if these are references to other PSD2 Title II provisions (e.g. Article 10) or the Bank of England proposals described in point 3.9 of the consultation and for this to be made clearer.

9 QUESTION 9: Do you agree with the approach to continue to exercise the SPI exemption, with the same conditions as under the PSD?

9.1 We support the government continuing to exercise the derogation that allows the UK to retain the existing “Small Payment Institution” exemption on the basis that it supports innovation and competition in the UK payment market.

10 PSR CP 16/4: Our approach to handling applications under sections 56 and 57 FSBRA https://www.psr.org.uk/psr-publications/consultations/PSR-CP164-consultation-paper

Page 19 MEMBER CIRCULATION

10 QUESTION 10: Do you agree that the government should extend the right of termination to overdrawn current accounts?

10.1 We do not agree that the government should extend the right of termination to overdrawn current accounts and we do not believe that the interests of customers are best served by making this change.

10.2 We do not think implementation of legislation that specifically relates to “payment services” is an appropriate vehicle to address any gaps or inconsistencies concerning consumer credit and/or payment account legislation such as the Consumer Credit Act or Payment Accounts Regulations.

10.3 There is nothing in the PSD2 text or, indeed, in the current PSD, that sets a right of termination to overdrawn current accounts. Therefore the approach the government is considering would appear to be ‘gold-plating’, which would go against the maximum harmonisation principle.

10.4 Point 4.7 of the consultation document does not make it clear whether it is referring to arranged or unarranged overdrafts (or both). The CCA is clear on termination of regulated agreements and to which regulated credit agreements those CCA provisions apply. Just because CCA states that certain of its provisions do not apply to excluded agreements (e.g. to authorised business and non-business overdrafts or overrunning) does not mean that the PSR2s should be extended to cover credit agreements.

10.5 These new proposals come as a complete surprise to PSPs and, if pursued, run the risk of introducing further complexity into the implementation of PSD2.

10.6 We acknowledge that there is an existing market practice that allows a customer to switch current accounts even when overdrawn but this is not an absolute right. It requires the new bank to agree to offer a new lending arrangement, after conducting its own credit risk assessment, to replace that held with the old bank and such decisions are not necessarily dependent on the closure of the account at the old bank. Current industry rules allow customers to switch and leave some debt at the ‘old’ bank, but this right does not extend to customers who are in serious debt (in ‘Recoveries’).

10.7 As stated in the consultation document, extending the right of termination to overdrawn current accounts would leave the current account provider having to rely on contractual rights to recover the debt. Extending this practice would not appear to be encouraging responsible borrowing behaviour.

10.8 We are concerned that customers: (i) may not realise the negative consequences termination of the contract could have on their credit rating and future borrowing ability and (ii) may wrongly believe that they are ‘free’ from the overdraft debt. A customer may find themselves in a scenario where they have multiple overdraft debts, all of which are trying to be recovered, at banks and building societies with which they do not have a current account.

Page 20 MEMBER CIRCULATION

10.9 From the perspective of the banks and building societies, we believe that this could create challenges around their ability to recover debt as, by that stage, the main ‘banking’ relationship with the customer will have been terminated. One member who has experienced this scenario has found that it is indeed much more difficult to collect the overdraft debt where they no longer hold the customer relationship. Firms will no longer be able to utilise incoming funds to reduce the debt and will need to recover the debt directly from the customer, which may have commercial implications. For example, the customer’s debt would need to be dealt with by firms’ collection teams while the debt recovery process would become more drawn out and, potentially, more costly for firms.

10.10 These amendments could impact documentation across the customer base for no clear benefit. We understand that HMT is separately consulting on updating the CCA and moving it into an FCA handbook, so the proposals in the PSD2 consultation would appear to be at odds with this strategic direction.

10.11 We note that draft regulation 41(2) (in relation to the application of Part 6 in the case of consumer credit agreements) currently makes it clear that ”Regulations 50 (changes in contractual information) and 51 (termination of framework contract) do not apply”.

10.12 One option HMT could consider, which would not require changes to be made to the PSRs2, is the potential the partial switching service may offer to address the government’s policy objectives. For example, it effectively enables customers to retain a negative balance/overdrawn position at their ‘old’ provider and simultaneously to try the services of - and move their payments to - a new provider. This option enables customers to build up their relationship with the new provider, potentially to borrow from them and pay off their overdrawn balance over time.

10.13 One member has also suggested the creation of a Credit Passport to help overdrawn customers switch, by providing PSPs with better information to support their ‘credit decisioning’ at account opening.

11 QUESTION 11: Do you agree that the Title III provisions should continue to apply to transactions involving micro-enterprises in the same way as those involving consumers?

11.1 Yes we are supportive of the UK government continuing to exercise the derogation whereby micro-enterprises (and small charities) would be treated in the same way as consumers. This will allow operations within the retail space to have a consistent approach.

12 QUESTION 12: Do you agree with the government’s proposal to maintain the thresholds set for low-value payment instruments in the PSRS?

12.1 Yes we agree with the government’s proposal to maintain the thresholds set for low-value payment instruments in the PSRs (i.e. €60 and €300, and the pre-paid limit of €500 for intra-

Page 21 MEMBER CIRCULATION

UK transactions). Please also see our comments under question 1 regarding references to Euro versus Sterling amounts.

13 QUESTION 13: Do you think PSPs should be required to provide monthly statements to payers and payees?

13.1 We do not think that exercising the derogations regarding monthly statements would be appropriate since this would remove what degree of flexibility currently exists to accommodate customers’ (consumers, businesses and corporates) own preferences to determine how and when they receive information from their PSP. From a customer perspective we do not believe there is a concern to be remedied here. We therefore support the wording in the current draft PSR2 in regulations 53(3) and 54(3). This view would appear to be in line with point 75 in the consultation impact assessment published on 9 March which states: “the Government believes that this is an area which should be left to competition between providers rather than be subject to impose[d] further legal requirements”.

13.2 We would point out that the FCA has encouraged ‘smarter communications’ and we would encourage HMT to follow a similar approach. The FCA’s research demonstrates that “annual summaries…have no effect on consumer behaviour in terms of incurring overdraft charges, altering balance levels or switching to other current account providers”11; whereas, by contrast, giving consumers relevant information in an engaging way with a clear call to action has considerable effect. The CMA remedies also recognise this sentiment and rightly champion digital communication.

13.3 Point 4.10 of the consultation provides a useful summary and clarification of the PSD2 Article 57 and 58 provisions, which “allow for the option of providing monthly statements, with Article 57(2) giving the choice to PSUs and Article 58(2) giving PSPs a choice, as part of a framework contract”. However, we would also emphasise that the PSD2 text actually refers to the information being “provided or made available”. Reference to “made available” is in line with the changing behaviour in the market as customers use means other than paper to access and inform themselves about their accounts. Over time it has become much easier for customers to access account information without having to rely on periodically-issued paper statements. Account information can be accessed in branch, over the telephone, at a cash machine and via digital banking. Indeed, digital banking not only makes access easier but also provides more up-to-date account information. As a result, there is less reliance on paper statements. The wording of question 13 does not make this distinction and we are unsure if this is an intentional narrowing of the interpretation or an oversight. However, we note that the draft regulations do use the phrase “provided or made available”. We also understand that the recent judgment of the European Court of Justice, in relation to Case C 375/15, which was made on 25 January 2017, addressed the issue as to “whether information given through an e-banking mailbox is ‘provided’ (as opposed to merely being ‘made available’) through a ‘durable medium’” in the context of the current PSD Article 44.

11 Page 3, FCA (March 2015), Message received? The impact of annual summaries, text alerts and mobile apps on consumer banking behaviour, FCA occasional paper No. 10, <https://www.fca.org.uk/publication/occasional-papers/occasional-paper-10.pdf

Page 22 MEMBER CIRCULATION

13.4 We understand from point 4.11 that the government “is considering whether to exercise the member state option to require that PSPs provide information on their transactions to payers and payees at least once a month, on paper or on another durable medium”. It argues that this “would maintain and confirm common practices”.

13.5 We agree that these are common practices for certain types of payment account, with the vast majority of PSPs (especially where credit is concerned) providing monthly statements12 but making these less frequent with the consent of the customer should also be possible.

13.6 We disagree with the assertion in point 4.11 in the consultation that the “default position…would mean PSPs providing payers and payees with a statement for every transaction”. The choices are:

• providing the payer/payee with details of each payment transaction to/from their account (this wouldn’t need to be a statement but would need to be provided in a durable medium e.g. email); or

• providing/making available a statement once a month whenever a payment transaction has been debited/credited subject to the framework contract providing for this.

13.7 We believe that including a condition in the framework contract that a monthly statement, containing the information in draft regulation 53(2), will be provided or made available in a particular manner avoids having to report after every transaction provided that the PSU is able to request information is provided or made available in an alternative way to that set out in the contract. Would HMT confirm that this is also their interpretation?

13.8 Since PSD2 Articles 57 and 58 refer to providing information about individual payment transactions to the payer/payee, we assume that any proposal to require PSPs to provide or make available information at least once a month would only apply where there has been a payment transaction on the account during that time. Clarification in this regard would be welcome.

13.9 Online information is not the only alternative as customers can also request a statement whenever they want. There will be those who are comfortable to receive statements less frequently than monthly but who know that if for some reason they require an “interim statement” they can request one.

13.10 According to research conducted individually by some of our members, many customers do not need or want this level of information. Instead they are looking for flexibility and different options, e.g. quarterly statements or to view balances, recent transactions and statements anytime through digital channels. One member advises, for example, that nearly two thirds of its personal customers now opt for electronic (instead of paper) statements when they open a new personal current account in branch. However, the wording of the derogations in PSD2 Articles 57(3) and 58(3) place unnecessary restrictions on member states’ ability to apply the information requirements in a more flexible way since both use the words “at least once a month”.

12 One member has also emphasised to us that it actively encourages its “vulnerable customers” to retain a monthly statement if they choose paper and, regardless of what statement frequency a customer has opted for, each would be pre-notified of any overdraft charges before they are applied.

Page 23 MEMBER CIRCULATION

13.11 As customers become comfortable with managing their own level of access online, forcing monthly statements would be a retrograde step. Also, requiring monthly statements for savings accounts in scope of the PSD2 provisions – where transactions tend to be far less frequent than, say, on current accounts and where monthly statements are less likely to be offered by default – is likely to create customer dissatisfaction and result in additional costs for PSPs with no clear benefit.

13.12 Article 47(2) of PSD1 states that “A framework contract may include a condition that the information referred to … is to be provided or made available periodically at least once a month …”. The equivalent provision in PSD2 (Article 57(2)) states “A framework contract shall include a condition that the payer may require the information referred to … be provided or made available periodically, at least once a month …”. So the choice of frequency becomes the customer’s when they are payer rather than the PSP’s. Does this requirement only apply to new payment accounts from 13 January 2018 or it will apply to all existing payment accounts on that date too? If the latter then to what extent, and what in form, do PSPs need to obtain such choice from millions of customers?

13.13 Point 4.12 in the consultation references the CCA and notes that “In the current regulations, regulation 41 switches off the provisions where section 78 of the CCA and the Consumer Credit (Running Account Credit Information) Regulations 1983 apply, which require regular statements for overdrafts”. Whilst there are CCA requirements in relation to the provision of statements for customers with CCA regulated arranged overdrafts, draft regulation 41(3) does not give the clarity between CCA requirements and PSR requirements in the same way that the current PSRs do. The CCA requirements about the giving of statements to customers are not exactly the same as required under the current PSRs, nor indeed PSD2. We would agree that for those current account customers using their arranged overdraft the CCA requirements are relevant (supplemented by PSRs as necessary). Although we do not think this is HMT’s intention, it should be clear that the manner of provision of information to satisfy CCA requirements should not be applied where CCA is not applicable, i.e. where CCA is not applicable, statements could be “made available” rather than provided.

14 QUESTION 14: Do you agree with the government’s proposal to provide access to out-of-court procedures (in the form of the FOS) only where the complainant would usually be eligible to refer a complaint to the FOS?

14.1 There are considerable complexities and subtleties to be understood, which the PSD2 text and the draft regulations struggle to make clear. We have set out below our current interpretation of points 5.8(19) and 5.8(20), along with points 5.12 – 5.13 (when read in conjunction with points 4.8 and 4.8.1), in the context of the implementation of PSD2 Articles 101 and 102. We would welcome confirmation or further clarification from HMT and the FCA on a number of these points.

14.2 HMT is proposing to exercise the derogations in PSD2 Articles 38(2) and 61(3) to apply the Title III and Title IV provisions to micro-enterprises in the same way as to consumers. We

Page 24 MEMBER CIRCULATION

are supportive of this approach. We assume that these provisions would therefore also apply to a charity with an annual income of less than £1 million as is the approach under the current PSRs but clarification in this regard would be welcome.

14.3 HMT is proposing to exercise the derogation in PSD2 Article 61(2) such that Article 102 (ADR procedures) would not apply where the PSU is not a consumer or micro-enterprise (or small charity). We support this approach.

14.4 Our understanding is that the complaints-handling requirements set by PSD2 Article 101(2) 13 apply to all types of PSU. However, only eligible complaints brought by eligible complainants can be referred to FOS, with the requirements and procedures to be addressed in the FCA’s approach to PSD2. If we have interpreted this correctly, we do not think these subtleties have been made entirely clear in the wording of draft regulation 101(1) which indicates that regulation 101 only applies to PSUs which are not eligible to bring their complaints to FOS. In addition, regulation 101(7) requires the PSP to inform the PSU “about the details of at least one provider of dispute resolution services…” and it unclear to whom the PSP should refer the PSU in this context, including situations where cross-border payment services are involved.

14.5 According to points 5.12 and 5.13 the intention would appear to be that complaints eligible for referral to FOS under PSD2 (i.e. complaints about payment services) can only be brought by eligible complainants, namely consumers, micro-enterprises and small charities. We support this approach.

14.6 We note that point 5.14 refers to the FCA considering widening the remit of FOS “from a ‘micro-enterprise’ threshold to a ‘small business’ threshold” to be implemented “by FCA rules”. The current approach to the FOS’s jurisdiction is based on the fact that consumers and micro-enterprises are very similar in terms of their sophistication levels and access to resources. If the FOS remit was to be extended to a ‘small business’ threshold, the service would need to be supported with appropriate staff training for decisioning. While for a range of practical reasons banks could support the extension of the current FOS framework to (for example) all firms of under £6.5m, no strong case has been made to date to extend coverage to larger SMEs. Larger SMEs have greater access to financial advisers and to other forms of alternative dispute resolution. Disputes arising with larger SMEs are likely to be more complex and it is in the interests of all parties for such cases to be subject to the rigour of the courts to achieve fair outcomes if resolution cannot be reached.

15 QUESTION 15: Do you agree that the prohibition on surcharging should be limited to payment instruments regulated under Chapter II of the IFRs?

15.1 The consultation document (point 5.16) rightly notes that PSD2 “introduces a default prohibition on surcharging for payment instruments for which interchange fees are capped under Chapter II of the IFR” but fails to mention in points 5.8 and 5.16, or in question 15, that the default prohibition in PSD2 Article 62(4) also applies to “payment services to which

13 Requirements for PSPs to respond to payment services complaints within 15 days and to provide a final response within 35 days – as summarised in consultation point 5.8(19).

Page 25 MEMBER CIRCULATION

Regulation (EU) No 260/2012 applies” (i.e. the SEPA Regulation). However, we see that the draft PSRs2 appear to have correctly incorporated mention of both prohibitions in terms of the proposed amendments to the Consumer Rights (Payment Surcharges) Regulations 2012 as set out in PSRs2 Schedule 8(7).

15.2 PSD2 Article 62(5) gives member states the right to “prohibit or limit the right of the payee to request charges taking into account the need to encourage competition and promote the use of efficient payment instruments”. This is a topic where we have taken a neutral position throughout the legislative process. The UK is a relatively mature card market accounting for over 30% of all card payments made in the EU. There is no single view as to whether exercising this derogation would be pro-competitive in the UK card market as it is likely to impact firms in different ways. Our members may choose to make individual representations on this issue.

16 QUESTION 16: Do you agree with the proposal to maintain the thresholds set for low-value payment instruments under the PSRs?

16.1 As noted in our response to question 12, we agree with the government’s proposal to maintain the thresholds set for low-value payment instruments in the PSRs (i.e. €60 and €300 and the pre-paid limit of €500 for intra-UK transactions). Please also see our comments under question 1 regarding references to Euro versus Sterling amounts.

17 QUESTION 17: Do you agree with the proposed approach to consent, authentication and communication?

17.1 Alignment of the Open Banking API Standard and PSD2

17.1.1 In points 6.6 to 6.12 of the consultation document HMT make a number of assertions and policy statements which are useful in providing an indication of government’s expectations. While generally welcoming these, we believe it is necessary that they are aligned to practices elsewhere in Europe.

17.1.2 We agree that the Open Banking API Standard (to be delivered by the nine named banks – the ‘CMA9 - to meet the open banking remedy set out by the CMA) “will need to align” (and be implemented in a manner compatible with) PSD2 as stated in point 6.7. We also generally endorse the observation made in point 6.10 that “APIs are only one method by which ASPSPs could provide access to AISPs and PISPs”. While it is the approach which has gained the most attention in the market, especially in the UK, other methodologies may emerge and the Open Banking API Standard may not necessarily be adopted by all players. We note that the “Executive Summary” in the final draft RTS refers to a new Article 27(2) RTS, which “clarifies that the ASPSPs may want to opt for a dedicated interface or may allow the use of the interface used for identification and communication with their payment services users”.

Page 26 MEMBER CIRCULATION

17.1.3 It will be important to ensure that there is no need for Open Banking to rebuild the API Standard in order to comply with PSD2 so as to avoid both customer confusion and additional implementation costs. Please also see our response to question 22.

17.1.4 To ensure the Open Banking API Standard is PSD2-compliant a detailed assessment of requirements, plus clarity of assumptions where build is made in advance of detailed requirements and a published service specification, are required. This would validate, for example: o standards for data structure, APIs and security; o customer communications; o consideration of the General Data Protection Regulation (GDPR); and o liability and redress.

17.1.5 It is critical too that the Open Banking API Standard, in terms of its alignment with PSD2, does not exceed the maximum harmonisation principle.

17.1.6 We share the government’s view, set out in point 6.10 of the consultation, that the proposed regulations (PSRs2) provide the “legislative foundations on which the Open Banking API Standard then sits”, albeit that the scope of PSD2 is considerably broader and is just one of several pieces of legislation with which the Open Banking API Standard - or any other mechanism utilised to deliver the third party provider provisions - will need to comply.

17.1.7 It should also be acknowledged that not all parts of the legislative foundations are currently known or finalised e.g. the requirements to be set by the EBA RTS on strong customer authentication and secure communication as well as the FCA’s PSD2 approach and, indeed, the implementation approach being adopted by other member states. Please see further comments in our response to question 22.

17.1.8 It should not be forgotten that the PSD2 provisions are not restricted to a domestic market but apply on a European basis beyond the scope of both the CMA remedy and the UK government’s open banking vision.

17.1.9 As noted in 6.11 “the CMA remedy is limited to current accounts”. PSD2 extends beyond the Open Banking remedy in terms of the type of accounts, the data, the mandated entities and the payment service users in scope. The CMA remedy applies in a retail banking and personal and business current account context while PSD2 covers all payment services and payment accounts including a corporate banking context. Open Banking requires personal current account (PCA) and business current account (BCA) non-redacted current account transaction data whereas PSD2 refers to “account information” and “associated payment transactions” and requires AISPs to identify themselves towards, and communicate with, the ASPSP in accordance with the EBA RTS on strong customer authentication and secure communication. These threshold issues concerning access to account data between Open Banking and PSD2 should be aligned as far as is possible to avoid market fragmentation and a confusing consent model for consumers.

Page 27 MEMBER CIRCULATION

17.1.10 We understand the additional observation in point 6.11 that “including all payment accounts within the initial development of the Open Banking API Standard would allow the competition and coordination benefits to be shared more broadly across a wider range of account types and services”. However, in establishing the scope of Open Banking – and having considered the broader scope of PSD2 – the CMA preferred that “the Implementation Entity should have a very clear and narrow focus” and stated that it “would not wish to see the implementation Entity’s remit extended if this would jeopardise the successful and timely implementation of the [the CMA’s] remedies”.

17.1.11 Therefore we are uncomfortable with any suggestion that providers will need to apply the Open Banking API Standard to non-PCA and BCA current accounts by January 2018, which is the delivery timeline for Read/Write access to accounts within the scope of the CMA Open Banking remedy. We also note that the CMA, in its final report, was clear that the implementation of the Open Banking API Standard in January 2018 could be delayed if it would otherwise give rise to significant risks or inefficiencies arising from a lack of alignment with the PSD2 EBA RTS on strong customer authentication and secure communication.

17.1.12 It is not clear how the Open Banking Implementation Entity could decide to extend its activities beyond the scope of the CMA remedy, given the funding and governance. What is clear is that implementing Open Banking creates an opportunity and a necessity for alignment with PSD2. However, Open Banking will not deliver a solution that encompasses the complete scope of the PSD2 provisions in January 2018. This raises important questions for the entire industry about preparedness and cooperation regarding implementation in relation to those payment accounts and PSPs that are outside the scope of the CMA remedy.

17.1.13 We are of the opinion that Open Banking should implement a solution built on open data/API standards that can be extensively reused for PSD2 and indeed other market developments such as those deriving from the PSF and BoE RTGS2. Given that the scope of the CMA order is narrower than the scope of PSD2, coupled with the concerns of the CMA that extending scope could jeopardize delivery, we believe that attention should be focused on defining the ideal governance vehicle and market engagement to develop Open Banking post-January 2018 and, particularly, in the period between January 2018 (PSD2) and the effective date of the EBA RTS on strong customer authentication and secure communication, which could form an ideal time for market growth in adopting the standards for Open Banking. We therefore suggest that HMT discusses the design of the long term governance in order to achieve the best outcomes for the wider market implementation of PSD2 TPP-related provisions in an economically sustainable manner. We would advocate that the work to consolidate the retail PSOs, sponsored by the BoE and PSR, would seem relevant to this longer term undertaking.

17.2 Role of the competent authority

17.2.1 We are aware that the competent authorities in each member state will be responsible for authorisation and registration of third party card-based payment instrument issuers (PIIs),

Page 28 MEMBER CIRCULATION

PISPs and AISPs and, as mentioned in the consultation document in point 6.13, in the UK this role will be performed by the FCA who will manage the public register referred to in PSD2 Article 14 and regulation 4 in the PSRs2. Its system for doing so must operate seamlessly with the Open Banking API Standard and certificate issuing authority (if different from the Open Banking Implementation Entity), which would also need to interoperate with equivalent registers provided in other member states. In addition, the FCA and equivalent competent authorities in other member states are required to notify the EBA of the “information entered in their public registers” in accordance with PSD2 Article 15 (EBA register) although this does not appear to be explicitly mentioned in the draft regulations.

17.2.2 We strongly believe that some form of real-time capability will be required to verify a PII’s, PISP’s or AISP’s authorisation/registration status with the FCA (and other member states’ competent authorities) both from customer protection and from a liability model perspective. This clearly has technical implications which PSPs need to accommodate into their implementation plans. There is risk and uncertainty involved where the industry is expected to proceed in the absence of any detail or clarity regarding the functionality and technical accessibility of these member state registers and the EBA central (but not legally-binding) register.

17.2.3 There is extra complexity added with regard to the CMA remedy, where we note the additional challenge that the CMA may require separate whitelisting requirements if the entities in scope of access to Open Banking are out of scope of the PSD2-set FCA authorisation/registration process. In order to ensure customer protection is at the heart of open banking, HMT and the FCA should work together on ensuring that the criteria for third parties to get onto the competent authorities’ registers and whitelists are suitably robust to match the sensitivity of the banking data and payments functionality they will be able to access. The UK Banking industry has established very strong security best practice to protect customers’ data through online services, and we would expect the FCA to hold PIIs, PISPs and AISPs to the same standard.

17.2.4 Point 6.14 of the consultation indicates that “industry” is to be left to solve many of the problems and practicalities arising from implementation of the PSD2 provisions. A similar statement is also made in point 6.36. We comment on this in our response to question 21.

17.3 Consent

17.3.1 We agree with the assertion in point 6.16 that “where a payer is using an AIS or PIS, explicit consent must be obtained by the AISP or PISP for the service or payment transaction in question”. We would also add that the ‘consent’ model will need to be compliant with the GDPR and the ASPSP will need sufficient information to enable it to manage potential liability. In the context of data-sharing with a third-party we believe that a principle of informed PSU consent should be adopted. Users should clearly understand the consent they are being asked to provide, including: • who they are providing consent to; • what they are providing consent for (i.e. what the consent will permit the third party to

do and what data will be shared);

Page 29 MEMBER CIRCULATION

• which party must the PSU contact to request rectification or erasure of personal data; and

• how long the consent will last.

One member has suggested that there should be a consistent taxonomy so that each institution describes what is being consented to using exactly the same terms so as to avoid customer confusion.

17.3.2 We note that “authorisation of a payment transaction does not have to be given by the user directly to the ASPSP but can be given only to the PISP”. We assume this is a reference to PSD2 Article 64(2), as reflected in regulation 67(2)(c) which says “Consent to execute a payment transaction may also be given via the payee or the PISP”. It may, however, present some serious practical issues as to how the consent is made clear to the ASPSP. This is pertinent under the current industry position of ‘Gross Negligence’ whereby the PSU authorises a payment transaction that is later suspected to be part of a scam14. Also, we believe it is important to differentiate between the initial interaction between a PSU, PISP and ASPSP, where it is critical that the ASPSP authenticates their customer and seeks authorisation, from any subsequent requests from the PISP.

17.3.3 We believe that it is critical during the authentication procedure for AISPs and PISPs to enable ASPSPs to replay back to their customers the specific consent that the third party has requested (“authorising” the data to be shared). This means the third party would have to pass this detail to the ASPSP once the consent has been given to the third party by the customer; and that ASPSP can then ensure the customer is authorising the specific consent the third party has mentioned to the ASPSP. This is to ensure that the ASPSP knows the extent or restrictions of the PSU’s consent (e.g. what information the PSU has consented to share with an AISP and whether the PSU gave consent to the AISP for continuous access or ‘one-off’ access) so that the right access is being provided.

17.3.4 This is a vitally important fraud protection measure – without this check, the ASPSP would only be able to trust that the third party was representing the customer consent correctly. This is open to abuse by fraudsters and malicious actors, and may result in data being shared to which the customer did not consent. The authorisation of consent with the customer in no way requires the third party to explain to the ASPSP the purpose for which the data would be used; it also does not create friction, as it can take place seamlessly within authentication. All that is required is for the consents provided to be passed to the ASPSP so that the ASPSP can check that with the customer and ensure access granted matches their wishes. It is helpful in engendering confidence in the system.

17.3.5 What also remains unclear are the following consent-related issues: (i) withdrawal or amendment of consent and how this would be managed and

communicated. If a customer comes directly to their ASPSP to withdraw consent, they will have to block each request (up to 4 a day) and then notify the FCA of the refusal of access. Over a number of accounts and a number of days, this process will become overwhelming both to ASPSPs and the competent authority;

14 Which? Super complaint

Page 30 MEMBER CIRCULATION

(ii) how to address consent in situations where there may be: (a) more than one signatory on an account, e.g. joint accounts or corporate/business accounts; or (b) different access permissions on the underlying account, which can be common for corporate accounts (where the model of authorising payments and the way in which the corporate structure is transposed into systems access is significantly more complex than the models which are currently offered for personal customers) and where there may be limits on the types of amounts of payments that can be made by particular signatories;

(iii) consent in the context of Article 65 - confirmation on the availability of funds requirement in relation to card-based payment instrument issuers; and

(iv) the treatment of vulnerable customers, Powers of Attorney, carers and customers with disabilities using these services. Do special considerations apply to demonstrate they have given consent with proper authority?

We note that proof of authorisation will be a key issue in disputed transactions. It is not clear to what extent an ASPSP could place reliance on SCA as a means of determining that customer consent has been given and build this mechanism into terms and conditions.

17.3.6 Clarity is required from the UK authorities as to the interaction between PSD2 and the General Data Protection Regulation (GDPR) in terms of data exchange and the ‘consent’ model. PSD2 Article 94 states that a PSP cannot access, process or retain any personal information for the provision of payment services unless it has the explicit consent of the payment service user to do so. This would seem to imply that PSPs will also have to obtain explicit consent from payment service users. This provision sits largely in isolation and could be interpreted to have a very wide application. Once GDPR comes into force, will PSPs have to ensure that the consent obtained is compliant with the requirements determined by GDPR? GDPR sets a high standard for consent and prescriptive standards which must be met for consent to be valid15. The GDPR consent requirements are such that in most cases firms should not be making consent a pre-condition for the receipt of a service. Article 97 seems to conflict with this intention as it is requiring consent on a mandatory basis before personal data can be processing in connection with the provision of payment services.

17.3.7 If PSPs are required to obtain specific consent for each processing activity and this consent can be withdrawn at any time, this will create significant issues for PSPs. It would appear that this consent requirement applies to all payment services and also calls into question whether an ASPSP should be obtaining explicit customer consent before releasing any information to an AISP, PISP or PII. Although sensitive payment data should

15 This will include:

• Explicit consent requires a very clear and specific statement of consent which must be kept separate from other terms and conditions

• Granular consent must be obtained for distinct processing operations • Consent must be actively given, the indication of consent must be unambiguous and involve clear affirmative

action (no pre ticked boxes or statements confirming consent has been granted without any affirmative action by the individual)

• Evidence that consent has been obtained as well as telling the payment service user how to withdraw their consent.

• Avoid making consent a pre-condition of service.

Page 31 MEMBER CIRCULATION

not be released, it is likely that the information shared will still consist of customer personal data.

17.4 Authentication

17.4.1 We had significant concerns about the draft EBA regulatory technical standards (RTS) on strong customer authentication and secure communication, which we set out in detail in our response to the EBA consultation in October 2016. The delayed submission to the European Commission of the final draft RTS means that the requirements with which PSPs will be required to comply are still not certain, which constitutes a further risk to PSPs’ implementation plans and ability to comply with the timescales set by both PSD2 (18 months from the date of adoption of the RTS and their subsequent entry into force) and the earlier deadline set by CMA remedy (full read/write capability by January 2018).

17.4.2 We support the view documented in point 6.18 of the consultation that “best practice is expected to involve customers authenticating themselves directly with their ASPSP, i.e. providing their login details only to their ASPSP, rather than the AISP or PISP, with confirmation then provided by the ASPSP back to the AISP or PISP”. This is, in our view, the best procedure to mitigate the risk of fraud. We believe Open Banking is currently modelling for this as an option. However, we are also aware that debate continues at a European level over the meaning of PSD2 Recital 32, where it states that an ASPSP “which provides a mechanism for indirect access should also allow direct access for the PISPs” and Recital 93, which refers to having a clear legal framework under which PISPs and AISPs can provide their services “without being required by the [ASPSP] to use a particular business model, whether based on direct or indirect access”.

17.4.3 It is our understanding that the adoption of an Open Banking derived solution as a means to comply with the TPP-related PSD2 provisions is a market choice and cannot be enforced on ASPSPs or on AISPs and PISPs, including those which currently rely on or choose to operate a different access approach e.g. utilising the PSU’s personalised security credentials, especially during the ‘gap’ between January 2018 and application of the RTS (at the earliest Q4 2018 but possibly not until 2019). There is also a risk that customers will experience two changes to the authentication regime.

17.4.4 In point 6.19 the government sets out its expectations regarding access to information by an AISP on both a one-off and ongoing basis, “subject to the RTS”. The original draft RTS were proposing that AISPs should be able to request information from payment accounts no more than twice a day when the PSU was not actively requesting such information. We argued in our response to the consultation that such a limit would potentially restrict AISPs’ propositions. We note that the final draft RTS now state in RTS Article 31(5) that AISPs “shall be able to access information…where the payment service user is not actively requesting such information, no more than four times in a 24 hour period, unless a higher frequency is agreed between the account information service provider and the account servicing payment service provider, with the payment service user’s consent”. As AISPs will download data periodically, there is an implication that they will need to store data at least until the next time the PSU accesses it. Consideration will need to be given to how

Page 32 MEMBER CIRCULATION

long this data may be stored and its security. Guidelines on data retention will be required. Alternatively it may be argued that this is a matter for the AISP/PSU contract.

17.4.5 We also noted in our RTS consultation response that the volume of information exchanged can affect system efficiency and availability, not just the number of information requests. In connection with this latter point we support the additional assertion in point 6.19 that says “ASPSPs are expected to allow for regular communication sessions with the AISP, but not necessarily to provide an uninterrupted data stream”. We would also highlight the need to allow ASPSPs some leeway to accommodate IT changes and upgrades as is the case where a PSU is accessing information directly (a point which is acknowledged later in the consultation document in 6.32).

17.4.6 We support the statement in point 6.20 that “the government expects the initiation of transactions through a PISP to require authentication each time a payment is initiated” whilst noting the caveat that this is “subject to the RTS”.

17.4.7 Section 6 of the consultation document focuses on PIS and AIS and makes no mention of the requirements in relation to PSD2 Article 65 (regulation 68) concerning provision of confirmation of availability of funds to card-based payment instrument issuers, which is similarly reliant upon the EBA RTS on strong customer authentication and secure communication. There is only a brief mention in point 5.8(3). We are interested to understand the authorities’ assessment of the implementation impact on PSPs and the expected demand for this service from a UK perspective. We assume that an API could be used to provide the secure communication mechanism between the card-based payment instrument issuer and the ASPSP.

17.4.8 We would also welcome clarification regarding whether the requirements in relation to PSD Article 65 (draft regulation 68) will come fully into force on 13 January 2018. It is noted that, unlike a payment initiation service or account information service, the requirement for an ASPSP to respond to a third party request to confirm availability of funds is conditional on the third party authenticating itself and communicating securely in accordance with the EBA RTS on authentication and secure communication. As the EBA RTS will not be in force on 13 January 2018, it is unclear as to how these conditions could be met.

17.5 Communication

17.5.1 Whilst the proposed model of a PSU providing their payment account login details only to the ASPSP as part of a TPP service is broadly agreed upon, clarity is required as to exactly what information the AISP or PISP captures from the PSU and provides to the ASPSP.

17.5.2 According to point 6.21 the EBA RTS on SCA and secure communication “will set out further details on the requirements for any communication between AISPs/PISPs and ASPSPs” (although third party card-based payment instrument issuers should also be

Page 33 MEMBER CIRCULATION

mentioned). We are concerned that there is too much reliance on the EBA RTS, which leave a number of practical issues unclear. For example: • What enrolment processes will TPPs adopt and what information will the TPP capture

from the PSU and provide to the ASPSP? Ideally there should be a structured and agreed approach to ensure this is included as part of the communication standards, albeit that this is entirely for the TPP to decide and not in the remit of the ASPSP.

• How will ASPSPs be able to check the authorisation registers of all member states? We need an online register that is updated in real time in order to check whether the party requesting access is properly authorised or registered.

It would be helpful if the UK authorities (via the regulations or approach) could provide further clarity or guidance where this is lacking in the PSD2 text or the EBA RTS.

18 QUESTION 18: Do you agree with the information and payment functionality that will be available to AISPs and PISPs?

18.1 Accessible online

18.1.1 The term “accessible online” is used in PSD2 Articles 61(1)(a), 66(1) and 67(1) and the equivalent draft regulations 68(5)(a), 69(1) and 70(1) but is not defined. To date we have tended to take the view (based on the reference in PSD2 Recital 93) that “accessible online” means the use of all common types of devices (e.g. computers, tablets and mobile phones, including apps). Our understanding is also that if a PSU has not chosen to access its payment account online, the PSU’s payment account would not be automatically accessible by a TPP until that situation changed. This interpretation would seem to be in line with the description in point 6.22 of the consultation, which refers to “any [payment] account which is accessible by the user on the internet through any device, including a computer, a mobile phone, or an application on a mobile phone”.

18.1.2 It should also be understood that the services available to the PSU via e.g. an online banking portal will vary from ASPSP to ASPSP. In addition, in the context of corporate usage, certain activities available via a traditional online banking application would not necessarily be accessible via the ‘mobile’ application, which may provide full reporting capabilities but only limited payment initiation functionality. Some banking systems that allow machine-to-machine communication to our mind should not be regarded as an online account or accessing the account online and we elaborate further on this in our response to question 20. Additionally, retail customers often have access to different applications that offer varying levels of access, for example in making payments to new beneficiaries.

18.1.3 Our understanding is that if an ASPSP does not offer online account services to its customers, then it would not have to be open to third party access although it may choose to do so e.g. for commercial reasons or in response to demand from its customers. So if a payment account is not made accessible online to the ASPSP’s customers today, the account does not have to be accessible to third parties. Similarly, where certain online account services are not already offered to the PSU, ASPSPs need not build these functionalities to accommodate third party access. Confirmation in this regard would be helpful.

Page 34 MEMBER CIRCULATION

18.2 Payment account

18.2.1 We have always assumed that the FCA’s current interpretation of “payment account” as it applies under PSD1 - and as described in the FCA Perimeter Guidance (Chapter 15.3) - would continue to apply to PSD2. The description in point 6.23 reflects the same view.

18.2.2 We accept that credit cards are deemed to be payment accounts under the PSRs2 as they are under the current PSRs. We understand that this is not an interpretation that most other member states apply today. We believe it would be helpful to have further clarification as to whether credit cards are in scope for PIS as well as AIS. We see this hinging on the interpretation of payer instructed transactions from accounts which are “accessible online”. In general, we have assumed that third party access will be restricted to AIS only in most cases.

18.2.3 The functionality that some (but not all) credit card issuers may offer for payer-initiated transactions via an online account, tends to be limited to balance transfers (where the customer effectively uses part of their credit limit to pay off a credit card with another provider) or money transfers (generating a payment to a payment account instructed by the cardholder e.g. to pay off loans). These transactions are generally a mechanism for customers to access promotional offers – which are not available to all customers all of the time and they will have specific conditions such as a fee, an interest rate and a length of time during which the offer is valid - which are intended to promote account switching. This feature of the credit card market has encouraged competition and a high level of switching (15% of balances are moved in this way annually). It would be unfortunate if this pro-competitive aspect of the market was adversely impacted as a result of bringing this activity into the scope of PIS.

18.2.4 All other card payments are payee (retailer) initiated, using the card-based payment instrument itself. We would consider that card-based payments are not accessible online, and therefore the only payment mechanism that should be available to a PISP would be a balance transfer and/or money transfer where this is an online service directly available to the PSU to instruct these payments. However, it is important to note that balance transfer and money transfer requests typically attract a fee imposed by the ASPSP. Considerable effort has been made by the industry to provide customers using these services with information about fees, the duration of offers and the contractual obligations that customers need to meet in order to qualify for the offer. Indeed the industry has agreed voluntarily measures in response to the FCA Credit Card Market Study to introduce improved mechanisms to provide cardholders with information on expiry of offers. It is difficult to see how a PISP could provide a comparable level of information on fees and charges.

18.2.5 In our view, notwithstanding any potential legal interpretation, the payment mechanisms in question are niche and not “accessible online” in any conventional sense and including them with the scope of PIS access is likely to result in poor consumer propositions.

Page 35 MEMBER CIRCULATION

18.2.6 In the event that balance transfers and/or money transfers are deemed to be included within the scope of PIS, for credit cards there would be significant inconsistency regarding whether a PISP would have any liability for unauthorised transactions. Draft regulation 64(3) provides that draft regulation 76(5) will not apply to a payment service which is provided in relation to funds covered by a credit line under an agreement regulated by the Consumer Credit Act 1974 (CCA). CCA does not envisage transactions being authorised by any party other than the customer or their agent. As a result either the ASPSP or the customer could pick up the liability for a payment which was unauthorised or incorrectly authorised due to a deficiency in the service provided by the PISP.

18.2.7 We do not believe that charge cards are explicitly mentioned in the FCA PERG Chapter 15.3 and it would be useful to understand the UK authorities’ expectations in this regard. Charge cards work very similarly to credit cards – the chief difference being that a charge card must be paid off at the end of the month, whereas a credit card balance can be rolled over to the following month. We think it is probably even less likely that charge cards would have ‘online usable’ features such as balance or money transfers, so would be even less likely than credit cards to be caught by the PIS provisions.

18.2.8 Point 6.24 of the consultation rightly observes that the types of accounts in scope of PSD2 and the PSRs2 are far broader than those captured by the CMA remedy, which is restricted to personal and business current accounts. Our understanding is that currency current accounts would also fall into the definition of a payment account in the context of PIS and AIS, reflecting the expansion of scope of PSD2 to include all currencies, not just those of EU member states. However, it should be noted that the CMA Open Banking remedy only applies to UK Sterling current accounts.

18.3 Account information service access

18.3.1 Point 6.25 argues that the information an AISP should be able to access is “the same information regarding a payment account as is available to the user when accessing their account online directly with the ASPSP”. We note that similar wording is used in the final draft EBA RTS in RTS Article 31 concerning data exchanges, which refers to providing AISPs “with the same information from designated payment accounts and associated payment transactions made available to the payment service user when directly requesting access to the account information, provided that this information does not include sensitive payment data”. The PSD2 text itself – in Article 67(2)(d) and (e) requires the AISP to “access only the information from designated payment accounts and associated payment transactions” and “not to request sensitive payment data linked to the payment accounts”. In addition, PSD2 Article 67(1)(f) obliges the AISP “not to use, access or store any data for purposes other than for performing the account information service explicitly requested by the PSU, in accordance with data protection rules”.

18.3.2 We take this to mean that that if a PSU can access information about non-payment accounts (e.g. savings, mortgage or loan accounts) the AISP cannot request it and the ASPSP is under no obligation to make available such information to the AISP under PSD2/PSRs2 although it would be free to do, with the PSU’s consent, under a bilateral

Page 36 MEMBER CIRCULATION

agreement with the AISP and outside the scope of the PSD2/PSRs’ provisions. We also would not expect AISPs to have access to any account information overlay services which an ASPSP may itself provide online for its PSUs. Otherwise it could operate as a disincentive to ASPSPs to develop and expand their online services, thereby reducing innovation and competition. We assume the reference to “transaction data” in point 6.25 of the consultation refers to transactional data presented to the customer in online banking and not to copies of correspondence sent to the customer that may be accessible via online banking.

18.3.3 PSD2 Article 67(2)(e) states that the AISP shall “not request sensitive payment data linked to the payment accounts”. Thus we assume that the information to be shared would be minus any sensitive payment data, although we have previously noted (in our comments under 1.7.1) the possible transposition error in draft regulation 70(3)(3), which states that an AISP must simply “not store sensitive payment data linked to the payment accounts accessed”. However, there remains a lack of clarity as to what falls into the scope of the definition of “sensitive payment data16” and, conversely, what is “non-sensitive payment data”. Clarification is urgently required at both a domestic and European level in this regard. For example, according to investigations by the EPC Payment Security Support Group dating from Q3 2015, member states may have different interpretations with respect to sensitive data while legal precedence over PSD2 with regard to some data elements may exist in certain countries. We understand that according to the French Monetary and Financial Code, the name of the account owner and the account number are deemed to be sensitive data that need to be protected. We have included some additional comments regarding the possible scope of information available to PISPs and AISPs later in our response to question 18.

18.3.4 In addition, we would stress that the extent of information to be shared with the AISP is also subject to the PSU’s explicit consent in line with PSD2 Article 67(2)(a).

18.3.5 Point 6.25 of the consultation document also sets out examples of types of account information an ASPSP might be expected to provide to an AISP (subject to the PSU’s explicit consent). We would comment as follows:

• “account information, such as name on the account, address of the account holder,

account number” – this should be clearly defined and kept to an appropriate level because there is a risk of scope creep to provide more customer information, e.g. number and amount of direct debits and standing orders. We suggest the authorities undertake a fraud assessment to ensure that release of such information is unlikely to increase the risk of fraud. We strongly disagree that certain customer personal information, like address, should be available to third parties and see this as sensitive data.

• “product details, such as the product type, interest rate when in credit, overdraft amount,

interest rate when overdrawn” – draws the scope of the product details very widely and

16 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 payment initiation service providers and account information service providers, the name of the account owner and the account number do not constitute sensitive payment data”.

Page 37 MEMBER CIRCULATION

should not automatically be seen as in scope of the PSD2 provisions. Many of these elements would not necessarily be available through online banking. There is a blurring, here and elsewhere, of the PSD2 and Open Banking/API Standard requirements, which appears to be gold-plating. While we support the view as stated in point 6.7 of the consultation that the Open Banking API Standard “will need to align” with PSD2, it is important to be clear which requirements emanate from PSD2 and which arise from the CMA remedy, given the different legal basis, mandated entities and enforcement regimes.

• “transaction data to the same level of granularity and covering the same time periods as is

available to the end user online” – there is nothing in the legislative text that would imply that AISPs should expect the same information from all ASPSPs. HMT has usefully underlined the fact that the extent of data an individual ASPSP may enable its customers to access online is a competitive issue, which will therefore vary from ASPSP to ASPSP and also from customer segment to customer segment. We see that in the feedback table issued alongside the final draft of the RTS on SCA and secure communication, the EBA’s analysis of comment 210 (in relation to a question about what information is included in the data exchange) notes that “ASPSPs will have different online platforms for their PSUs, with potentially different information, and based on PSD2 not harmonising the information, the RTS can only require that if the ASPSP provides a dedicated interface the information should be ‘the same information’ as what would be available under the customer online interface”;

18.3.6 PSD2 makes it clear that AISPs are only permitted to request non-sensitive payment data. To understand the scope of data that this might encompass, we note that: • The definition of “sensitive payment data” in PSD2 Article 4(32) includes the statement

that “For the activities of payment initiation service providers and account information service providers, the name of the account owner and the account number do not constitute sensitive payment data”.

• RTS Article 10 appears to indicate that non-sensitive “payment account information” comprises: “(a) the balance of one or more designated payment accounts; (b) the payment transactions executed in the last 90 days through one or more designated payment accounts”.

Consequently, it would appear that non-sensitive payment data would at the very least include name, account number, current balance and payment transactions executed in the last 90 days.

18.4 Payment initiation service access

18.4.1 Point 6.26 in the consultation includes a clear statement that “ASPSPs are expected to provide to a PISP access to the same functionality that is available to the user when accessing their payment account online directly with the ASPSP”. PSD2, in Article 66(4)(c), refers to ASPSPs treating payment orders from PISPs “without any discrimination other than for objective reasons, in particular in terms of timing, priority or charges vis-à-vis payment orders transmitted directly by the payee”. It does not place an explicit obligation on ASPSPs beyond that in terms of the functionality to be made available.

Page 38 MEMBER CIRCULATION

18.4.2 Our view is that ASPSPs can only be required to execute those payment types which are currently offered to an individual PSU within the ASPSP’s existing business model. In other words, for example, an ASPSP is not under any obligation to offer SEPA Credit Transfer or SEPA Direct Debit payments just because of the PIS provisions in PSD2 (although it may be under a separate obligation to do so by virtue of the SEPA Regulation).

18.4.3 We agree that credit transfers are in scope. It would be helpful to have clarification that this could potentially include credit transfers made via Bacs as well as Faster Payments, CHAPS17, SEPA payments and other international transfers where these are available to the PSU.

18.4.4 Point 6.26 refers to “the establishment of standing orders” and we would like to understand whether this is limited to the creation of a standing order or does it mean PISPs should also be able to amend or cancel a standing order too?

18.4.5 We consider that the creation of standing orders is in scope if the online functionality is available to the PSU itself. We tend towards the view that the cancellation and amendment of a standing order would not fall within scope.

18.4.6 There is a distinction to be made between: (1) an arrangement that a PSU may enter into with a PISP for that PISP to initiate regular payments on their behalf (which may be e.g. by means of regular single immediate payments); and (2) a mandate to make regular payments (e.g. by way of a standing order lodged with a customer/PISP on their behalf with their ASPSP). The first is an arrangement between the PSU and the PISP and the second is a formal mandate to the ASPSP to make a payment.

18.4.7 We believe that a PISP should be able to initiate a series of standing order payments to the same beneficiary in one session in the same way that a PSU could. The mandate to make all standing order payments initiated by the PISP would be held by the ASPSP.

18.4.8 There is a need for clarification regarding whether authorisation is required each time the payment takes place. We would suggest that authorisation is given for the whole series of payments at the initial authorisation and, as such, authorisation is only required once throughout the lifetime of the (un-amended) standing order. If the payer instructs the PISP to make regular payments which are initiated by the PISP as a series of one-off payments, we would expect a separate authorisation for each payment.

18.4.9 Point 6.26 also appears to be indicating that the “establishment of direct debit mandates” would be out of scope of PIS if this is not a function already available to the PSU online. We note that the final draft EBA RTS on SCA and secure communication references, in point 13 of the rationale, refers to “a transaction where the payer’s consent for a direct debit transaction is given in the form of an electronic mandate with the involvement of its

17 We believe that very few (if any) consumers would have access to CHAPS via online banking.

Page 39 MEMBER CIRCULATION

PSP”. In the feedback table accompanying the final draft RTS, the EBA states a number of times that direct debits “are out of the scope of the requirement for SCA and therefore out of the scope of the RTS”. We would agree that direct debits should generally be seen as out of scope of the PIS provisions. Direct debits in the UK (and the pan-European euro SEPA Direct Debit schemes) are based on a creditor-driven mandate flow model. They are considered as ‘pull’ payments initiated by a business and are subject to scheme rules as well as completion of a mandate by the PSU. It would not seem logical to require all corporates who utilise direct debits to become authorised as PISPs and it seems that the government has reached a similar conclusion. The Direct Debit market in the UK already features very considerable third party support for payees e.g. Bacs bureaux. Thus there is a working market and PISPs that also aspire to facilitate DDs already have the means to join the market.

18.4.10 PSD2 Article 66(4)(b) requires “all information on the initiation” and “all information … regarding the execution of the payment transaction” to be provided or made available by the ASPSP to the PISP. We see from the feedback table issued alongside the final draft of the RTS on SCA and secure communication, the EBA’s analysis of comment 211 (in relation to concerns about information accessed by TPPs) states “PSD2 does not set an obligation to provide other information to the PISP, such as overdraft limits. As this is defined in PSD2, the RTS cannot reiterate the same in the RTS but the requirements of the RTS are to be understood in line with these PSD2 provisions. However, for the purpose of clarity, the EBA has added a recital 18”. RTS recital 18 indicates that “payment initiation service providers, payment service providers issuing card-based payment instruments and account information service providers will only seek and obtain the necessary and essential information from the account servicing payment service provider for the provision of a given payment service and only with the consent of the payment service user”. Accordingly we understand that the information to be made available in connection with PSD2 Article 66(4)(b) is limited to that which is “necessary and essential”.

19 QUESTION 19: Do you agree with the government’s interpretation of the definition of AIS and PIS?

19.1 We have articulated in our response to question 18 our views regarding the scope of PIS and have flagged areas where we have queries or feel that further clarification is required. Generally, we see payments in scope ultimately being all types of payment that can be made through online banking (including corporate online services) and available to the PSU online but we envisage there being a likely emphasis on Faster Payments in the UK, especially in the early days.

19.2 We find point 6.28 (which states that the “government interprets the definition of AIS as meaning that an AISP uses some or all of the information from one or more payment accounts held by the PSU with one or more ASPSPs, to provide an information service”) rather too vague. Please also refer to our comments in response to question 18.

Page 40 MEMBER CIRCULATION

19.3 In terms of the interpretation of AIS, we would see this as allowing consumers and businesses to obtain a consolidated view of their accounts and to use tools to analyse their transactions and spending patterns. This could be on an ongoing basis as part of a long term relationship between the PSU and the AISP. Alternatively, consent could be given for one-off access in order to enable, e.g. an affordability check to be carried out when applying for a mortgage or loan. Will the UK authorities provide any clarity regarding use of the information obtained? We would see the purpose being to make the data available to the PSU rather than taking the information and making it more generally available to other parties (albeit this could be done with separate PSU consent, falling outside the scope of AIS). Our current understanding is that, in the context of AIS, there would likely be a direct relationship between the AISP and the PSU.

19.4 Point 6.29 sets out possible types of services in scope of AIS such as “dashboard services”, “income and expenditure analysis” and expenditure-related alerts. We would see “price comparison and product identification services” as being more within scope of the CMA remedy rather than the PSD2 provisions. This is an area where the distinction between PSD2 and the scope of the CMA Open Banking remedy should be maintained, especially if it affects whether the service provider is or is not required to be authorised or registered under PSD2.

19.5 The focus of the list of services in point 6.29 appears to be geared very much towards consumers and small businesses.

20 QUESTION 20: What services are currently provided that you think may be brought into scope of the PSDII by the broad reading of the definition of AIS and PIS?

20.1 We see a risk of unintended consequences in applying a very broad and literal interpretation to the definitions of PIS and AIS. The intention of the European Commission underpinning PSD2 was to encourage and support innovation and competition in the provision of payment services, especially in the realm of ecommerce and the retail market. Another risk is that if the UK’s scope is set too broadly compared to the approach in other member states (going against the maximum harmonisation principle), it will hamper the provision of cross-border services, creating fragmentation and customer confusion.

20.2 Existing corporate functions like shared service centres, in-house banks and central treasury may appear on a literal level to provide third party services such aggregated account information or payment initiation. However, we believe these are likely to fall within the exclusions in PSD2 Article 3 such as Article 3(n) regarding parent and subsidiary undertakings and as described in PSD2 Recital 17.

20.3 At the HMT pre-consultation workshop held on 15 April 2016 questions were raised about the potential impact on accountancy or legal firms where certain services that such firms may provide (e.g. solicitors initiating payments as part of their conveyancing work) could conceivably fall within a very literal reading of the AIS and PIS definitions, as could services provided by credit reference agencies. We take the view that a pragmatic approach should be adopted by the UK authorities when considering whether particular services fall into or

Page 41 MEMBER CIRCULATION

outside scope of the PSD2 provisions, while taking care not to seek to extend the scope into services covered separately by the CMA remedy that may be provided by entities unregulated according to PSD2.

20.4 The European Commission itself has shown its willingness to take a pragmatic view. A broad reading of the PIS and AIS definitions led to questions being raised as to whether certain services provided by SWIFT (MT101 Request for Transfer and MT9XX services) should be considered in or out of scope. Following discussions between SWIFT and the European Commission we have been informed that the latter concluded such services should not be seen as in scope of PSD2. We understand this was based on the following reasoning: • In the PIS model envisaged by the Commission, it would expect the PISP to inform the

corporate immediately that the payment had been initiated in line with the wording in PSD2 Recital 29 which says: “PIS enable the PISP to provide comfort to a payee that the payment has been initiated…” In the Request to Transfer situation no such feedback message is provided. There is a contract between Bank A and Bank B and also between the corporate and Bank B. In a typical PIS scenario the corporate would use its credentials to initiate the payment with Bank B but this doesn’t happen with Request to Transfer.

• In terms of the ‘Customer Statement / MT940’ scenario, here the corporate uses Bank A to obtain a consolidated view of its accounts with other banks such as Bank B using e.g. MT940. However, Bank A does not access (“go into”) the corporate’s account with Bank B to obtain the information. Instead, Bank B provides the information to Bank A on an unsolicited basis but at a frequency agreed with the corporate rather than on a real-time basis. Here we understand that the Commission concluded that such services were out of scope as they are about receiving rather than accessing information and there was no proactivity on the part of Bank A.

20.5 A common theme for the activities which we think are not intended to be regulated as third party payment services is that they are provided by the third party under a formal mandate or agreement between the third party and the customer (such as a services agreement or a power of attorney) and the customer directly mandates or authorises its AS PSP to accept payment instructions or account access from the third party on this basis so that the role of the third party is already clearly known to and understood by the ASPSP. It seems to us that such criteria would be useful in excluding from the PIS and AIS definitions activities which were never intended to be caught by PSD2.

20.6 Certain Corporate Banking services should not be brought into scope of PIS and AIS. For example, Corporate Banks have the ability to aggregate account information and initiate payments, across one or many banks, on behalf of their clients. These services aim to actively manage the client’s balances and liquidity positions as well as make payments. These services usually use SWIFT messages (MT101, MT940, MT942 etc), but can use proprietary networks. These arrangements are usually governed by contracts clients have their respective banks. We believe that banks comply with strong authentication via the

Page 42 MEMBER CIRCULATION

security infrastructure of host-to-host connectivity18 where secure communication with encryption or corporate seal is part of a unique host-to-host connection set up between the corporate and the PSP. 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. Above the corporate seal level, personal digital signatures can also be applied and can enable a very complex set of user entitlements via the usage of a Signature Authorisation Matrix.

20.7 We do not think that the PIS and AIS provisions are intended to apply to a range of activities which could technically fall within the very broad definitions within the Directive such as activities connected with fund administration, transfer agency and portfolio and asset management for example. We think that certain investment activities19 should be subject to the same exclusion as that which applies under PSD1 to securities asset servicing20 in line with PSD2 Article 3(1).

20.8 We think that web portals are not providing a payment service where all they do is pass messages from the acquirer to the issuer, without ever holding funds or performing authorisations.

20.9 We are unclear about the position of commercial bureau/Bacs bureau and payroll companies and wonder whether they might fall within the ‘commercial agent’ exemption (Article 3 point (b) and Recital 11) or the technical services exemption (Article 3 point (j))?

21 QUESTION 21: Do you agree with this description of the rights and obligations for ASPSPs, AISPs and PISPs?

21.1 Rights of access

21.1.1 The wording in point 6.32 (which refers to “a user”) seems to be slightly at odds with that used in point 6.22 (where the reference is to “the user”). We would like to emphasise that the right for AISPs and PISPs to access a particular payment account applies only where the individual PSU has specifically activated an online access arrangement with its ASPSP thereby making the PSU’s payment account accessible online.

18 Albeit some members would argue that host-to-host type connections should be deemed to be exempt from the SCA requirements. 19 Transfer Agency, Corporate Trust Administrative Services, Account Administrator, Cash Administrator, Registrar and Cash Manager 20 In relation to PSD1, the FCA PERG chapter 15.5 addresses questions relating to negative scope/exclusions. In connection with Q37 it concludes that the objective is the payment service provided to specific clients and not the dealings among PSPs to deliver the end payment arising from that service. In addition (see Q38) PERG took the view that the regulations do not apply to securities assets servicing, including dividends, income or other distributions and redemption or sale.

Page 43 MEMBER CIRCULATION

21.1.2 Point 6.32 helpfully acknowledges that a 24x7 access principle nevertheless has to accommodate some leeway to take account of “scheduled maintenance or system failures”, which should not be seen as ASPSPs hindering access by PISPs and AISPs. In addition, as we have previously observed (in our response to question 17), the volume of information exchanged can affect system efficiency and availability, as well as the number of information requests. There is a risk that some AISPs will build apps that automatically call data either on a regular basis (e.g. hourly) or in real-time that will place additional pressures on ASPSPs systems so we believe some safeguards will need to be put in place while still ensuring that AISPs are able to deliver their services. For example, in extremis, if the level of requests from a particular AISP or PISP is threatening the performance of core banking systems, the ASPSP should have the right to throttle or rate-limit these requests. We note that the final draft EBA RTS (in RTS Article 31(5)) sets some high level parameters on the frequency of access.

21.1.3 Point 6.33 rightly highlights the fact that provision of access by ASPSPs comes with a (significant) cost and we note that the consultation document makes a clear statement that “ASPSPs only have to provide one mechanism”. We support this as a general principle as we have always thought that it would be unreasonable to expect all ASPSPs across Europe to support an unlimited number of PISP and AISP business models in different member states. As noted in our response to question 17, we remain unsure as to how this policy statement aligns with ongoing discussions at a European level where certain parties point to PSD2 Recital 32 and Recital 93 which imply that ASPSPs should provide mechanisms for both direct and indirect access, albeit these terms are not defined. Nevertheless it is helpful to have the UK government’s policy view clearly stated.

21.1.4 While the Open Banking API Standard may offer the best way of providing secure access (as stated to be the government’s view in point 6.33) it may not deliver sufficient functionality to enable full compliance with PSD2 from January 2018 and we understand that it may be necessary for ASPSPs to support alternative access options (e.g. use of credentials by the PISP or AISP or URL or other).

21.2 Consumer Protection

21.2.1 We agree that PSD2 does not provide the only legal framework and that provision of PIS and AIS will need to be compliant with other consumer and data protection legislation, as indicated in point 6.34 of the consultation.

21.3 Liability

21.3.1 We note that the consultation observes (in points 6.14 and 6.36) that “industry” is expected to “put in place suitable arrangements …[and] appropriate processes to manage liability …or dispute handling” and “to develop appropriate mechanisms so that ASPSPs can work effectively with PISPs”. This is a disappointing outcome. Without any particular body with the appropriate authority being mandated to take this responsibility it leaves liability sitting with the ASPSPs who have limited and uncertain recourse and does not provide any support or clarity for third parties.

Page 44 MEMBER CIRCULATION

21.3.2 We think government or FCA should issue guidance on how disputes between TPPs and ASPSPs should be managed. In any event, further clarity is needed, particularly in connection with the following provisions:

• PSD2 Articles 73 and 90 indicate that the ASPSP shall be responsible for refunding the payer and seek recourse from the PISP for the “losses incurred or sums paid” (which we assume means it is necessarily limited to the refunded payment amount) as a result of the refund to the payer. How are ASPSPs expected to obtain immediate refunds from third parties, especially in the absence of a contract and involving parties who may have only limited capital?

• How is liability to be proven? PSD2 Article 72 indicates that the burden of proof falls to the PISP to prove it was not at fault. We believe guidance issued by Government or the FCA would be very helpful in bringing clarity over what should be expected. If this is not possible, an alternative would be to task an appropriate body to set out best practice guidelines.

• The liability model in relation to provision of AIS has not been articulated in the PSD2 text. Beyond data protection law, there is no customer protection for third party data loss or hacking.

21.3.3 In addition, it should be recognised that any “suitable arrangements” that are put in place will need to work across Europe and cannot be developed by the UK industry on its own. While we understand that from a UK perspective Open Banking is looking to put something in place, this does not cover the scope of PSD2 (see our response to question 17). We therefore suggest that HMT discusses the design of the long term governance of Open Banking in order to achieve the best outcomes for the wider market implementation of PSD2 TPP-related provisions in an economically sustainable manner. We would advocate that the work to consolidate the retail PSOs, sponsored by the BoE and PSR, would seem relevant to this longer term undertaking.

21.4 At a European level the Euro Retail Payments Board has recently established a Payment Initiation Services Working Group with three underlying work streams, one of which is due to consider what are termed “other operational and technical matters”. The outline deliverables for this work stream include reference to, for example, testing, a technical helpdesk and processing of error messages for error handling and/or post-transaction dispute handling. However, it is currently unclear the extent to which this initiative will lead to concrete outputs or be limited to setting out some high level principles or recommendations.

22 QUESTION 22: Do you have any comments on the initial period of implementation, before the EBA RTSs are fully in force?

22.1 The initial period of implementation, before the EBA RTS are fully in force, gives us a number of serious concerns. We are surprised that HMT’s consultation document does not mention PSD2 Article 115 which gives a right to pre-existing TPPs to continue their business from January 2018 at least until the RTS is implemented. We see this as an important vehicle for PSD2 compliance, albeit there are some significant issues to resolve around if and how TPPs and ASPSPs identify each other and for mitigation of associated liabilities that may arise. As mentioned elsewhere in our response, the registers that member states

Page 45 MEMBER CIRCULATION

and the EBA are required to deliver are important elements of the operating model for checking the authorisation and registration status of PISPs, AISPs and also ASPSPs so the national and European authorities will also have a role to play in ensuring that their own services are available in time and enabled to support a 24x7, automated environment.

22.2 On the back of the Open Banking API Standard it may be possible to offer some API services in January 2018 but this will depend upon the extent of alignment with PSD2. The EBA RTS are not expected to enter into force until summer 2017, following which PSPs have 18 months to implement the requirements according to the PSD2 text, which would mean that the EBA RTS would apply at the earliest from late 2018. However, recent intelligence indicates that the European Commission and the ECB remain unhappy with the submitted final draft of the RTS and we have heard anecdotally that the Commission is planning to use the full extent of its ‘consideration period’ to analyse, possibly change or even reject the RTS as they currently stand. This would push the timescales out to possible approval in autumn 2017, which would mean that the RTS may not apply until April 2019.

22.3 Implementing the RTS by January 2018 instead would therefore be extremely challenging if not completely impossible. It is highly likely that the UK would be the only territory taking such an approach which complicates cross border activity. The whole UK community is exposed to the risk of significant re-work if PSPs have to ‘guess’ the RTS in say July to be ready for January and get it wrong, bearing in mind they also will need to be able to interoperate on a pan-European basis with implementations carried out in other member states, especially given that the RTS provide much of the detail concerning the security and the requirements of the different actors involved in provision of these new payment services.

22.4 Whilst we support the policy objectives of making more payment services data available as soon as is practicable, the UK authorities could theoretically consider deferring the delivery of the access to account provisions until the RTS apply. This would enable ASPSPs to focus on delivering a compliant solution with appropriate and standardised security and communication arrangements. We understand that the German legislator has already taken concerns around the timing mismatch between the application of the TPP-related provisions and the EBA RTS into consideration by bringing in line the effectiveness of the relevant sections of the German implementation act for PSD2 with regard to third party providers with the date of effectiveness of EBA RTS according to PSD2 Article 115(4).

22.5 There are other issues to be considered in connection with implementation timescales: (i) Reliance on third parties – for some crucial areas (such as 3D secure) to meet SCA

requirements, PSPs have to rely on third parties to provide the required functionality. Having an earlier implementation expectation might make meeting the requirements difficult where suppliers are unable to make required changes in time, leaving PSPs physically unable to comply as these products cannot be developed in house.

(ii) Specification availability – for PSPs in the UK affected by PSD2 but not by the CMA remedy Order on open banking, the lack of availability of specifications and ability to influence the process will cause additional pressure in terms of compliance. Later access to API specifications provides a much shorter implementation window to meet a January 2018 expectation compared to the PSPs who comprise the ‘CMA9’.

Page 46 MEMBER CIRCULATION

(iii) Consent model & consumer trust – the timeline also compresses the amount of time available to build a consent and liability model which PSUs can trust and that protects those PSUs. Although this is being developed by the CMA9, it is not being influenced by smaller institutions (or indeed larger institutions such as credit card only issuers) and therefore might not be right for PSUs who bank with a variety of different types of institutions and products, thereby eroding trust and decreasing the impact of the open banking effort.

22.6 We note the reference in 6.39 to the “learning process” that AISPs, PISPs and ASPSPs will undergo during this initial period of implementation. Additional guidance as to what is or is not permissible in terms of the interactions between ASPSPs and TPPs during this period would be welcome. We would envisage a phased implementation; some screen scraping (albeit this would be unlikely to work in a corporate or business context, given the complex authority levels and signing rights, etc.) and some API services would be available in January with a ramping up of more complex API based services thereafter and eventual phasing out of screen scraping in line with 6.33. It should be emphasised, however, that this learning phase is not without risk as a variety of potentially untried operating practices are adopted in an environment where rules and liability models are still developing. Fraudsters, seeking to steal customer data, may attempt to exploit the fact that processes and reliable sources for checking authorisation/registration status will still be under development. Disputes may be a common occurrence.

22.7 The EBA has publicly stated that, once it has submitted the final draft RTS on strong customer authentication and secure communication, it intends to give further consideration to the ‘gap’ between January 2018 when the majority of the PSD2 provisions apply and the as yet unknown date (expected to be late 2018 at the earliest) when the EBA RTS provisions apply. We would support an approach that gave clarity at a pan-European level, especially since the scope of PIS and AIS is also pan-European.