As the Joint Parliamentary Committee considers the Personal Data Protection Bill, 2019, MediaNama will publish a series of articles from legal experts focussing on the key aspects of the Bill and how they will affect users and companies. This is the thirteenth article in the series. Read our extensive coverage of the Bill here.

By Asheeta Regidi

The tightly regulated financial sector is no stranger to multiple privacy, security and confidentiality obligations, whether imposed by law, contract or accepted industry standards. Despite this, the nuances of a data protection law nevertheless bring in new compliance obligations.

A key challenge for the financial sector will thus be to streamline their existing obligations and activities with the requirements of the draft Personal Data Protection Bill, 2019 (the “PDP Bill”). This article looks at the changes in the PDP Bill entail for the financial sector in terms of the impact on certain specific activities, and how present financial laws would need to be aligned with the Bill.

Fintech companies are providing an increasing number of services to customers (neobanks, personal finance managers), to banks (video KYC services, payment aggregators), to other companies like merchants (risk management services, customer lifecycle management) and even to other fintech companies (credit scoring, analytics). A number of these often fall outside of traditional regulation.

The PDP Bill brings in major compliance obligations, for the first time for some, and in particular for data intensive activities.

Impact on API-based banking and consent management

An increasingly popular fintech service today is  API-based banking-as-a-service. This allows third party applications to access data from a bank to provide a service, such as a neobanking app enabling salary disbursals from enterprise bank accounts to multiple employee bank accounts. Relevant data in the bank’s database is accessed using an application programming interface (API), that only gives access to the queried and permitted data.

This exchange of data falls entirely outside the scope of the RBI’s account aggregator (“AA”) framework, a consent management framework introduced to govern a similar exchange, but between regulated entities only (for example: a customer of Bank A approaches Bank B for a loan, and Bank B seeks credit history, etc. from Bank A).

The AA framework prescribes detailed data protection requirements (explicit consent with strict restrictions for access, sharing, storage, etc.). For fintech provided services, the entire process (relying on user credentials, screen scraping, etc.) is instead governed contractually.

The PDP Bill will now bring in similar data protection requirements, requiring, for instance, addressing existing issues such as inadequate customer consent and sharing of plain-text data, enabling the exercise of data principal rights like the right to access or portability, and revamping contracts to specify controller-processor obligations, purposes, erasure periods, and so on.

Consent managers under the PDP Bill
The Bill also brings in an analogue of the AAs — intermediary data fiduciaries called “consent managers”. These will help users manage consent given to data fiduciaries, thus enabling both regulated and unregulated entities to now gain consent-based access to data through a third party. Some clarity as to their operations is needed — such as whether they will follow the AA’s model of functioning, whether they can be sector-specific, whether API specifications for simplified integration will be issued, etc.

Aligning the AA framework with the PDP Bill
On a separate note, along with consent management, the consent managers additionally allow users to communicate with fiduciaries to exercise any of their rights under the proposed law. The AA framework at present does not permit this exercise. An amendment should be considered to avoid forcing users to have to rely on the AAs for managing consent as well as a separate consent manager for exercising their rights.

Impact on increasing mergers, acquisitions, and consolidations in the fintech sector

A notable trend in the financial space bound to reach India soon are varying mergers, acquisitions and consolidation (Visa-Plaid, Fiserv-First Data, Worldline-Ingenico). The coronavirus outbreak may also trigger a certain amount of consolidation in the sector to enable struggling companies to survive. Data will play a significant role in the decisions taken, both as an asset to be valued as well as a risk to be assessed.

Monitoring notable movements by the proposed Data Protection Authority (“DPA”), and conducting independent privacy audits, as a part of prior due diligence procedures by the companies themselves, will become inevitable. The significant fines under the Bill (2-4% of total worldwide turnover) will also necessitate indemnities and warranties from the seller, such as that it hasn’t experienced any data breaches, or that its activities are fully compliant with the law.

Data protection compliance during the process of the M&A itself will be key (such as identifying a lawful basis of processing, providing notice to data principals, etc.). Significantly, the Bill proposes exempting M&As from the consent requirement, as a “reasonable purpose” for processing [Section 14(2)]. In view of the classification of financial data as sensitive personal data (“SPD”), it is notable that the original 2018 Bill did not allow SPD to be exempted as a reasonable purpose. The 2019 Bill however makes no such distinction. Thus, unless further clarity is given in the final draft, SPD, including financial data, will also be within the scope of the consent exemption for M&As.

How will existing contracts and relationships be redefined? A closer look at the payments industry

