A lot is being read, written or heard about GDPR – it’s relevance, implications to institutions that collect personal data, and ramifications of non-compliance. Therefore, this will not deal with any of these in detail. Keeping it simple we will try exploring 4 specific impact points within financial institutions because of this regulation, and therefore what changes this may ask to be brought about in systems, while meeting its terms under the 99 articles that GDPR comprises of.
As a quick introduction to GDPR – it stands for General Data Protection Regulation. It applies to citizens of the European Union, with an aim to standardize data privacy laws across industries by making them aware of the rights they have under this regulation to protect their personal information. Banks, in general, are involved in the collection of humongous amounts of customer information, which is mostly aggregated at different levels for numerous activities, like customer onboarding, client analytics for relationship management, transaction booking, as well as back-office functions like risk reporting and accounting. During these processes, quite naturally, personal data is visible to a large number of different people through diverse systems at various stages. This is where GDPR impacts all financial institutions, because now under the regulation effective from May 25th, 2018, financial firms (like any other entity in the EU region) will have to adapt to the standards prescribed by GDPR on all personal data of EU citizens from being unethically used, to from hacking or identity theft.
This article doesn’t dig deep into GDPR to its lowest specifics, for which there is no better place than the source itself – https://www.eugdpr.org/ . However, in the following sections of this article, we will evaluate in a little more detail what the advent of GDPR actually means for the IT systems of financial institutions, and which one IT should focus on, in this fast-changing world of adapting to greater privacy standards when it comes to client data. The context below will help readers get a simplified view of 4 such critical areas which should be in our minds while solutioning products in this space for banks.
Customer Consensus
There are three important elements within which the most basic tenets of GDPR rests. First– the clauses very clearly articulate that personal data refers to whatsoever can be used to classify an individual within the European Union, like name, mail-id, IP, social profile or any unique identification number issued by a central authority. Second – the act unambiguously mandates that all firms must gain consent from customers before any personal data is collected. And it doesn’t end here. Third – the terms under GDPR also mandates entities to clearly outline the purpose for which personal data is being collected within the EU, plus directs firms to take additional permission if they want to share such personal information with other 3rd parties.
From IT perspective, the first and the second elements are relatively easier to implement because it impacts most processes within banks which deal with functions like client onboarding or KYC. Henceforth, most likely, GDPR auditors will mandate that the bank’s internal reference data management systems have a control to specifically qualify all data as personal which come under the regulation. However, the ramifications of the third element may become more complex to handle later if not defined well in advance within the information system strategies of banks. It’s not uncommon for financial institutions to subsequently pass personal data to other downstream processes which are secondary to the original purpose of data collection but nevertheless are important middle office functions. A few examples of such banking functions are customer segmentation, risk profiling, target marketing etc etc. In-fact there are host of vendor products and services, which many a times banks integrate with, to get client insights and one of the most important features of such customer data platforms is that the data must be readily available to these systems used for such analysis. These may be just a few examples, but given the seriousness of implications related to GDPR, data protection officers and product owners must be diligent in identifying possible impacts of this regulation in all applications while they are defining use-cases that may involve processing of client personal data without their consent.
Data Removal Rights
In defining the rights to data privacy, GDPR empowers European Union citizens to not only request access to their data but also ask for the removal of their own personal data from banks without the need for any additional authorization from any other outside agency. This means that unless there is a need to retain some very specific data which may be required by the banks for other regulatory reporting, in all other circumstances an individual will have the right to exercise his right and option to be forgotten.
While this may seem simple to implement, however, this may have humongous implications on IT systems. Both on legacy and as well when ideating new solutions because, from this point forward, client data portability will be one of the main asks when building new platforms. On legacy systems, backward compatibility will become a big challenge for banks now because there will be the need to make changes in the architecture that will ensure there are no adverse impacts on flows if an existing EU client exercises his right to data deletion.
Pseudonymization of Data
GDPR ensures that there is end-to-end accountability of all participating entities cutting across any client data value stream of a bank to ensure client data stays protected. And it does this by ensuring that not only the parent bank but also all its supporting entities grip compliance as seriously, Under this regulation, a remote function which is working in collaboration with EU banks or serving EU clients, even if it is geographically outside the EU region, cannot disassociate itself from obligations towards data access. The parent organization will remain responsible for EU personal data throughout the entire data lifecycle and they will have to assure that data, that is transferred to third parties, is handled in a manner compliant with GDPR.
Now cross-functional IT systems form the very basis of every financial entity, with client data recurrently passing through this complex web of systems and processes. Combine this to the ecosystem where software development and support is mostly globally distributed. And therefore, it obviously means that personal client data is often accessed by external entities, which potentially increases data exposure at an aggregated level. The challenge therefore for all banks is to function within this operating model and still be able to comply with all GDPR norms. This definitely calls for protecting potential client data in all forms of settings whether it is in a live production environment, during development, or in testing. While It is quite a common practice to mask data in non-production environments so as to hide client data from crossing geographical boundaries, GDPR recommends that data must also be pseudonymized into artificial identifiers in the production environment. Pseudonymization is a new concept under GDPR and it asks for separation of data from direct identifiers so that linkage to an identity is not possible without additional information that must be held separately. And all these call for architectural change within the legacy systems involving significant hardware and software re-build cost.
Consequences of Breach
It’s not that earlier financial firms did not have guidelines to protect customer data, however, the difference between pre and post-GDPR is that while previously entities could have their own standards and adopt their own protocols in the event of data breach, but now the consequences are mandated by the regulation itself. Some of them are reporting a data breach by protection officers to the supervisory authority within 72 hours and as well notifying the impacted customer of the breach, along with likely outcomes plus the remediation within the ambit of GDPR. So much so that GDPR is very specific about the content of such reports on details regarding the nature of the breach, the categories, impacted individuals etc.
The obvious outcome is that, as fast as the banks can, they are adapting to these mandatory compliance needs. The choice for financial entities will be to select between build or buy options for compliance and reporting solutions. In a period of time, the most likely outcome will be that financial firms will be trying to optimize the product cost by buying some standard GDPR reporting framework as a 3rd party product and investing more optimally their resources on data portability part. There are already products and frameworks in the market meeting such demands. The challenge obviously is how fast and how meticulously banks can meet these compliance demands because the liability in the event of any compliance breach is significant. For example in case of failing to gain consent to process data or a breach of privacy by design, the contingent liability on firms will be a fine up to €20m or 4% of their global turnover-whichever is greater. While lesser violations, such as records not being in order or failure to notify the supervisory authorities, will lead to fines up to 2% of global turnover
Conclusion
Given the extensive reach of the GDPR legislation, there is no doubt that banks and other financial entities will have to not only re-architect their existing systems but also ideate newer systems with the concept of Privacy by Design rooted into their information systems strategy. For example, one of the interesting areas of study today is how open banking is clashing with GDPR. On the face of it the two seem to go together well, but while the payments systems directive PSD2 (also known as open banking regulation) on one side authorizes banks to make certain data available to third-party providers the flip side to this use case is definitely related to data being at risk of misuse unless closely guarded by the GDPR provisions. In other words, while PSD2 requires banks to open customer account and transaction data to third parties via open APls, GDPR imposes rigorous requirements for them to protect customer data as well as stringent penalties in case of failures. No doubt that the rise of software-as-a-service frameworks have given banks benefits in terms of greater agility, flexibility and scalability. But this very ease acts as a double-edged sword when it comes to meeting the directives under GDPR.
While it’s fair to conclude at this point with an intended to keep this article light, however for deeper and more interesting insights we must seek answers to the below questions:
- What implications may GDPR have on the business of banks?
- How does GDPR relate to some of the other banking regulations such as AML and as well some of the non-EU-laws like the Indian IT Act section 43A that puts significant responsibilities on companies handling sensitive personal data.
- How will banks be able to bring a balance between their large portfolios of regulatory projects like GDPR alongside demands to go digital via APls and Cloud?
The stories are still unfolding and this is possibly just the beginning. While data is no doubt gold in today’s world, where most fin-tech firms are building platforms to consume bank APIs, regulations like GDPR will ensure that such gold is not only used responsibly but also with the consent of who it belongs to… and so it should be!!
