ARTICLE
10 August 2023

Fintech And The Data Protection Bill

I
Ikigai Law

Contributor

Ikigai Law is an award-winning law firm with a sharp focus on technology and innovation-led businesses. We advise clients from high impact startups to mature market-leading companies and are often at the forefront of policy and regulatory debates for emerging business models. Our TMT practice is ranked by Chambers and we were named Boutique Law Firm of the Year in 2019 by Asian Law Business.
No piece of legislation has taken more punches than our elusive data protection law. You've heard this before, but we'll say it again. The data law is nearly here!...
India Privacy
To print this article, all you need is to be registered or login on Mondaq.com.

This article discusses the first step for fintechs to get ready for the new data law. It originally appeared in the July 2023 Edition of FinTales, our monthly fintech newsletter.

No piece of legislation has taken more punches than our elusive data protection law. You've heard this before, but we'll say it again. The data law is nearly here! The Digital Personal Data Protection Bill, 2023 was introduced in Parliament on 3 August 2023. And this time, the stars may well align for the law to be passed.

The new bill is lean and principle-based and leaves the details to the rules (which will be framed by the government). Once passed, it will affect all businesses including fintech companies that collect and use digital personal data. Read our primer on the law for a quick explainer, and our summary for an overview of the law and changes from the earlier version.

Earlier this year, we listed what fintechs must do to prepare for data regulations. Our three priorities were: know your data, share with care, and tell it all. We discuss a step zero today – know yourself.

Are you a planet or a moon?

Say you are a payment aggregator or a KYC service provider or an AI-based data analytics service provider. Your clients are entities – not people. The data protection law aims to protect humans (and their privacy), not entities. Does that mean you skip the whole 'DPDP and what it means for me' conversation? No, not so fast.

A KYC service provider services a bank. It conducts KYC verification of the bank's customers for the bank. The service provider sits on large volumes of data. But it hasn't collected the data in its own right. It only accesses the data to do a task for its enterprise customer – the bank.

Data laws recognise two types of entities:

  • Data fiduciaries – those who call the shots about their users' data. They decide what data is needed, what it'll be used for, how it'll be used, and so on.
  • Data processors – those who only process data on behalf of the fiduciary. They have no independent business having that data if not for the fiduciary.

Under data laws (including our proposed one), it is the fiduciary whose neck is on the line. The law says "Hey bank, your customers trusted you with this data. Whether you do the job yourself or outsource it, it's your job to protect their data."

Our solar system analogy for the RBI and its regulated entities works for the data law as well. The data law/ data protection board is the sun, the bank (data fiduciary) is the planet, and the KYC service provider (data processors) are the satellites orbiting the planet.

And so, before you start thinking about how to comply with the law, you must understand your role. Also, just because you're a processor for one activity, doesn't mean you are processor for everything you do. The fiduciary/ processor distinction is activity specific. The KYC service provider is a processor when processing bank's customers' data on the bank's behalf. But it may be a fiduciary when it's collecting training datasets from various sources to train its AI model. Similarly, the KYC service provider is a fiduciary when it collects and uses its own employees' data.

What you should do as a processor

Once you identify your role, in situations where you are a fiduciary, compliance is your responsibility. (Our primer sets out the basics for you.)

But, what do you do for situations where you are a processor?

The data law doesn't tell processors what to do. It leaves it to the bank to tell them what to do. Interestingly, while the RBI tells its regulated entities (REs) this is what you must include in your outsourcing agreement, the data law doesn't. It just tells fiduciaries you must have a contract with your processor. It tells REs a few other things re processors, such as, REs must ask processors to stop processing if a user withdraws her consent to the processing or to delete the data when processing is complete.

The bank will pass on some dos and don'ts, checks and balance onto you – through your agreement with them. For instance, don't use this data for anything else; if there's a breach, tell us asap; don't engage any sub-vendors without getting our approval; make sure your systems are secure; and so on. Of course, a lot of this is already in outsourcing agreements. But with the new law, there'll be a new sheriff on the block monitoring this – the data protection board. As a processor, you must also seek some protections. A KYC service provider has no business having the bank's customers' data – without the bank having first legally taken it from its customers. Its right to the data depends on the bank having taken customers' consent. And so, you must make sure that they've done this right. Processors must also seek clarity on what security controls are expected of them, what they must do in case of security incidents, what should they do in case third-parties or government agencies make request for data, and so on. And they must seek to cap their liability, depending on the nature of service they provide.

The content of this article is intended to provide a general guide to the subject matter. Specialist advice should be sought about your specific circumstances.

See More Popular Content From

Mondaq uses cookies on this website. By using our website you agree to our use of cookies as set out in our Privacy Policy.

Learn More