FPF & VUB Roundtable – Banking on Personal Data
Authors: Caroline Hopland, Ine van Zeeland, and Rob van Eijk
FPF & Vrije Universiteit Brussel: Banking on Personal Data
Last week, Future of Privacy Forum (FPF) and Vrije Universiteit Brussel (VUB) hosted a roundtable on open banking. Twenty subject-matter experts discussed some of the main challenges in banking and data protection law: consent and its various interpretations, (re)use and sharing of personal data, and interoperability. The European Data Protection Board (EDPB) has begun to address whether the unresolved questions can be answered. Aspects of these issues were highlighted in the roundtable.
In terms of next steps, FPF and VUB will turn to engaging and understanding how the EDPB has set out the path forward with another round of discussions in mid-September. The next question is: to what extent can insightful use cases from other parts of the world serve as an inspiration to European banks, regulators, and watchdog groups?
Open Banking: EDPB guidance
The EDPB released, on July 17, 2020, their Guidelines 06/2020 on the interplay of the Second Payment Services Directive (PSD2) and the General Data Protection Regulation (GDPR) – version for public consultation. While transaction information is increasingly digitized and banks are announcing data sharing agreements with ever more external parties, the European Commission plans to announce a new digital finance strategy, in a continued effort to ‘open up’ banking. Experts in the industry, however, warn that there still are many unresolved questions when it comes to banks sharing data with third parties.
To consumers, the situation appears complex. They tend to hold banks accountable whenever something goes wrong, as these are the familiar parties to them. Roundtable participants from South Africa and Israel confirmed this was the case in their countries as well: criticism for malpractices at fintechs is still directed at banks. Government authorities or regulators could perhaps play a role in improving trust among the wider public. For instance, in the UK there is a dispute management system for disagreements between banks and third parties; this could be offered to consumers as well. As it is, consumers whose rights have been breached can only go to court, which is a high threshold for many. When it comes to data breaches, it would also be in the interest of fintechs to have clarity on liabilities in order to take out adequate insurance.
The difference between consent under PSD2 & the GDPR
The first presenter discussed the difference between consent under PSD2, the European directive regarding digital payment services, and the GDPR, in various banking situations.
They explained that PSD2 sets out rules concerning:
– Strict security requirements for electronic payments and the protection of financial data of Payment Service User (PSU), guaranteeing safe authentication and reducing the risk of fraud;
– The transparency of conditions and information requirements for payment services; and
– The rights and obligations of PSUs and providers of payment services.
They stated that the GDPR, however, generally focuses on strengthening the rights of the data subjects and sanctioning any violation of data subject rights. Both PSD2 and the GDPR set standards with respect to the safe-keeping of personal data and information provision to PSU (respectively, data subjects under the GDPR, when the PSUs are individuals). A Third Party Provider (TPP) must comply with both PSD2 and GDPR but, where one regulation is silent and the other regulation restricts processing of personal data, the protection of personal data shall prevail, (e.g., for the processing of special categories of data, apply Article 9 of the GDPR). Additionally, the processing of sensitive personal data, like health data, is prohibited unless one of the exemption clauses set out in Article 9, section 2 of the GDPR applies.
As for consent, the ‘explicit consent’ prongs within Article 94 of the PSD2 should be seen as an additional safeguard to ensure the consumer fully consents and understands the contract. However, PSD2 consent for the parameters of the interaction with the financial institution and GDPR consent for personal data processing should not be conflated. The presenter also touched upon Germany’s pragmatic approach, where consent of a PSU under Article 64 of the PSD2 (‘authorization’) also includes the explicit consent for data processing.
The presenter described the roles and responsibilities of a TPP & an Account Servicing Payment Service Provider (ASPSP) under PSD2 and GDPR with respect to their responsibility for safeguarding personal data during data transfer. The ASPSP must comply with Articles 66(1), (4), 67(1), (3) of the PSD2, and transfer of client data is justified according to Article 6 (1)(c) of the GDPR (providing a legal obligation). Once the TPP obtains access to a consumer’s data, it assumes its own responsibility with respect to processing personal data. If an interface from a bank complies with the Regulatory Technical Standards (RTS) on Strong Customer Authentication and Common and Secure Communication, then the data flow will be secured. The TPP must then explore any technical solutions in order to exclude certain categories of data that are not needed. This is an open issue right now and has not yet been solved.
The first presenter mentioned: ‘Consent requires that information is clearly provided to the data subject. The data subject should know to whom the data flow is going, and to whom the data is being disclosed to. This should be as precise as possible. This is why we are trying to precisely describe the purpose, parties, and recipients of the data flow. Bottom line: Consent under PSD2 might be totally valid, but not valid under the GDPR.’
Data (Re)use
The second presenter further touched upon these issues and spoke about what they mean in practice. The second presenter said that, ‘the idea behind PSD2 is that it should allow for competitiveness in the market.’
They discussed the purpose limitation requirements under PSD2 and the GDPR. Articles 66 & 67 of the PSD2 specifies the purposes for which the data is processed, but the GDPR, by the rights afforded to data subjects, causes a bit of disparity. This is shown in the EDPB’s Guidelines, and therefore creates a dual approach depending on whether the PSU is a legal entity or not. Articles 5(1)(b) of the GDPR, and Articles 66(3)(g) and 67(2)(f) of the PSD2 set out the specified purposes for processing and are almost identical. PSD2 creates the first element of the GDPR’s ‘purpose limitation’ principle and specifies the purposes for which the data is processed.
They stated that the specified purposes in Article 66(2)(f) of the PSD2 limits the Payment Initiation Service Provider’s (PISP) processing to payment initiation services to:
– Initiate the payment order
– Instruction from PSU + ‘consent’
– Instruction to Account Servicing Payment Service Provider (ASPSP)
– Receive authorization from ASPSP;
While Article 66(3)(g) of the PSD2 limits the Account Information Service Provider’s (AISP) processing to account information services to:
Instruction from PSU + ‘consent’
– Access payment accounts held by PSU
– Receive authorization from the ASPSP
– Receive account information from ASPSP
– Display account information back to PSU.
The presenter explained that payment data transactions are not considered personal data if the data relates to a Corporate PSU, whereas such data would amount to personal data for individual PSUs.
Moreover, they described the EDPB’s Guidelines on PSD2 relating to further processing, and explained that:
– Compatibility is unavailable under Article 6(4) of the GDPR (paragraph 22 of the Guidelines). The relevant lawful basis for processing under the PSD2 is performance of a contract, for which the ‘necessary’ requirement has been restrictively interpreted (see EDPB Guidelines 2/2019).
– Further processing of payments data can only be based on EU or Member State law or the data subject’s consent. The Guidelines note that relevant Member State law includes counter terrorism and anti-money laundering (paragraph 23 of the Guidelines) but leaves a question mark as to whether fraud prevention and detection activities are captured (paragraph 70 of the Guidelines alludes to this, in combination with Article 94(1) of the PSD2 but this was not explicit in the Guidelines).
In practice, this means that: 1) PSD2 is not lex specialis; the two regimes operate together; 2) this is a dual regime under PSD2; and for a corporate PSU, the only permitted processing appears to be restricted by Articles 66 and 67 of the PSD2, with no recourse to obtain consent under GDPR for corporate PSUs; 3) there are no compatible purposes under Article 6(4) of the GDPR; 4) we must be mindful of EU and Member State Law; and 5) the role of consent, especially consent that meets the requirements of the GDPR, has a very important role in determining how ancillary services can be provided under PSD2 to individual PSUs (i.e. data subjects).
The second presenter stated: ‘If the fulfilment of the account information or payment initiation service falls under performance of the contract, then the TPP ought to also get the consent of the data subject to see if they can share the data with third parties so that they can offer them services unless this can be included in the contract; however, this will need careful consideration in line with the EDPB’s Guidelines 2/2019.’
The second presenter expressed that: ‘If, for example, PSD2 deals with consolidation of various accounts for purposes of analytics as an account information service, then the account information service ends because the consolidation has taken place. If the purpose is different and not previously covered in the contract – assuming it can be covered in the contract and that such additional services are necessary – the TPP must obtain consent from the individual PSU to share the PSU’s data with recipients for the further purposes of X, Y, Z. However, an ecosystem based on consent is unlikely to be viable in practice. Further clarity from the EDPB is required owing to the inherent conflict between what the Guidelines suggest and what PSD2 was designed to achieve.’
Interoperability
The third presenter focused on the Financial Data Exchange (FDX) model. FDX has the potential to be an alternative model to the open banking model that has been gaining momentum in, e.g., the UK and Australia. FDX is user centric by design and creates a consent receipt where it can trace users’ data through a data transferring ecosystem (e.g., from the bank to the permission party). FDX focuses on control, access, transparency, traceability, security, and data minimization, and ensures that consumers have full control of their data. By creating a fully traceable ecosystem with consent receipts, users will be able to identify the liable party if there is a breach of their data.
To learn more about FPF in Europe, please visit fpf.org/eu.
