Not Just a Marketplace: Lender Primacy, Disclosures and Consent Architecture in Digital Loan Sourcing

– Archisman Bhattacharjee (finserv@vinodkothari.com)

Introduction

Digital lending in India has entered a phase where the architecture of customer acquisition itself is treated as a regulated function. What began as a technology-led convenience layer has evolved into a tightly governed framework in which the design of digital interfaces, the sequencing of disclosures, the structure of consents, and the allocation of roles between regulated lenders and technology intermediaries are all matters of legal consequence. The focus of regulation is no longer confined to how loans are sanctioned or serviced; it now squarely extends to how borrowers are first sourced, presented with offers and invited into a lending relationship.

This shift is driven primarily by the digital lending chapter introduced under the Reserve Bank of India (Non-Banking Financial Companies – Credit Facilities) Directions, 2025 (“Directions”), which adopt an activity-based approach to supervision. Under this framework, regulatory responsibility follows the function performed, irrespective of whether that function is carried out by an RE, a Digital Lending App (DLA), or a Lending Service Provider (LSP). Running alongside this regime is the Digital Personal Data Protection Act, 2023 (DPDPA), which establishes a consent-centric statutory structure for the collection, use, sharing, storage, and erasure of personal data. In a data-intensive sector such as digital lending, these two frameworks intersect most sharply at the sourcing stage, where borrower data is first captured and borrower choice is first shaped.

Against this backdrop, loan sourcing through DLAs can no longer be understood as a purely commercial or marketing activity. It is the legal gateway through which lender rights are established, disclosures are made, and the initial consent architecture is constructed. The manner in which a platform displays participating lenders, explains matching logic, presents privacy policies and seeks borrower authorisations has direct implications for regulatory compliance and enforceability of the lending relationship.

This article examines digital loan sourcing through DLAs as a distinct regulated activity. It analyses how RBI’s digital lending framework and the DPDPA together reshape the design of sourcing interfaces, the presentation of lender identity and the structure of purpose-specific and non-bundled consents. The discussion focuses on the practical and legal expectations from REs and their technology partners at the sourcing stage and highlights why compliance must be embedded into product architecture rather than treated as an overlay.

Regulatory Allocation of Roles and the Principle of Lender Primacy

The RBI framework recognises that digital lending ecosystems may involve multiple participants, including technology platforms, analytics providers etc. Notwithstanding this multiplicity, the Directions anchor accountability on the regulated entity (RE) that extends credit. The RE is treated as the principal, while DLAs and LSPs are treated as agents or service providers whose acts and omissions are attributable to the RE for regulatory purposes.

This principle of lender primacy has two important consequences:

1. First, the RE cannot contractually shift regulatory liability to an LSP or DLA. 
2. Second, the RE must exercise demonstrable control over the design of digital journeys, the content of customer interfaces, and the manner in which data is collected and processed.

From an operational standpoint, this requires REs to move beyond generic outsourcing agreements and adopt a function-wise allocation model. Each discrete digital lending activity such as onboarding, KYC facilitation, credit assessment support, servicing, and recovery must be mapped to a responsible RE function and a supporting LSP function. This mapping must be reflected in contracts, internal policies, and system architecture.

Loan Sourcing as a Regulated Activity

Loan sourcing through a DLA is often viewed as a front-end marketing or customer acquisition function. Under the regulatory framework introduced through the Directions, however, sourcing is treated as a regulated activity because it directly affects how a borrower chooses a lender and on what terms the borrower enters into a credit relationship. The regulatory focus therefore begins at the first point of contact between the borrower and the digital platform, and not only at the stage of sanction or documentation.

At the very first interaction on the DLA, the borrower must clearly specify the name of the RE(s) that have lending arrangements with the platform. This requirement flows from paragraph 7(1) of the Directions, which provides that where an LSP has arrangements with multiple lenders, the LSP shall provide a digital view of all loan offers matching the borrower’s request and also disclose the names of the lenders. The same paragraph further requires disclosure of the names of unmatched lenders, i.e., regulated lenders whose products are available on the platform but are not being shown to the borrower pursuant to the platform’s matching logic.

In practical terms, this translates into the following design expectations:

1. The RE’s name should be visible before the borrower starts the application and not only at the final acceptance stage.
2. If more than one RE is integrated, the platform should display all matched REs upfront along with the names of the unmatched lenders

