Published on December 6, 2018
More than a half-year has passed since GDPR (EU General Data Protection Regulation) moved into force. Have you heard about any laud GDPR cases where companies were fined?
I’ve heard about only one – Ms. Elizabeth Denham, the UK Information GDPR Commissioner, stated that she might investigate Facebook for exposing people’s data to the political consultancy Cambridge Analytica. Well, to my understanding, this event happened before 25 Jan ’18, i.e. it may be ethical or not (proper or improper), but it was not in the violation of not-exited GDPT that time. Based on the USA Congress hearing and the demands of the UK Parliament, Facebook did not breach its own policies as well. As we all know, Facebook is a great source for all kinds or researches, intelligent or not. People, who used Facebook, had to understand up-front that very they disclosed their personal data to anyone who might be interested in them for any purposes. There are no such things as a ‘free fun’ (or breakfast).
So, I can assume, that GDPR practice is still in the speeding up deployment. I’ve noticed an interesting (IMHO) phenomenon – all companies raise a banner of client centricity, but internally many top managers are not in favour of protecting personal data from their own personnel, their partners and consumers. If a personal data should be moved from one internal system to another and the GDPR-aware Architects say that the data should be encrypted, this causes an unhappy reaction from the Managers of both systems.
The business owners of the systems openly express serious concerns about how their staff would be able to deal with encrypted data. Personal data protection still comes as a big surprise to many operational businesses. When Compliance, Business and Enterprise Architects say that no Excel spreadsheets with personal data in clear may circulate around business teams, the options here are: a) prohibit the use of spreadsheets for personal data, or b) encrypt this data in the spreadsheets. The reaction of business users is usually like this, ‘This is unacceptable, we always worked with meaningful spreadsheets…’.
I think that the culmination of the current state of GDPR adoption, i.e. its understanding, implementation and acceptance in the corporate culture, can be illuminated when viewing the GDPR and PSD2 (Payment Services Directive 2) regulations together. Our companies are in the exact this position – in between these regulations.
These regulations come from the EU Regulation Bodies, have only a few references to each other (if at all), but result in the situation where GDPR requires to protect personal data while PSD2 requires to disclose it to many. In the UK, particularly, the regulation known as Open Banking (OB) has expanded the scope of PSD2 almost twice.
Both regulations represent, refer and operate with a notion of ‘consent’. While GDPR has enlarged detailed explanations about the data subject’s consent, i.e. how it may be obtained and managed, I was not able to find anything comparable in clarity and details for the Account Holder’s consent in OB. Though, this may be only my fault.
What I’ve found in OB, are two statements, “An intent is used to define the fine-grained permissions that are granted by the PSU to the TPP” [where PSU stands for a Payment Service User and TPP stands for Third-party Payment Provider], and “The act of providing authorisation of an intent by a PSU to an ASPSP is called consent authorisation”,
[where ASPSP stands for an Account Servicing Payment Service Provider,
which is usually a bank or an institution that hols and maintains
Accounts for individual or institutional Account Holders]
.
This OB’s tiny explanation has caused a lot of confusion already. Just think about this declaration from Deloitte, “…consent from customers to allow banks to share their payment data with Third Party Providers (TPPs) under PSD2”. Consent is interpreted as a permission that should “allow banks to share their payment data”. This is a bit bold statement because an Account Holder might not mean giving the consent for sharing his/her payment information, but only to conduct the payment or withdraw via payment API. If the bank does not provide different options of “fine-grained permissions” by the OB APIs, TPP will be always in violation of GDPR using coarse grained account APIs (because Account Holder will be able object any use of his/her financial data on the basis s/he did not mean that particular usage). For instance, a consent to conduct payment or withdraw does not automatically mean that the TPP may keep the Account Number or to share it with anybody. Dealing with account API is usually much more complex.
Back in September 2017, i.e. just a half-year before GDPR getting in power, FCA promoted a few ideas that GDPR practically shuts down. They are: “The UK implementation of article 94(2) PSD2 does not permit an ASPSP to require explicit consent where it has an obligation to disclose information.” That is, “the ASPSP should not require explicit consent from its customer before it complies with its obligations relating to giving payment account data to AISPs or PISPs” [where AISP stands for account information service provider, a type of TPP, and PISP stands for a payment initiation service provider, also a type of TPP]. Also, “ASPSPs are not required to check the terms of the consent provided by the customer to AISPs, PISPs …, nor are they able to seek proof, or confirmation from the customer, of that consent as a prerequisite to fulfilling their obligations to provide access to AISPs, PISPs…”. Isn’t this crystal clear that the ASPSP’s customers were seen in PSD2/OB as a rightless source of information for TPPs? Fortunately, these ideas have not got through.
There were several attempts to “wed” GDPR and OB, for instance, “… TPPs will be able to access the customer’s payment account information directly, provided they have the customer’s explicit consent, and use banks’ infrastructure to facilitate provision of payment initiation or account information services. In principle, this marries perfectly with the right to data portability introduced by GDPR” [TPPs will be able to access the customer’s payment account information directly, provided they have the customer’s explicit consent]. Well, GDPR portability addresses only a change in the data custodian, not the changes in the data protection. Giving an access to the account data does not automatically mean that the bank should return the data in response to the OB API request. Why, instead, the bank may not allow TPP to read the data from the bank’s screen? Since the bank is a trusted custodian of the financial information of the Account Holder, what guarantees the bank that the personal data of its customers will be still protected on the TPP’s side?
Thus, if a bank or any analogous institution is compliant with GDPR, the only OB APIs can be realised directly in accordance with PSD2/OB are payment APIs. All account APIs must be in compliance with GDPR, i.e. the Account Holder must be presented with multiple fine-grained options that cannot be interpreted in any other way than is written. Also, no data processing is permitted other than the ones the Account Holder has given the consent in the request. That is, when and if a TPP obtains a personal data of the Account Holder, this data is still belongs to the Account Holder, who acts now as a data subject and the TPP must ask this person for any further permissions to operate with data. If personal data were fully covered by GDPR initially, no legitimate interests may be applied automatically by the TPP based on the fact of a change in data custodian.
That is, there should be a standardised regulated mechanism that would guarantee that the TPP preserves all GDPR rights of the Account Holder when the personal data is moved from the bank to the TPP upon explicit fine-grained permission. For example, an Account Holder can consent to copying account data to the TPP, but not giving a consent on processing this data in any way (in the GDPR meaning of processing). According to GDPR, all usage of personal data must be explicitly and unambiguously documented when the consent is requested.
Altogether, PSD2/OB and GDPR are in a conflict and balancing these two regulations appears trickier than it seemed at the beginning. If the ASPSP is really after protection of its existing and future customers, it can apply GDPR and leave the TPP to resolve legal restrictions on personal data. If the ASPSP cares about customers and TPPs, the account APIs can be offered in an impersonalised manner or a data encryption/decryption mechanism should be shared between the ASPSP and TPP (via a support from the OB organisation).
Particularly, all personal information, i.e. an information that can be used to identify the person, should be either non-readable or simply removed from the bank’s API returns regardless whether TPPs like this or not. Obviously, all these nuances should be clearly described in the API documentation. It is important to outline, that no PSD2 or OB standards may push the banks to violate GDPR. Banks should be alerted about such risks now and in the future.
I provide on- and off-line #consultations on #architectural #solutions and #design for individuals and groups, on #Skype, 5 days a week. Cheaper that to call a plumber. Send requests to mpoulin@usa.com with “CONSULT” in subject.
HOW to ARCHITECT for DEVELOPERS 