Compliance
From Loan Application to Consent Receipt: A DPDP Use Case for Digital Lending
By Charanjeet Singh, Co-Founder, IndiaConsent
From Loan Application to Consent Receipt: A DPDP Use Case for Digital Lending
A digital lender does not collect just one piece of information for one purpose. In a single loan journey, an applicant may share identity documents for KYC, bank statements for underwriting, contact details for servicing, and device or application data for fraud prevention. The operational DPDP challenge is not merely to place a consent checkbox on the application form; it is to connect every purpose, recipient, withdrawal and downstream action to a defensible record.
This use case follows a fictional NBFC, Sahyog Finance, through a personal-loan application. The names are illustrative, but the workflow is designed around the practical questions lenders face: what can be collected, why it is collected, who may receive it, how long it is retained, and what happens when a customer changes their mind.
The lending data journey
| Stage | Personal data involved | Purpose | Typical recipients / systems | DPDP control |
|---|---|---|---|---|
| Application | Name, mobile number, PAN, address, employment details | Create and assess the loan application | Loan origination system, lender operations team | Clear notice and purpose-linked consent where required |
| KYC and verification | Identity document, photograph, date of birth, address proof | Verify identity and meet applicable obligations | KYC provider, authorised verification systems | Record the specific purpose, recipient and timestamp |
| Underwriting | Income, bank statements, credit history, existing liabilities | Assess eligibility, affordability and risk | Credit bureau, account-information or verification partners | Separate consent for data access and sharing where required |
| Servicing | Contact details, repayment history, support conversations | Service the account and communicate about the facility | Loan management system, customer-support vendor | Maintain access controls and an auditable processing trail |
| Marketing | Product interests, channel preferences, customer profile | Offer unrelated products or partner offers | Marketing platform, group entities, selected partners | Keep optional marketing consent separate and withdrawable |
The important design principle is separation. A customer agreeing to provide bank statements for assessing a loan should not automatically be treated as agreeing to receive promotional messages or to have the same data used for unrelated profiling.
A consent-led loan application
Sahyog Finance redesigns its application flow around four processing purposes rather than one bundled acceptance:
- Loan assessment: The applicant is shown a short notice explaining that the lender will use the information provided to process and assess the application.
- Credit and financial-data access: The applicant is told what financial information will be accessed, from which source, for what decisioning purpose, and which provider will receive it.
- Fraud prevention and security: The lender explains the relevant device, transaction or behavioural signals used to detect suspicious activity and protect the application process.
- Marketing: This is optional, unbundled and off by default. Declining it does not block the loan application.
Each action produces a separate consent record. The record should identify the Data Principal, the Data Fiduciary, the notice version, the purpose, the categories of data, the disclosed recipients, the channel, the date and time, and the affirmative action used. A screenshot alone is not enough: the lender needs a durable, retrievable consent artifact that can be connected to the relevant processing activity.
The DPDP Act describes consent as free, specific, informed, unconditional and unambiguous, conveyed through clear affirmative action. For a lender, that means a long, undifferentiated "I agree to everything" clause is a weak foundation for a purpose-specific data journey. IndiaConsent's product page describes consent receipts, immutable consent artifacts and instant revocation as core capabilities for this operating model.
What happens after withdrawal?
Two months after taking a loan, the customer opens the lender's privacy dashboard and withdraws consent for marketing. The withdrawal should not be treated as a general request to erase all loan records, because the lender may still need to process information connected to the existing facility, servicing, legal obligations or other recognised uses under applicable law.
The workflow should therefore do four things:
- Mark the marketing purpose as withdrawn immediately and stop new campaign activation.
- Propagate the withdrawal to the marketing platform, group entities and relevant partners.
- Preserve the original consent and withdrawal events as an auditable history.
- Review whether any data collected solely for marketing should be deleted or anonymised under the lender's retention schedule.
This is where consent management becomes an engineering problem. A dashboard that changes a preference but does not reach the systems that actually send messages is only a user interface, not an effective control.
The partner-sharing use case
Suppose Sahyog Finance uses three external providers: a credit bureau, a bank-statement analysis provider and a communications vendor. The lender should maintain a purpose-to-recipient map so that it can answer, for every data flow:
- What information is shared?
- For which purpose?
- On whose instructions or legal basis?
- Which vendor or partner receives it?
- When does the sharing stop?
- What deletion or return action follows expiry or withdrawal?
The same map supports procurement, privacy notices, vendor contracts, access reviews and incident response. It also helps the lender avoid a common failure mode: recording consent at the front end while downstream services continue processing an outdated purpose or an old version of the notice.
Building the operating model
A lender can implement this use case through five connected layers:
1. Purpose and data inventory
Create a living inventory of loan-origination and servicing purposes. Link each purpose to data categories, systems, recipients, retention rules and the consent or other permitted basis relied upon.
2. Notice and consent orchestration
Present short, intelligible notices at the moment data is requested. Keep mandatory application processing distinct from optional marketing and partner-sharing choices. Store the exact notice version accepted by the applicant.
3. Consent receipts
Generate a tamper-evident receipt for every grant, refusal, withdrawal and update. The receipt should be searchable by customer, application, purpose, vendor and time period without exposing unnecessary personal data to operational users.
4. Propagation and enforcement
Expose consent status to the loan origination system, customer relationship platform, marketing tools and partner integrations. A withdrawal event should trigger defined actions instead of relying on a manual email to each system owner.
5. Evidence and reporting
Give the privacy, compliance, audit and risk teams a common evidence layer. They should be able to demonstrate what the customer saw, what action the customer took, where the data travelled and what the lender did when the permission changed.
The business result
For Sahyog Finance, the outcome is not simply a compliance register. The lender gets a more reliable loan journey: fewer ambiguous forms, clearer customer choices, faster handling of privacy requests, and a smaller gap between the consent captured by the front end and the processing performed by the back end.
The use case also scales beyond personal loans. The same architecture can support credit cards, insurance distribution, wealth products, account aggregation, collections and partner-led offers. The purpose catalogue changes by product; the control pattern remains recognisable.
What's at stake if this goes wrong
A lender that cannot connect processing to a clear purpose may struggle to explain its decisions to customers, auditors or regulators. A lender that cannot propagate withdrawal may continue processing after a customer has changed their preference. And a lender that cannot produce the underlying consent artifact may have a policy on paper but no evidence that its digital journey followed it.
DPDP implementation in finance therefore needs to be treated as a continuous control loop: disclose, collect, record, use, monitor, withdraw, propagate and retain evidence. The consent receipt is the thread that ties those actions together.
Frequently Asked Questions
Does every activity in a lending journey require consent?
Not necessarily. The lender must assess whether processing is based on consent, a recognised legitimate use, or an applicable statutory requirement. The customer-facing notice and internal purpose map should reflect that distinction rather than treating every activity as either consent-based or unrestricted.
Should marketing consent be bundled with a loan application?
No. Marketing is generally an optional purpose and should be presented separately so that declining it does not prevent a customer from applying for or servicing a loan.
What should a consent receipt contain?
At minimum, it should connect the Data Principal and Data Fiduciary to the purpose, data categories, recipients, notice version, timestamp, channel and action. It should also record later withdrawals or changes in a way that can be audited.
What should happen when a borrower withdraws consent?
The lender should identify the affected purpose, stop processing that depends on the withdrawn consent, propagate the change to relevant systems and partners, and assess deletion, anonymisation and retention requirements. Withdrawal of one optional purpose does not automatically erase information needed for the existing loan relationship or legal obligations.
Can a lender rely on a consent record stored only by a vendor?
The lender should retain sufficient access to the authoritative evidence and ensure that vendor records can be retrieved, reconciled and tested. A contractual statement that a vendor has "captured consent" is not a substitute for operational visibility.
Related Articles & Internal Resources
- IndiaConsent's DPDP Compliance Guide for the Banking Sector
- Operationalising DPDP Consent Artifacts in Core Banking
- DPDP for E-Commerce: A Marketplace Use Case
- DPDP in Healthcare: Patient Consent & Health Data Sharing
- DPDP Compliance Checklist for Enterprises: 7 Critical Steps