Relationships in the financial sector are determined not just by law, but also by contract, by custom and by international practices. This creates specific issues in relation to data protection compliance. This is illustrated here with a reference to the payments industry:

Identifying fiduciaries, processors, and redefining obligations

A payments transaction made on a merchant site involves a range of players — the merchant, the payment gateway/aggregator, a mobile wallet, card networks, the issuing and acquiring bank, the bank with the nodal account, any service providers involved such as the cloud service providers or SMS service providers, and so on.

The exact role of each of these, that is, as a processor or a fiduciary, varies based on the specific role as well as the individual contractual arrangements between each player. For example, the banks involved will normally be fiduciaries while the payment gateway/aggregator will normally be a processor. However, if the payment gateway chooses contractually to retain data, say on customer complaints made to them for research for product evaluations, then it acts as a fiduciary with relation to that specific data.

The PDP Bill requires each of these players, whether fiduciaries or processors, to be compliant with the law. This will also include the card networks, in view of the extra-territorial jurisdiction of the PDP Bill [Chapter VII]. Existing obligations will also need to be re-evaluated for their compliance with the upcoming law — such as revamping contracts to separate obligations and liabilities imposed. In the payments transaction, for instance, the notice and consent obligation will be imposed on the merchant. Another example is imposing privacy by design obligations on the provider, such as when a fiduciary is using a white-labelled payments application/technology.

Another important point here is the contractual determination of liabilities to pay the steep penalties under the Bill for a violation. It must be remembered here that fiduciaries and processors alike can be required to compensate victims of a data breach for a violation they commit.

Identifying a lawful basis of processing

The PDP Bill only identifies Indian laws as an exception to consent. This means that unless exempted as a reasonable purpose, requirements imposed via international law, contract, etc. will require consent. PCI-DSS compliance, for example, is a mandatory international compliance standard for card payments imposed by card networks (i.e., not an Indian law). For every such obligation, the financial sector will have to identify whether a law exists, an exemption applies (for, PCI-DSS for instance, the reasonable purpose exemption for fraud prevention/information security will apply) or if consent will have to be obtained.

Interacting with existing laws

Issues can also arise where a law is in place. The PDP Bill, for instance, recognises only purposes “necessary” under law. Consider the RBI’s Master Direction on KYC, which grants banks certain discretion in relation to disclosures, allowing these for when the “interest of the bank requires disclosure” and when there is a “duty to the public to disclose” [Section 56(d)]. Whether various discretionary powers satisfy the requirement of “necessity” under the PDP Bill, given that this is prescribed law, or whether these will need a separate DPA approval needs to be clarified.

Similarly, minimum retention periods can be found in the law (the KYC direction for instance prescribes 5 years), but the PDP Bill requires maximum retention periods to be defined. In case maximum periods are not introduced in the data protection itself, companies will be required to define when to erase data on their own.

A separate conflict that arises is with concurrent jurisdiction for data-related disputes between the DPA/Adjudicatory Officers under the PDP Bill and various avenues under financial laws such as under RBI notifications or laws like the Payments and Settlement Systems Act. The Digital Ombudsman, for instance has jurisdiction over any non-adherence to an RBI instruction, that often includes privacy and security requirements. The PDP Bill thankfully proposes to solve this by allowing the regulator and other authorities to enter into a Memorandum of Understanding with the DPA for this.

Can the Bill be applied retrospectively to existing databases?

The absence of an adequate data protection law has led to the creation of huge databases, which are subjected to analytics using AI/ML, become the object of data trades/sales, enable revenue generation via cross-selling and upselling of financial products, enable services like wealth-tech, robo-advisory, and so on. Consider alternative credit scoring, which moves past financial data alone to use alternative data — ranging from web browser history to details about phone calls made — to decide whether or not credit should be granted.

Data protection laws don’t have direct retrospective application. However, steps will be needed to continue processing (which includes even mere storage) the data in hand. Companies will have to either erase, anonymise (which is tricky) or make the data compliant. The last can be burdensome, as it involves providing notice to customers, reviewing activities to ensure they comply with privacy principles (data minimisation, purpose limitation, use limitation, etc.), and so on, and where an alternative ground for processing cannot be identified, obtaining proper consent from the customers.

