CRED and the DPDP Act: What Happens When Your Business Model Is a Consent Transaction
CRED trades rewards for financial data. Under the DPDP Act that is either the strongest foundation in Indian fintech or a very expensive gap, depending on whether consent is itemised or bundled.
CRED is the most DPDP-interesting startup in India right now. Not because it has had a breach. Because its entire business model is a consent transaction.
You give CRED your credit card statements, your loan history, and your bank account data. In exchange, you get reward points and exclusive offers. That is the deal: explicit, visible, and ongoing. Under the DPDP Act, that is either the strongest foundation in Indian fintech or a very expensive gap. It depends on one thing: is that consent itemised or bundled?
Itemised or bundled: the §6 question
§6 of the DPDP Act says consent must be taken separately for each purpose. Accessing your credit card data to pay bills is one purpose. Using that same data to build a creditworthiness profile shared with lending partners is a different purpose. Both need their own consent: separate checkboxes, separate notices, and separate withdrawal options.
If the consent flow covers both under a single "I agree to share my financial data", that is the gap. Not because it is deceptive, but because DPDP does not accept bundled consent for separate purposes. Full stop.
The harder problem: withdrawal without detriment
§6 also says a user can withdraw consent at any time, and that withdrawal cannot result in detriment to the user. If withdrawing data-sharing consent means losing access to rewards or features, that is detriment. The "pay with data or lose the product" model is one of DPDP's genuinely unresolved tensions, and CRED will be at the centre of it when enforcement starts.
To be clear: we are not saying CRED has built it wrong. The actual consent infrastructure is not visible from the outside. But the question is worth asking before the regulator does.
The audit question for every data-for-value product
If you are building any product that trades value for data, audit your consent flow against one question: does each purpose have its own checkbox? If the answer is no, that is your DPDP to-do list, not a minor technicality. Item 3 of our DPDP compliance checklist covers exactly this.
The free Compliance Score below checks your consent capture, among other things, in 60 seconds.
Frequently asked questions
What is bundled consent under the DPDP Act?
Bundled consent is a single agreement covering multiple distinct processing purposes, such as one checkbox covering bill payments and credit profiling. §6 of the DPDP Act requires separate, specific consent for each purpose, so bundled consent does not meet the standard.
Can a company remove features when a user withdraws consent?
This is one of the open tensions in the DPDP Act. §6 provides that consent withdrawal should not result in detriment to the user. Whether losing rewards or features amounts to detriment is likely to be tested once enforcement begins, so products built on data-for-value exchanges should design withdrawal paths carefully.
Does the DPDP Act apply to financial data specifically?
The DPDP Act applies to all digital personal data, but §8 and Rule 6 require safeguards proportionate to the sensitivity of the data and the harm exposure could cause. Financial statements, loan history, and creditworthiness profiles sit at the high end of that scale.