- Consent recorded per purpose, with notice version and timestamp
- Withdrawals propagated to internal systems and partners as tracked events
- Retention rules that delete data on schedule, with proof
- A single view of who holds a customer's data and why
- Evidence ready for audits and data principal requests
Anonymised composite. Client names, identifying details and confidential figures are withheld; public facts are cited in the references.
The situation
A digital lender in India served customers through a mobile app, with credit decisions supported by bureaus, co-lending partners, verification vendors, a collections agency and marketing platforms. Consent was a set of checkboxes at sign-up. Personal data flowed to partners through file drops and APIs built over years by different teams, and nobody could answer a simple question for a single customer: who holds this person's data, for which purpose, and what happens if they withdraw?
Why now. The Digital Personal Data Protection Rules were notified on 13 November 2025, bringing the DPDP Act, 2023 into force in stages over 18 months12. Registration of consent managers applies after the first year, which falls in November 2026, and most core obligations for data fiduciaries apply from around May 20273. For a lender whose business runs on personal and financial data, that is not much time to rebuild how consent works.
What had to be true
- Consent per purpose, not one blanket checkbox, with the notice version recorded.
- Withdrawal as easy as giving consent, and actually honoured by every system and partner.
- Retention that deletes: data removed when its purpose ends, with evidence.
- Breach detection and reporting fast enough to meet notification duties.
- Room for consent managers, so customers can manage consent through a registered intermediary.
Architecture
The data flow, end to end
- NoticeCustomer sees a clear notice per purpose in the app or via a consent manager
- RecordConsent written to the ledger with purpose, notice version and time
- EnforceAPIs and pipelines check the ledger before using the data
- WithdrawA withdrawal is published as an event to every internal consumer and partner
- AcknowledgeEach consumer confirms and records the action taken
- Retain or eraseJobs delete data when purposes end and write proof to the audit store
The hard part: proving a withdrawal reached everyone
Recording consent is easy. Proving that a withdrawal stopped processing everywhere is not, because data has already been copied to analytics, partners and vendors. The design treated each withdrawal as an event on the stream, with every consumer and partner integration required to acknowledge it. Tracing producers and consumers with OpenTelemetry links a published event to each receiving service in one trace4, which turns propagation into something you can query and show to an auditor.
A consent you cannot withdraw everywhere is not really consent. Design withdrawal first; recording consent is the easy half.
Partners without event integrations received withdrawals through an authenticated API with mandatory acknowledgement and a retry queue. Unacknowledged withdrawals raised alerts to the partner owner, not just to engineering. Related reading: change data capture and event streams and data contracts.
How it ran
- Purpose and notice wording
- Retention schedule
- Partner contract updates
- Consent ledger and APIs
- Withdrawal events and acknowledgements
- Retention and erasure jobs
- Data flow inventory
- Event or API integration
- Acknowledgement SLAs
- Data and partner inventory
- Purpose catalogue
- Gap assessment
- Consent ledger
- New notices in the app
- Policy checks at APIs
- Withdrawal events
- Partner gateway
- Tracing and alerts
- Retention and erasure
- Consent manager integration
- Audit evidence
Key decisions and trade-offs
| Decision | Alternative | Why |
|---|---|---|
| Append-only consent ledger | Consent flags on the customer record | History, notice versions and audit evidence come built in |
| Withdrawal as an event with acknowledgement | Nightly batch updates | Fast propagation and proof of delivery per system |
| Purpose tags on data in analytics | One shared data lake with no purpose context | Lets retention and access rules work on analytical copies too |
| Deletion with proof | Soft-delete flags | Erasure has to be real and demonstrable |
| Design for consent managers now | Wait for the registry to mature | Interfaces are cheaper to add before integrations multiply |
What I'd do again, and differently
Again: start with the data and partner inventory, and make withdrawal the first feature built. Differently: bring partners in earlier. The longest delays came from contract changes and vendors without any way to receive a withdrawal, not from the engineering. For broader context on rules across markets, see where I work and how another data protection law shapes AI architecture.
If you are preparing an Indian platform for the DPDP Rules, my work with Indian companies explains how I approach it, or analyse your challenge and bring the result to a call.
- 1India's Digital Personal Data Protection Act, 2023 brought into forceHogan Lovells · Nov 2025
- 2Update: India's digital personal data protection framework comes into effectAZB & Partners · Nov 2025
- 3
- 4Instrumenting Apache Kafka clients with OpenTelemetryOpenTelemetry blog (Paolo Patierno) · 6 Sep 2022