Is alternative credit scoring a “reasonable purpose” for exemption from consent?
The Bill proposes exempting credit scoring from consent as a reasonable purpose. It is not clear if alternative credit scoring falls within this exemption. Under the GDPR, companies have a certain amount of discretion with identifying processing that they have “legitimate interest” in, allowing them to use alternative data for credit scoring thereunder. Under the Indian PDP Bill, the reasonable purposes exemption is not similarly discretionary, but will work in the form of whitelisting by the DPA. It is unclear at the moment if the exact scope of the whitelisted activity will be clarified, or if once whitelisted, defining the scope of the activity will be left to the discretion of the companies. Given the increasing use of alternative credit scoring, particularly as a tool for financial inclusion, there is potential for the DPA to permit it.

How will the innovation sandbox work? How will it interact with other sandboxes?

Innovation in general will need to become more privacy conscious. This will be in terms of the data leveraged to create, and also the impact of the innovation itself. Consider Video KYC, which will involve the use of biometric data (say facial recognition techniques). This, in turn, will lead to the creation of multiple biometric databases with various entities using the technology with the RBI (via the regulatory sandbox, since applications have been invited for digital KYC products), with fintech companies providing this service, with banks and other financial institutions using the service and even with the Central KYC registry. Securing these will need to be prioritised. Video KYC services, like other inventions that are based on biometric data (such as device-less payments), will also need to be conscious of Section 92 of the PDP Bill, whereby the Central government can prohibit processing of certain types of biometric data.

Similar consciousness with data protection norms is also required when creating underlying technology. The blockchain, for instance, is a technology that by its very design brings in certain limitations for privacy compliance. An example is with customers exercising rights to data correction or data erasure. Privacy by design is a factor that will have to be accounted for [Section 22].

Innovating itself will face its own challenges. The RBI’s regulatory sandbox framework, for instance, mandates express customer consent together with demonstrated compliance with data protection laws. Flexibility with repurposing data, however, will be limited given the PDP Bill’s norms on data minimisation and purpose limitation. To support innovation, relaxations similar to those allowed for the sandbox proposed under the PDP Bill itself should be extended to the sandboxes in the financial sector as well. These include, for example, relaxation of purpose, collection and retention limitations.

Interaction with other sandboxes

Also, with multiple regulatory sandboxes in place (for instance, IRDAI, SEBI, RBI, recommendations for inter-regulatory sandboxes in the financial sector for hybrid financial products), permitting inter-operability between these sandboxes and the one under the PDP Bill, or the ability to seek relaxations from multiple sandbox frameworks for a single product must also be considered. This is important since each framework allows an authority to relax regulations only within the ambit of its specific powers. The RBI for instance will be unable grant relaxations to the regulatory provisions within the power of the DPA, and vice versa. 

How will new players from Big Tech be governed?

DPA monitoring will also be inevitable with another notable trend — the foray of Big Tech into the financial space. The services offered include payments (WhatsApp Pay, Alipay), credit (Apple card), banking and neobanking (Uber Money, Google’s Project Cache), etc. This will involve, on the one hand, repurposing existing data troves (such as creating risk profiles or customised product offerings), and on the other, the greater data access and insight gained on account of the new and increased customer activity on their platforms.

While developing business models here, Big Tech companies need to take into account that they no longer have a free rein over data. The Bill brings in restrictions like data minimisation and purpose limitation, which impose restrictions on (say) the types of data that can be collected, how long it can be stored and the purposes it can be put to. Consent will often be required as a basis of processing, and even where it is exempted (say for State activities or as a reasonable purpose), notice will still need to mandatorily be provided to data principals.

The need for a Task force on data protection

An important issue with the PDP Bill is that a lot is left to the discretion of the DPA. Many aspects of the compliance are thus ambiguous at present. The complete picture of the actual obligations for a specific industry and the flexibility allowed will emerge only once the DPA is in place and commences issuing guidance documents, codes of practice, etc. To effectively do this,

  1. The discretionary power of the DPA should be reduced by introducing more definite terms in the law to guide it, say with the determination of exemptions or the defining of timelines for data breach notifications.
  2. A streamlining of norms at an industry level will also become essential. This can be via the setting up of a Task Force to review and align current financial laws with the PDP Bill, as recommended by the Steering Committee on Fintech Related Issues. This can also be done by allowing of industry-created but DPAI approved codes of practice. These will be essential steps, not only for the financial sector, but also for other highly regulated industries such as healthcare.
  3. The second recommendation of the Steering Committee, that certain obligations of the DPA be handed to other sectoral regulators to discharge, also needs to be implemented for a more balanced sharing of power and responsibility.

*

Asheeta Regidi heads Fintech Policy at Cashfree and is a certified privacy professional.

Edited by Aditi Agrawal