GDPR: Protecting consumer data
On 25th may 2018, the new GDPR laws established by EU commissioner pertaining to EU economic area and European Union citizens and residents came to life. The new rules announced two years prior, promised steep penalties starting at $10million or 2% of annual company turnover and up to $20m or 4% turnover, whichever was higher, for serious breaches of consumer trust.
GDPR is a set of laws regulating the processing of personal data of the EU citizens and residents, within the European Union and European economic sector. GDPR also attempts to unify laws across the EU as it supersedes the 1995 directive; outdated rules that not only came before the global digitization and the big data boom but were also interpreted differently by various EU members.
The new law forces companies to minimize the amount of data they gather, process, and store, and the time they use such data.
It also gives consumers a pleiad of rights such as:
- The right to access your personal data in an easy and understandable way, without unnecessary delays.
- The right to change and update the data.
- The right to request erasure of your data, as far as it allows companies’ compliance with other laws.
- The right to withdraw your consents and change how your personal information is used.
- The right to be informed within 72h about data breaches and hacks.
- The right to data portability – an ability to quickly and easily transfer your data to another provider.
- The right to specifically opt-in or object to data gathering and storage via cookies or email lists.
Implementing GDPR, as many analysts pointed out, requires not only auditable protocols and automated data lifecycle but also some fundamental changes to how banks and financial companies think about the consumer privacy. For the majority, it might require a major revision of the core processes and their business models.
PSD2 opening Banks to Non-bank Competition
PSD2 or the Revised Payment Service Directive, which came into force on 13th January 2018, is a part of Open Banking initiative that hopes to encourage innovation and competition from the non-banking entities. To do that, it will cut banks’ monopoly on payment services and force banks to share the client’s information with the third-party providers authorized by the customers. The main goals of PSD2 are to make online payments between different members of the EU faster and more secure. It facilitates the cross-border transfers and strives to create a single digital market. In effect, citizens of European countries can transfer money to another EU state just as quickly and securely as they would when paying in their own country.
The PSD2 promotes digitization of banking and financial services and the creation of APIs (Applications Programming Interface). The new applications will work on top of the banking account infrastructure to provide clients with payment services or additional services via third-party providers.
TPPs (Third-Party Providers) according to the new law will include:
- PISP = Payment Initiation Service Providers may, with the permission of the customer, initiate bank payment on their behalf.
- AISP = Account Information Service Provider, can analyze customer bank statements directly using banks framework and APIs, and produce aggregate data or analyses of spending behaviors. With user permissions, AISP could offer analyses from several different banks.
The law was passed by the European Commission and the parliament in November 2015, and the organizations were given two years to adapt their systems. The banks were allowed to take two distinct approaches. A passive strategy that complies with minimal requirements and builds an underlying API that is accessible to third parties for them to develop their apps. Or an active approach where banks take the initiative to design their own advanced applications and leverage the system to their advantage by enticing customers with the in-house services.
PSD2 opens personal customer data to many potential third parties, which is why the law puts extra pressure on customer’s consent and the data security inherent to the new apps and APIs. The Strong Customer Authentication rules (SCA) will govern the security and will require 1) something the customers know (a pin, a number, or a password), 2) something they own (a credit card, a smartphone) to validate their identity and block access in case of lost cards and phones and 3) something that customer is (biometric such as a fingerprint, facial recognition, or iris scan and detection of unique behavioral patterns)
GDPR and PSD2: is there a real contradiction?
There has been a vivid discussion regarding the possible GDPR & PSD2 contradiction. That might be partially caused by the lack of all the necessary details laid down by the Regulatory Authorities in regards with the both initiatives. There is definitely a commonality between both regulations and that is the emphasis on customer consent. At the end, the customer is in the lead: when they decide to share personal data with any (third) party, it is their freedom of choice.
PSD2 obliges banks to provide Third Party Providers (TPPs) with access to a customer’s payment account data if a customer explicitly consents to such a disclosure. GDPR also requires to get an individual’s explicit consent prior to any data disclosure. So basically the type of consent for both PSD2 and GDPR is pretty clear – it should be explicit consent and that is the crucial point. Worth mentioning that before GDPR came into effect, the previous EU legislation on data protection had no focus on “explicitness” of consent and, consequently, businesses used that legal gap in their own interests (e.g. business used to use pre-ticked boxes on their webpages that simply could be unintentionally ignored by individuals when sharing their data, concluding a contract or purchasing anything online). With GDPR using pre-ticked boxes for obtaining consent is not legal anymore.
But there is a number of points which may provoke ambiguity of complying the two laws. They are as follows:
- The technical ways and overall purposes for such consent
The technical ways and overall purposes for such consent may be different in PSD2 and GDPR. According to PSD2 (Art. 67, 94) banks must only allow TPPs access to customers’ payment account data provided the TPPs have the “explicit consent” of the customer. Meanwhile, the GDPR states that data controllers (in our case – banks or TPPs) must have a “legal basis” for processing customer’s personal data and consent is only one of the available legal bases. So it means that GDPR allows the processing of personal data even without customer’s (individual’s) consent in certain cases ( for example, when the processing is necessary to perform a contract, or for the purposes of the legitimate interests of the data controller or for compliance with a legal obligation.) In other words, if a customer wants to carry out a payment transaction with a TPP, the TPP needs access to customer’s payment account data in order to initiate the payment. And there should be no need for customer consent for the associated data processing operations since TPP has “legal basis” for such actions.
In this particular point we get a perfect example of the misleading interpretation of PSD2 and GDPR consent provisions. In some cases banks can refuse to provide TPPs with access to customer payment data because of the fear of breaching the GDPR. As a result of such banks behaviour, competition authorities may consider banks refusal to provide TPPs with access to customers payment data as breach of competition law.
- “Personal data” vs “sensitive payment data”
One more problem which occurs in the interpretation of both regulations is a lack of definition. GDPR contains definitions of “personal data” (as well as special categories of personal data). PSD2, in turn, brings in additional definitions which do not appear in the GDPR, such as “sensitive payment data”. Does sensitive payment data qualify as a category of special personal data under the GDPR and thus subject to stricter rules, or not? That is the question which remains unresolved.
- Information requirements
Information requirements are also not well regulated yet. According to GDPR, there are information requirements for banks and TPPs, such as having to provide customers with a legal basis for the processing and transfers of personal data. But who is responsible for providing this information to customers? If it is banks responsibility, how is it possible for a bank to ensure the customers using TPPs have access to the necessary information to satisfy their obligations under the GDPR.
- Incident reporting requirements
Both PSD2 and GDPR impose incident reporting requirements but the approaches used are different. Thus, GDPR requires banks and TPPs to document all personal data breaches (and notify these breaches to the relevant data protection authority within 72 hours, unless the breach is unlikely to result in any risk for individuals.) At the same time, bank or TPP must notify the customers whose data was breached without undue delay where the breach is likely to result in a high risk to the rights and freedoms of the customer.
PSD2 requires banks and TPPs (as well as other payment service providers) to notify, without undue delay, to the competent authority any “major operational or security incidents”. Similar to the GDPR, under PSD2 bank or TPPs also have to notify the customer if the incident may have an impact on their “financial interests”.
Practically it means that banks and TPPs will have to satisfy incident reporting requirements under both GDPR and PSD2 separately. For example, in the UK the relevant reporting authority under the GDPR is Information Commissioner’s Office (ICO) and under PSD2 – Financial Conduct Authority (FCA).
2018 has been a transformative year for banks and financial institutions as two major legislations rolled out only a few months apart forcing them to restructure a whole spectrum of their policies and systems. Both PSD2 and GDRP promote automation, innovation, and digitization.
PSD2 and GDRP can work in tandem since both laws put similar pressure on data protection, with PSD2 introducing the SCA model, and GDPR requiring security by design. But there are also a few grey areas in the which demand additional clarification. The best solution to implement both is building them into software and application design, which also aligns with EUs efforts to follow the global digitalization trends.