Fintech Consent Architecture: Lender, Platform and Data Flow Clarity
Reviewed by CA Nikhil Gupta · Last reviewed 4 June 2026
A fintech consent architecture linking regulated entity, LSP, app, bureau, account aggregator, analytics, recovery and grievance records.
For broader context, see the Data Privacy, DPDP and Cyber Law — Full Compliance Hub.
A borrower should know who the lender is, what data each participant receives and which permissions are optional.
The DPDP framework is phased. The 14 November 2025 commencement notification brought specified institutional and enabling provisions into force immediately; Consent Manager-related provisions follow after one year; most operating duties and Rules follow eighteen months after Gazette publication. As of 22 June 2026, the control should distinguish current obligations from future-state DPDP readiness.
RBI digital-lending guidance places accountability on regulated entities for LSPs and DLAs used in their credit process.
Collection should be need-based, explicit and auditable; broad mobile-resource access is not justified by app convenience.
DPDP roles may differ from RBI commercial roles: an LSP can process on instructions for one purpose and independently for another.
What the organisation should understand
- The DPDP framework is phased. The 14 November 2025 commencement notification brought specified institutional and enabling provisions into force immediately; Consent Manager-related provisions follow after one year; most operating duties and Rules follow eighteen months after Gazette publication. As of 22 June 2026, the control should distinguish current obligations from future-state DPDP readiness.
- RBI digital-lending guidance places accountability on regulated entities for LSPs and DLAs used in their credit process.
- Collection should be need-based, explicit and auditable; broad mobile-resource access is not justified by app convenience.
- DPDP roles may differ from RBI commercial roles: an LSP can process on instructions for one purpose and independently for another.
- Consent withdrawal, loan servicing, fraud, legal retention and credit reporting should be separated rather than promised as one-click deletion.
For the connected rule, example or next step, see Fintech Data Sharing: Loan Apps, Consent and Grievance Records.
The five-point review
| Check | What to examine |
|---|---|
| Actors | Regulated entity, LSP, DLA and sub-vendor. |
| Data | KYC, bank, bureau, device and behaviour. |
| Purpose | Underwriting, servicing, fraud, recovery and marketing. |
| Signal | Consent, refusal, withdrawal and downstream propagation. |
| Grievance | Which entity owns response and evidence. |
For the connected rule, example or next step, see Account Aggregator Economics: Consent Architecture vs Lending Monetisation.
Practical example
A platform displays its own logo while the bank lender appears only in fine print. Data goes to a bureau, analytics SDK and collection vendor under one consent. The journey should identify each material role and purpose.
How to apply the framework
Create a participant-by-purpose map and a borrower-facing summary that matches contracts and technical flows.
Require the regulated entity to access consent and sharing logs directly rather than relying on the LSP to reconstruct them after a complaint.
Operating workflow
Define the real process before selecting the legal label
Identify the people, data, systems, purpose, owner, processor, user journey and failure scenario. Review actors, data and purpose together. A policy statement or vendor assurance cannot replace evidence of how the live product behaves.
Separate current obligations from scheduled DPDP controls
Apply the 14 November 2025 commencement notification provision by provision. Continue complying with currently operative CERT-In, banking, telecom, insurance, employment, consumer, contract and criminal-law requirements. Build the scheduled DPDP workflow now, but do not describe a future provision as already enforceable.
Test and preserve evidence
Run the workflow in the live or controlled test environment. Preserve screenshots, approvals, logs, vendor responses, user communications, exceptions and remediation. Assign a named owner and completion date to every failed control so management can distinguish an operating safeguard from a policy intention.
Action checklist
- Map all participants.
- Minimise fields and permissions.
- Separate underwriting and marketing.
- Store borrower-level consent evidence.
- Control downstream vendors.
- Provide lender-visible grievance records.
Evidence to keep
- Role and data-flow map
- Borrower notices and consents
- LSP and vendor contracts
- Sharing logs
- Grievance and withdrawal records
Warning signs
- Lender identity hidden
- One consent for loan and unrelated offers
- Contact-list access
- Lender cannot access logs
- Vendor reuse for independent marketing
Finin2min takeaway
Privacy and cyber maturity are visible in operating behaviour: what the organisation collects, who can use it, how vendors are controlled, how users exercise choices, how incidents are handled and whether evidence survives scrutiny.
Frequently Asked Questions
Source and review trail
Use the current official instrument, portal or regulator publication before acting. This panel separates the category authority from page-specific references.
- Primary category
- Data Protection, Cyber & IT Law
- Official starting point
- www.meity.gov.in