Input to Members of the European Parliament on the PSD2 RTS proposal covering banks obligations

Transcription

1 Input to Members of the European Parliament on the PSD2 RTS proposal covering banks obligations ESBG (European Savings and Retail Banking Group) Rue Marie-Thérèse, 11 - B-1000 Brussels ESBG Transparency Register ID October 2017

2 ESBG White Paper Input to Members of the European Parliament on the PSD2 RTS proposal and its relation to GDPR in respect of banks obligations 1. The issue: Finding the right equilibrium between security and privacy on the one hand and access to consumer data on the other hand a complicated balance between PSD2 and GDPR This White Paper aims to summarize certain challenges identified in the discussions concerning the Commission s current proposal, presented in May, for the Regulatory Technical Standard (RTS) on Strong Customer Authentication (SCA) and Common and Secure Communication (CSC) for the revised Payments Services Directive (PSD2). This paper also underlines the complicated relationship between PSD2 and the General Data Protection Regulation (GDPR), which if not considered jointly can potentially lower consumer protection, decrease the level of innovation and increase the risk of fraud and misuse. To reduce risks of cyber security, PSD2 requires strong customer authentication when making electronic payments and demands secure communication interfaces between banks and Third Party Providers (TPPs). However, if the Commission s RTS proposal from May is adopted, there will be new challenges, market confusion and an increase in risks for both consumers and operators, since their proposal allows for a form of upgraded screen scraping through the introduction of a fall-back option when the dedicated interface is not working properly. In the first Payments Services Directive, two objectives were security and consumer protection. However, PSD2 contains an additional objective concerning increased innovation and competition by introducing a level playing field through TPP access to customer accounts. If it had been seen as an acceptable option to compromise the first two objectives in favour of the latter it would not have been necessary to address legacy TPP access methods (i.e. screen scraping) in the directive. Without a proper balance between these objectives, ESBG cannot see a well-functioning implementation of the directive, and therefore, we have concerns that the Commission s proposed fall-back solution does not address the security requirements as set out in the directive. Additionally, several stakeholders have expressed their disagreement with this Commission proposal. For instance, the European Banking Authority (EBA), who in a recent Opinion 1 stated that the fallback solution increases cost, fragmentation compromising the development of APIs, provides a competitive disadvantage to new entrants, a lack of improved technical reliability, incompatibility with PSD2 s security requirements, supervisory constraints, and unclear consumer understanding and consent. Similarly, consumer organisations, including BEUC 2, stated to be against what is now denominated as screen scraping. The consumer would have to give the third party their security credentials while the third party would have access to data which is not necessary for the service it is providing. In fact, in their February RTS proposal, the EBA effectively prohibited screen scraping and instead mandated the use of a dedicated interface, or Application Programming Interface (API), for the communication between the TPP and the bank. This position was welcomed by the banking industry despite the substantial investments required in these new interfaces. ESBG believes that the EBA in their RTS has achieved a fair compromise amongst the objectives in the directive, which is also possible to implement in practice, as these dedicated interfaces would especially serve the interest of consumers. 1 Op %29.pdf 2 2

3 In addition, the GDPR empowers the customer to control or restrict the information accessed by such third parties through the requirement that whoever manages personal information must receive customer or owner consent before revealing such data to third parties. The method proposed in the EBA RTS proposal requiring banks and other payment service providers to have dedicated interface solutions in place caters for such required sensitive personal information handling. This would also maintain a high level of customer protection while at the same time allowing all third parties, including TPPs, to access the payment account in line with both GDPR and PSD2. Given the points raised by the EBA in their RTS proposal, data protection equals a high level of consumer protection, and a fair balance needs to be sought. This was also raised by VP Dombrovskis in his Eurofi speech 3. The ESBG believes that with its RTS proposal the EBA has also achieved a practical compromise between the objectives in both PSD2 and GDPR. Therefore, ESBG is calling upon the Members of the European Parliament to take the interests of consumers and industry participants into account when judging the Commission s proposed RTS. 2. Screen Scraping vs. Application Programming Interface Today, TPPs mainly rely on screen scraping technology to gain access to the information held by a bank. Screen scraping is when a customer is required to provide their bank account credentials when using a TPP application, e.g. an accounts aggregator or a payment initiator. The TPP accesses the client s account through the respective customer interface (the internet bank) by logging in with the customers credentials and collects or scrapes the data. This practice is called screen scraping (see top layer in the picture on the next page). The aim of PSD2 is inter alia to regulate access to consumer accounts in a secure way. There are numerous issues to take into account in practice, such as: These providers are not regulated at all and are in fact impersonating the customers vis-à-vis the banks by requesting customers to hand over their security credentials although most banking terms and conditions prohibit customers to do so; and These providers, in fact, after logging on with the customer credentials, have access to essentially the same data a customer sees when he or she logs in to his or her internet bank; this includes data such as the customer s current and savings accounts, insurance, loans or mortgages taken out, investment and credit card accounts, joint current accounts and accounts on which the customer has a mandate. This would in almost every case include sensitive payment data. This access may also include accounts of children, parents, companies, associations and products such as pension accounts and all their related balances. Contrary to what data protection rules require, the providers would receive this access without the bank having the opportunity to ask for customer consent or to safeguard that consent was given beforehand. Due to the third-party uses of the consumers own security credentials, banks today cannot distinguish the third party providers from the customer. If the TPPs instead access clients data and services via dedicated interfaces (i.e. APIs), and not through the client s interface (i.e. screen scraping), they would need to clearly identify themselves and the bank could ensure that the TPP has been authorized by the competent authority. This would also enable banks to understand what data the TPP is mandated to access by the user (or regulation) thus strengthening the customer s ability to control which data is to be shared

