This piece explores the impact of India’s upcoming data protection law on payments businesses, with a focus on cross-selling and physical location of data storage.
With India’s upcoming data protection on the horizon, businesses must take a close look at their existing data use practices. The Personal Data Protection Bill 2019 (PDPB) calls for structural, organisational and behaviourial changes in data handling procedures. While this is not law yet,[1] businesses may need to recalibrate their business models and products in anticipation of the law. Common market practices like a catch-all ‘I agree’ to the terms and conditions, cross-selling, or wide data-sharing clauses in the privacy policy, may need a re-look. Businesses must also identify the data they hold and assess whether it needs to be locally stored. They must specify clear purposes for data collection, seek clear and specific user consent for all data processing, and must not collect more data than necessary. Organisations must adopt a privacy by design approach – a cultural shift that calls for user privacy to be considered at each stage of the data lifecycle.
This is true for all businesses, including fintech players that are already regulated by the RBI. In this post, we explore the gradated higher level of obligations for businesses handling ‘financial data’ and what this means for payments businesses. We focus on two practices: (i) cross-selling, i.e. the use of customer data to offer new products/ services; and (ii) the physical location where data is stored/ processed.
How should organisations handle financial data?
The PDPB treats different categories of data differently. The categories are:
(i) Personal data: any data that can identify an individual, such as names, addresses, IP addresses and other identifiers;[2]
(ii) Sensitive personal data (SPD): 11 defined categories of data, including data about religious/ political beliefs, biometric data, health data and financial data;[3]
(iii) Critical personal data (CPD): a category to be defined by the government;[4]
(iv) Non-personal data: presumably data that never related to individuals (such as weather patterns, soil trends) and anonymised personal data.[5]
Financial data is SPD under the PDPB. Financial data is defined widely and could include account numbers, transaction history, debit alerts, and loan repayment details.[6] The PDPB does not distinguish between more sensitive details like transaction history, and pure play identifiers like bank account numbers or UPI handles. Many businesses – not limited to the fintech space – routinely use such data. As a starting point, businesses must identify the different data they process and classify it.[7] This exercise typically forms the basis of determining how data is to be handled.
To collect or use financial data, businesses must get ‘explicit’ consent.[8] This is a standard of consent higher than the regular clear, specific, informed consent[9] required for collecting and using personal data. To meet this ‘explicit’ standard, businesses must do three additional things: inform users about the risk of significant harm to them from the processing; allow users the chance to separately consent to different categories of data; and not infer consent through conduct in any way. The lines between regular consent and explicit consent are murky—each of these additional requirements could be folded within the requirements for regular consent. For instance, notifying users about harm is part of ‘informed’ consent; allowing them to granularly consent to different processing activities is ‘specific’ consent.
Possible approaches: In practice, businesses could follow two approaches: one, follow one standard for consent for all types of data (arguing that there is no clear difference between the two and taking into account the complexity of following different layers of consent); or two, show a demonstrably higher threshold of consent for certain types of data through changes to consent forms or to the UI (when consent is sought through an app). The second approach could hold a business in good stead when called upon by a regulator to demonstrate how privacy is embedded in the organisation. This approach takes into account the sensitivity of the data, on the notion that while names and biometric data are both personal data, one carries a higher risk of harm than the other. The UI changes could include just-in-time notices or banners that provide details, such as possibility of harm, when the data in question is financial data. For example, apps typically collect debit alerts or transaction details through the SMS read permission. The UI could briefly display details on why this permission is needed and take this permission separately (instead of one broad consent to all the permissions).
What does this mean for cross-selling?
The requirement for granular specific consent means businesses may not be able to rely on a catch-all ‘I agree’ consent to distinct processing activities that are not related to the core product function. Cross-selling is a common business practice across sectors. This is typically done by building user profiles through customer data, such as expense history or repayment installments. Based on this profile, other products/ services are offered to an existing customer by the same company or a group company. Often, privacy policies and terms of use contain clauses that allow use of customers’ data for offering the customers unique offerings or better products/ services. Indeed, this may enhance the user experience.
Cross-selling is especially important for digital payments businesses. Such businesses already worked on thin margins, and the government’s zero MDR (or merchant discount rate) policy further disrupted their revenue earning capabilities.[10] Cross selling a more lucrative product (such as lending) using payments data may be crucial for survival of these players. For some players, payments could almost be a ‘customer acquisition cost’ to be able to sell another more lucrative revenue-earning product.
However, the PDPB calls for an overall privacy protective approach, one of its facets being data minimisation.[11] This does not mean that user data cannot be collected for cross-selling. It does however mean that businesses must take user privacy into account in all business decisions, including the decision to use customers’ data for cross-selling. In any case, for using financial data, they must seek explicit user consent. A broad clause in the terms or privacy policy coupled with a catch-all ‘I agree’ will need to be tested against the explicit consent threshold. Consent for services unrelated to the core functionality of the product cannot be bundled with other permissions.[12] So, while data use for cross-selling is not prohibited, it must be supported through appropriate controls, through UI/UX changes, consent forms or records. While some of these could introduce friction in the customer journey, carefully tailored design solutions could minimise such friction but at the same time provide relevant information for users to make meaningful choices.
What does the PDPB mean for physical location of data storage/ processing?
Under the PDPB, businesses can transfer financial data outside India under limited grounds, each of which rely on either the proposed regulator or the government approving the transfer.[13] In any case, such data must be stored on Indian servers (presumably a data mirroring requirement).
The RBI already had a localisation mandate- for ‘payments data’ to be stored locally.[14] Key points to consider:
(i) The RBI’s directive covers all data within a payment instruction. It must be complied with by payment system operators and all participants in the payments ecosystem (gateway/ aggregators, card networks, wallets, etc.). The RBI pegs the primary responsibility of complying with the direction on payment system operators, a requirement that would be passed on contractually to tech partners, vendors or service providers. Under the PDPB though, there is no such distinction – any data fiduciary, whether it is a payments system operator or other business, must store ‘financial data’ locally.
(ii) ‘Payments data’ under the RBI directive will likely be a sub-set of ‘financial data’ under the PDPB. Operationally, this adds a layer of complexity to data classification: the narrowest subset – payments data – is subject to a hard data localisation mandate by the RBI; a slightly wider category of financial data which is not payments data can be transferred outside India but mirrored in India; other personal data which is neither financial data nor payments data, can be transferred freely. Businesses must then decide which is most cost effective – segregating different data categories and treating them differently or wholesale local storage/ processing. Physical location of data storage/ processing will become a key factor in selecting vendors for data analytics and other processes.
Reportedly, the RBI has pointed out that the PDPB’s data retention provisions are different from its circulars.[15] In its view, sectoral regulators should be able to decide what types of data must be stored in India. It will be interesting to see the interplay between the RBI’s localisation mandate and the local storage requirements in the PDPB.
Conclusion
The upcoming data protection law will affect data use across sectors. While it is yet to be finalised, the overall structure and principles for data use will likely remain the same. To prepare for the law, businesses must start inventorising their data, assessing their data use practices against PDPB requirements, and identifying what they need to do to comply. Regulated entities like payments businesses must also explore the interplay between PDPB requirements and sectoral regulations to chart out compliance strategies.
Authored by Sreenidhi
Srinivasan, Senior Associate at Ikigai Law, with inputs from Aparajita
Srivastava (Partner – Regulatory).
[1] The PDPB is being examined by a joint committee of the Parliament.
[2] Clause 2(28) of the PDPB.
[3] Clause 3(36) of the PDPB.
[4] Clause 33 of the PDPB.
[5] Clause 91 of the PDPB. For more on non-personal data related proposals, see Summary of the report of the committee of experts on Non-Personal Data, 14 July 2020, https://www.ikigailaw.com/summary-of-the-report-of-the-committee-of-experts-on-non-personal-data/.
[6] Clause 2(18): “financial data” means any number or other personal data used to identify an account opened by, or card or payment instrument issued by a financial institution to a data principal or any personal data regarding the relationship between a financial institution and a data principal including financial status and credit history;
[7] See our blog post on data inventories being the first step towards PDPB compliance. Arriving soon: India’s data protection law. The first step towards compliance is a data inventory, 30 December 2019, https://www.ikigailaw.com/arriving-soon-indias-data-protection-law-where-should-organisations-begin/.
[8] Clause 11(3) of the PDPB.
[9] Clause 11(2) of the PDPB. ‘Clear’ means consent is obtained through an affirmative action. ‘Specific’ means consent is granular. ‘Informed’ means a user is given relevant details at the time of collection.
[10] Payments, Payments Everywhere, Not a Dime to Earn: Zero MDR & the Disruption of the Digital Payments Revenue Model in India, 28 May 2020, https://www.ikigailaw.com/payments-payments-everywhere-not-a-dime-to-earn-on-the-disruption-of-the-digital-payments-revenue-model-in-india/.
[11] Clause 6 of the PDPB.
[12] Clause 11(4) of the PDPB.
[13] Clauses 33 and 34 of the PDPB.
[14] RBI’s direction on storage of payment systems data, April 2018, https://www.rbi.org.in/scripts/NotificationUser.aspx?Id=11244.
[15] RBI seeks exemption from data protection law, HT, 10 September 2020, https://www.hindustantimes.com/india-news/rbi-seeks-exemption-from-data-protection-law/story-kwQzNs614s0C56VK6HTCJP.html