The Directions also make it clear that a DLA cannot present itself, directly or indirectly, as the lender. Under paragraph 6(1) (which requires a contractual arrangement clearly defining roles between RE and LSP (read with paragraph 6(7) which states that outsourcing shall not dilute or absolve the RE of its regulatory obligations, the lending relationship always remains between the borrower and the RE, and not with the DLA or LSP.

Accordingly, certain minimum presentation standards follow:

1. The RE’s branding/name should be clearly visible on key screens such as product listing, offer page and acceptance page.
2. Messages, notifications and emails should indicate that the loan is being offered by the RE, even if routed through the platform.
3. Loan agreements and key documents must clearly name the RE as the lender, with the DLA/LSP described only as a facilitator or service provider.

The overall presentation should consistently reinforce who the actual lender is.

The Directions further expect DLAs to function as neutral platforms. While paragraph 7(2) allows the LSP to adopt a mechanism to match borrower requests with lender offers, such mechanisms must operate in a fair and transparent manner (Refer to our article on Principles of Neutrality for Multi-Lender Platforms here)

Onboarding as a Consent-Oriented Legal Process

Traditionally, onboarding in lending has been understood as the stage where KYC is completed and the customer’s creditworthiness is assessed. Under the combined framework of the Directions and the DPDPA, onboarding now needs to be seen more broadly. It is the stage at which the borrower authorises how personal data will be collected and used, and at which the borrower begins a regulated relationship with the RE.

This broader understanding comes from the way the Directions regulate digital lending. 

1. Para 6(1) requires digital lending through an LSP to be governed by a written agreement that clearly sets out the roles and responsibilities of the RE and the LSP. 
2. Para 6(7) further clarifies that outsourcing to an LSP does not reduce or shift the RE’s regulatory responsibility. 

Together, these provisions show that onboarding is not just a technical step. It is the point at which the RE’s legal and regulatory obligations towards the borrower attach.

The Onboarding process includes three legal functions at the same timeIt enables compliance with KYC, customer due diligence and credit underwriting. The Directions require REs to follow the RBI’s KYC Directions and disburse loans only after such compliance (para 46 of the Directions). In addition, personal data for onboarding and KYC can be collected only on a need basis and with the borrower’s prior and explicit consent, supported by an audit trail [paragraph 13(1) of the Directions].

Onboarding establishes the contractual foundation of the loan. Under para 9(3) of the Directions, once the loan is executed, digitally signed copies of the KFS, sanction letter, terms and conditions and product summary must automatically be sent to the borrower. 

Onboarding also creates the consent framework for personal data processing across the lending lifecycle. Para 13(2) of the Directions requires that borrowers must have the option to give or deny consent, restrict sharing with third parties, revoke consent and request deletion or forgetting of data. Paragraph 13(3) further requires that the purpose of each consent be disclosed at the relevant stage of the interface, and paragraph 13(4) requires explicit consent before sharing personal data with any third party (unless required by law).

These RBI requirements align closely with Section 5, Section 6 and Section 7 of the DPDPA.

Read together, these rules mean that onboarding cannot be reduced to a single “I agree” screen. A single, blanket acceptance of loan terms, privacy policy and all consents in one click is difficult to reconcile with the requirement for specific and purpose-based consent.

Instead, a compliant onboarding flow should, in substance, distinguish between:

1. acceptance of loan terms and conditions,
2. authorisation for KYC and credit checks, and
3. consents for different types of data processing like that of advertisement/marketing of the Lender’s products/cross-marketing of other products.

Identification of the Data Fiduciary in Digital Lending

The DPDPA introduces the concept of a “data fiduciary” under Section 2(i) of the DPDPA. Section 2(i) defines a data fiduciary as:

“any person who alone or in conjunction with other persons determines the purpose and means of processing of personal data”

In most digital lending structures, the RE determines why personal data is collected (to assess creditworthiness, comply with law, service the loan) and how it is processed. Accordingly, the RE will ordinarily be the data fiduciary.

DLAs and LSPs, when they process data strictly on the instructions of the RE, function as data processors [means any person who processes personal data on behalf of a Data Fiduciary, refer Section 2(k) of DPDPA]. However, this characterisation is not automatic. 

This distinction is not merely theoretical. It determines who must issue notices, who bears liability for non-compliance, and who must respond to data principal rights. REs must therefore undertake a detailed data mapping exercise to identify fiduciary and processor roles and disclose the same transparently to borrowers. 

However in certain cases the DLA may also be considered as data fiduciary. If an LSP independently determines purposes such as using borrower data to build its own analytics products or to cross-sell unrelated services it may itself become a data fiduciary for those purposes. Eg:  the purpose of account creation with the DLA the borrower provides its personal data. 

Display and Acceptance of Privacy Policies Prior to Data Sharing

One of the central premises on which the RBI’s digital lending framework rests is consent-based collection and processing of borrower data. The Directions treat digital lending as a consent-driven ecosystem and require that personal data be collected and processed only on the basis of the borrower’s prior and explicit consent, with appropriate audit trails [para 13(1) of the Directions]. Borrowers must also be provided meaningful control over their data, including the ability to give or deny consent, restrict sharing with third parties, revoke consent and seek deletion or forgetting of data [paragraph 13(2) of the Directions]. In effect, consent is intended to operate as the legal foundation for data processing at every stage of the digital lending journey.

Under DPDPA, informed consent further requires that a data principal [Refer Section 2(j) of DPDPA] know who will process their personal data and for what purposes. In the digital lending context, this requirement cannot be satisfied merely by displaying the privacy policy of the DLA or the LSP. While the platform may be the point of collection, it is the RE that ultimately uses the data to undertake credit assessment, take lending decisions, report to credit bureaus etc. The borrower therefore needs visibility into the privacy practices of the RE as well.

Consequently, before any borrower data is shared with an RE, the DLA should display:

1. its own privacy policy [This should ideally be displayed prior to the account creation by the Borrower] ; and
2. the full privacy policy of each matched RE whose loan offer is being presented.
3. Names of third parties and purposes for which such data is shared with such third parties.

Only after the borrower has had an opportunity to review these disclosures and has selected a lender should consent for sharing data with that RE be sought. Seeking consent first and disclosing the RE’s identity or privacy practices later weakens the concept of informed consent and risks reducing consent to a mere formality.

Although the DLA may technically collect the data, the RE is the entity that uses the data in ways that directly affect the borrower’s rights, obligations and financial exposure. Requiring visibility of the RE’s privacy practices at the point of lender selection ensures that consent is meaningful, specific and anchored to the entity that truly determines the outcome of the data processing.

Content and Structure of Consent Notices

Consent notices in digital lending must be purpose-linked, intelligible, and granular. At a minimum, the notice must specify the identity of the RE and the LSP, the categories of personal data being collected, the purposes for which each category is collected, the names of recipients with whom data may be shared [Refer para 13(4) of the Directions] and the rights available to the borrower, including the right to withdraw consent along with such other requirements as provided under Section 5 of the DPDPA read along with Rule 3 of Digital Personal Data Protection Rules, 2025.

Granularity and Non-Bundling of Consent

One of the most important shifts introduced by the RBI’s digital lending framework, and reinforced by the DPDPA, is the clear rejection of bundled consents. Borrowers should not be required to accept multiple, unrelated data-processing purposes as a single condition for accessing credit, except to the limited extent that such processing is strictly necessary for providing the loan. [Also refer to our comments on the Draft Amendment Directions for “Advertising, Marketing and Sales of Financial Products and Services by Regulated Entities”, which discuss the management of bundled consents here]

This principle flows directly from the Directions, which require that borrower data be collected only on a need basis and with prior and explicit consent, and that borrowers be given the option to give or deny consent, restrict sharing, revoke consent and seek deletion or forgetting of data [para 13(1) and 13(2) of the Directions]. The DPDPA similarly requires consent to be free, specific, informed and unambiguous as per Section 6 of the DPDPA.

Accordingly, as a matter of design, separate consents should ordinarily be obtained for different categories of processing, such as:

1. onboarding and KYC including access to mobile resources like camera,location etc.,
2. credit assessment and underwriting,
3. marketing and cross-selling, and
4. sharing of data with third parties.

Each of these consents should be capable of being given or refused independently, and should also be independently revocable. 

At the same time, it is necessary to recognise a practical and legal nuance. Although digital lending is a consent-based ecosystem, certain categories of data processing are regulatorily mandatory for REs for the purpose of processing and continued operation of the loan. For example, collection of KYC data (including from CKYCR), obtaining bank account statements and collection of information relating to security or collateral (in case of secured lending) are required under applicable RBI regulations. Even though explicit borrower consent is still required for such collection, denial of consent in these cases would make it impossible for the RE to comply with its regulatory obligations.

In such situations, if a borrower refuses consent for mandatory processing, the RE would have a legitimate basis to deny the loan or discontinue the onboarding process, since the service cannot be provided without that data. 

Credit Assessment and Underwriting Support

DLAs and LSPs may facilitate the collection of financial information and apply analytical tools and in most cases provide underwriting support to some extent to the RE. However, the legal decision to extend credit must be attributable to the RE. Automated decisioning systems do not dilute this responsibility.

From a data protection standpoint, the use of personal data for credit assessment must remain within the scope of the purposes disclosed at onboarding. Any expansion of purpose for example, using the same data for unrelated analytics requires fresh consent.

Multi-Lender Platforms and Tiered Consent Architecture

Multi-lender platforms raise distinct regulatory and operational issues because a single borrower’s data may be relevant to and potentially accessed by multiple REs. To address these risks, a legally sound and borrower-centric model should be built around a tiered and purpose-specific consent architecture, combined with transparent and neutral presentation of loan offers.

1. At the first level, the borrower should provide consent to the DLA or LSP to collect and process basic personal data and data towards lending requirements of the borrower, such as name, address, loan requirements etc. only for the limited purpose of identifying suitable lenders. At this stage, the data use must be confined to matchmaking and eligibility assessment and not for loan processing or credit decisioning by any specific RE.
2. At the second level, once potential REs are identified, the borrower must be shown lender-specific disclosures and must actively choose which RE(s) they are willing to share their data with. Separate and granular consent should be taken for each selected RE, clearly stating what data will be shared and for what purpose.
3. At the third level, after the borrower selects a particular lender and decides to proceed, a final and explicit consent must be obtained for end-to-end loan processing by that RE, including underwriting, documentation and servicing.

In addition to the above consent framework, the platform architecture should ensure transparency and fairness in how loan offers are displayed [Refer para 7 of the Directions along with our writeups on the same here, here and here]

Servicing, Right to Withdraw Consent, and In-App Design

The right to withdraw consent, as recognised under the DPDPA, is a central pillar of the consent-based data protection framework. In the context of digital lending, this right cannot remain theoretical. It must be practically and meaningfully operationalised within the design and functioning of the DLA so that borrowers are able to exercise real control over their personal data.

Operationalising withdrawal of consent within the DLA

DLAs should ideally provide a clearly visible and easily accessible “Privacy and Consents” or “Manage Consents” section. This section should allow borrowers to view, in a consolidated manner, all consents previously provided, including the purpose of each consent, the entity to whom it was given, and the date on which it was captured. Withdrawal should be enabled through simple mechanisms, such as toggle buttons or “Withdraw” options against each consent item, without requiring the borrower to navigate multiple screens or submit offline requests.

From a system-design perspective, withdrawal should trigger automated workflows across the digital lending ecosystem. Once a borrower withdraws a particular consent, the DLA and connected systems should immediately communicate this instruction to the relevant RE(s) and LSP(s) and internal access controls should be updated to prevent further processing for the withdrawn purpose [except in cases where processing is required as per legal requirements]. Audit logs evidencing the withdrawal, time-stamp, and downstream actions should be maintained.

Purpose-specific withdrawal rather than blanket withdrawal

In digital lending, withdrawal of consent should be purpose-specific and entity-specific, rather than a single blanket option, so that borrowers can exercise granular control. Broadly, three distinct categories of withdrawal should be made available:

1. Withdrawal of consent for processing by the LSP / DLA
   This covers situations where the borrower no longer wishes the LSP or DLA to process personal data (for example, for analytics, profiling, or ancillary services). Upon such withdrawal, the LSP/DLA must cease further processing for those purposes and, subject to retention obligations, delete or anonymise the data in its possession.
2. Withdrawal of consent for sharing or processing by third-party service providers
   Where data is processed by outsourced vendors (for example, cloud hosting, communication service providers, or analytics partners), borrowers should be able to withdraw consent for such onward sharing. The LSP/RE, as the primary data fiduciary, must then ensure that these third parties are instructed to stop processing and to delete data..
3. Withdrawal of consent for processing by a specific RE
   This applies once a borrower has engaged with a particular lender. Withdrawal at this level would mean that the RE can no longer continue processing personal data for digital loan servicing or further lifecycle activities, except to the extent permitted under law.

Presenting these options separately ensures that borrowers understand who is processing their data and for what purpose, and can withdraw consent in a targeted manner.

Consequences of withdrawal and borrower communication

Certain withdrawals particularly those relating to core loan processing by an RE will have practical consequences. For instance, the RE may be unable to continue servicing the loan, issue statements, or provide app-based support. DLAs must clearly and transparently communicate these consequences at the time the borrower initiates withdrawal, so that the borrower makes an informed choice.

By contrast, withdrawal of consent for marketing or promotional communications should result in immediate cessation of such communications, without affecting the borrower’s ability to access or service an existing loan.

Data Retention and Deletion

Under the DPDPA, withdrawal of consent ordinarily requires a data fiduciary to cease processing personal data for the specific purpose for which consent has been withdrawn. At the same time, the statute recognises that deletion is not an absolute or mechanical consequence of withdrawal. Where retention of personal data is necessary to comply with a legal obligation or is otherwise permitted under law, continued processing may take place. In this regard, Section 8(7) of the DPDPA expressly permits processing of personal data  even in case of a request of withdrawal provided that processing is required for compliance with applicable laws.

In the digital lending context, this means that even if a borrower withdraws consent, an RE may still be required to retain certain categories of data, including KYC records maintained under regulatory directions, credit underwriting documents, transaction histories, audit trails, and other records necessary for regulatory inspections, dispute resolution, or statutory reporting. Such retained data must, however, be strictly ring-fenced for compliance and record-keeping purposes alone. It should not be used for fresh profiling, marketing, cross-selling, analytics unrelated to compliance, or any new processing purpose that would otherwise require consent.

Obligations of DLAs / LSPs in relation to retention and deletion

DLAs and LSPs typically function as data processors or, in certain limited contexts, as independent data fiduciaries for specific purposes (such as account management, platform security, or customer support). Unlike REs, they generally do not have direct regulatory mandates requiring long-term retention of borrower data. Consequently, their retention obligations are primarily purpose-driven and contractually structured.

Where a borrower withdraws consent, DLAs and LSPs should, as a default position, delete or irreversibly anonymise personal data once the purpose for which it was collected has ceased. Retention by an LSP/DLA may continue only in limited circumstances, such as:

1. Where the LSP is contractually required to store data on behalf of an RE as a processor to support the RE’s legal or regulatory obligations.
2. Where retention is necessary for platform security, fraud prevention, or to maintain audit logs demonstrating compliance with law.
3. Where certain minimal data is required to manage user accounts or enforce platform-level obligations.

The precise categories of data that may be retained by a DLA or LSP will therefore depend on the function being performed. For example, an LSP providing KYC or underwriting support may temporarily retain identity documents or decisioning logs, whereas a DLA operating a user-facing interface may retain limited account metadata.

Periodic evaluation and data minimisation

A key operational safeguard should be the introduction of periodic data retention reviews by DLAs, LSPs, and REs. These reviews should assess:

1. Whether each category of personal data continues to be necessary for the stated purpose.
2. Whether the purpose itself still subsists.
3. Whether any data can be deleted, anonymised, or archived with restricted access.

Such periodic evaluations help ensure compliance with the principle of data minimisation and reduce the risk of excessive or indefinite retention.

Data that a DLA may retain even after loan closure

Even where the borrower relationship with an RE has ended and a deletion request is raised, a DLA may still retain limited data that is necessary for platform functioning or compliance, such as:

1. Basic account identifiers (for example, user ID or login credentials) to prevent duplicate or fraudulent re-registrations.
2. Logs evidencing consent capture, withdrawal, and grievance handling.
3. Security and access logs required for cyber-security monitoring or forensic purposes.

This retained data should be minimal, access-restricted, and not used for any commercial or profiling purpose or any other purpose for which the DLA/LSP has not obtained the consent of the borrower.

Routing of withdrawal and deletion requests

From the borrower’s perspective, the DLA should operate as a single-window interface for raising withdrawal and deletion requests. Once such a request is made, the DLA/LSP should be responsible for internally coordinating with the relevant RE(s) and downstream processors, ensuring that:

1. Processing ceases for the withdrawn purpose.
2. Deletion or anonymisation is carried out wherever legally permissible.
3. Retention, where necessary, is appropriately justified and documented (under the storage/retention policy)

Borrowers ideally should not be required to separately approach multiple entities within the digital lending ecosystem.

Data Storage, Localisation and Segregation in Digital Lending Ecosystems

In digital lending ecosystems, it is common for borrower data to be stored on infrastructure owned or managed by DLAs or LSPs. This is particularly prevalent where the DLA or LSP forms part of the same corporate group as the RE, such as a holding company, subsidiary, or fellow group entity and the group operates a centralized technology stack supporting customer acquisition, underwriting, servicing, and analytics. From a commercial and operational standpoint, such centralized architectures promote efficiency, standardisation, and consolidated oversight. At the same time, they raise important regulatory considerations under the digital lending framework issued by the RBI, especially when DLAs operate in multi-modal capacities and perform multiple functions across the lending lifecycle.

A central regulatory touchstone in this context is the principle embedded in paragraph 14(1) of the Directions, which permits LSPs to retain only such basic and minimal data as may be necessary to perform their contracted services. Where complete borrower datasets are housed on servers controlled by a DLA or LSP, regulators may question whether the requirement of minimal data retention is being complied with in substance, even if the arrangement is justified on operational grounds. The issue, therefore, is not merely where the data resides, but who can logically access it and for what purpose.

To align centralized hosting models with regulatory expectations, REs must ensure that access restriction mechanisms are implemented. The DLA or LSP should be able to view or process only that limited subset of borrower data that is strictly required for discharging its specific contractual functions. Physical or technical hosting of data on LSP infrastructure should not translate into unfettered logical access. This mandates granular role-based access controls, purpose-based permissions and well-defined data access matrices mapped to each service function. In addition, REs should periodically review and reassess these access arrangements to evaluate whether the scope of visibility granted to the DLA or LSP remains justified in light of evolving business processes.

These controls assume even greater importance once the borrower relationship has concluded, such as upon closure of a loan account. While REs may be required to retain certain records for statutory, regulatory, or audit purposes, there would ordinarily be no continuing operational need for an LSP or DLA to access such data. Accordingly, access rights should be curtailed or revoked post-closure, reinforcing the principle that data access must be dynamic, purpose-bound, and proportionate to the services being rendered.

The risks associated with centralized hosting are amplified in multi-lender digital lending models, where a single DLA or LSP services multiple regulated lenders and may perform several roles across the lending chain. In such structures, the Directions implicitly require strict compartmentalisation. Data relating to each lender must be logically segregated supported by strong access controls, encryption, and continuous monitoring, so that information pertaining to one lender’s customers is not accessible to another lender or to unauthorized personnel within the DLA or LSP. The objective extends beyond technical hygiene to preventing cross-pollination of data, profiling across platforms, or indirect commercial exploitation of borrower information. Practically, this means REs must insist at the contracting stage on demonstrable segregation mechanisms and reserve audit and inspection rights to verify their ongoing effectiveness.

Alongside access and segregation, data localisation constitutes another foundational requirement. Para 14(4) of the Directions mandate that all borrower data be stored only on servers located within India. Where any processing occurs outside India, such data must be deleted from overseas servers and brought back to India within 24 hours. 

Conclusion

Digital loan sourcing through DLAs has moved decisively from being a mere customer acquisition channel to a regulated entry point into the lending relationship. The combined effect of the RBI’s digital lending framework and the DPDPA is that the very first borrower interaction must now be legally structured, transparent, consent-driven and anchored to the identity and accountability of the RE as the true lender. Sourcing interfaces must therefore be designed not as neutral marketplaces alone but as regulated gateways that reflect lender primacy, enable informed and granular consent and embed data minimisation and purpose limitation by design. For REs, compliance in this area is no longer about post-facto documentation; it is about shaping the architecture, flows, and disclosures of the DLA itself. Those institutions that treat sourcing as a core regulated function rather than a peripheral marketing activity will be better positioned to withstand regulatory scrutiny and build sustainable, trustworthy digital lending models.

---

Other resources on Digital Lending:

Resources on Digital Lending