4 Screen scraping prevents the customer from controlling or limiting the information accessed by a TPP. It is also difficult for a bank to track to whom the client s data is forwarded and what data is mandated by the user to access. Both are legal requirements in PSD2 that the bank needs to adhere to, and these will also be valid requirements under the GDPR from 25 May Additionally, APIs can be based around proven global standards. Banking communities are already at work developing these APIs. The industry is betting on these APIs to help the whole industry move forward, avoiding the creation of a different API by each bank and thus preventing TPPs from having to connect their user interfaces to APIs with diverse setups. This makes it even more pressing that policymakers should forego introducing exemptions and placing banks and consumers at risk just for the sake of a limited number of legacy players. In this way, a level playing field can be maintained. In its latest proposal, the European Commission seems to have instead decided to re-open the door to some form of upgraded screen scraping through the introduction of a fall-back option for cases in which the dedicated interface is not working properly. Under this proposal, banks would need to build three parallel interfaces instead of one (see diagram below). A clear missing ban of screen scraping could provide a wrong incentive to TPPs, and also banks, not to invest in a dedicated interface which at the end is contrary to the objectives of the PSD2 and GDPR. Additionally, it is not clear who would decide whether the dedicated interface is working properly or not, as this cannot reasonably be left fully in the hands of one party (the TPPs). 3. GDPR and PSD2 The method proposed in the PSD2 RTS proposal from the EBA, requiring banks and other payment service providers to have efficient dedicated interface solutions in place caters for such required 4

5 personal information handling. This would also maintain a high level of customer protection while at the same time allowing all third parties, including TPPs, to access the payment account in compliance with both GDPR and PSD2. GDPR requires that whoever manages personal information must receive customer or owner consent before revealing such data to third parties, empowering the customer to control or restrict the information accessed by such third parties. In the banking environment, this pertains to the account holder. However, we believe that the word consent is not used in a consistent manner between PSD2 and GDPR. The consent mentioned in PSD2: Art 94.2: Payment service providers shall only access, process and retain personal data necessary for the provision of their payment services, with the explicit consent of the payment service user is assumed to be different from the consent used in GDPR: Art 6.1.a: Processing shall be lawful only if and to the extent that at least one of the following applies: (a) the data subject has given consent to the processing of his or her personal data for one or more specific purposes. Our belief is that, for payment initiation, consent relates first to consent to access the customer s payment account, subsequently consent to execute a payment (a specific amount from a specific account to a specific beneficiary) and finally consent to hold data related to the specific payment transaction. The access and the execution are here ancillary to the primary consent related to the holding of the data. Therefore, clarification is required on such aspects. In addition, GDPR is a Regulation and PSD2 is a Directive, and different Competent Authorities in each Member State handle both; and that PSD2 compliance does not imply GDPR compliance. In addition, PSD2 does not point to GDPR (as PSD2 did not exist when GDPR was negotiated) and potential fines under GDPR can be significant for banks. Therefore, a coherent application of the relevant provisions of the different pieces of legislation is required, especially between GDPR and PSD2. 4. Concerns related to data As expressed by the European Parliament 4, many FinTech developments are directly based on the innovative use of data. However, the current EU-legal framework on data is quite complicated, with several overlapping pieces of legislation. Hence, to avoid putting European FinTech actors at a competitive disadvantage, it is necessary to ensure a coherent application of the relevant provisions of the different pieces of legislation in place, such as the GDPR, PSD2, AMLD4 and the NIS Directive. In the Report, the European Parliament rightfully calls upon the Commission to take into consideration both the trends of higher data collection and use and remote verification, as well as the related risks, in particular with regard to the GDPR and the PSD2 and Know-Your-Customer rules, so as to allow for better access for consumers to cross-border FinTech services; this emphasises that data protection measures must be put in place and that consumers should be given a choice in how data is used and collected, in line with the GDPR. 4 European Parliament Report on FinTech: the influence of technology on the future of the financial sector (2016/2243(INI)) 5

6 About ESBG (European Savings and Retail Banking Group) ESBG The Voice of Savings and Retail Banking in Europe ESBG brings together nearly 1000 savings and retail banks in 20 European countries that believe in a common identity for European policies. ESBG members represent one of the largest European retail banking networks, comprising one-third of the retail banking market in Europe, with 190 million customers, more than 60,000 outlets, total assets of 7.1 trillion, non-bank deposits of 3.5 trillion, and non-bank loans of 3.7 trillion. ESBG members come together to agree on and promote common positions on relevant regulatory or supervisory matters. European Savings and Retail Banking Group aisbl Rue Marie-Thérèse, 11 B-1000 Brussels Tel: Fax : Info@wsbi-esbg.org Published by ESBG. October