Co-Lending Consent Chain: From Lead Source to NBFC to Bank

Picture a common scenario. A digital lending marketplace captures a borrower lead and passes it to an NBFC. The NBFC underwrites and fronts the customer interface. A partner bank books its share under a co-lending arrangement. Eighteen months later, a regulator or internal audit team asks a simple question during a review: on what consent basis did this borrower’s data move from the marketplace to the NBFC, then to the bank, and later to analytics and collection partners? Your teams scramble across three systems, each with its own consent wording and logs, and still cannot produce a single coherent trail.

This is why consent in co-lending has moved from being a screen designed by product teams to a governance topic that reaches the board. RBI’s co-lending directions place ultimate responsibility on regulated entities, especially banks, even when the front-end is an NBFC or marketplace. RBI’s digital lending guidelines expect explicit, auditable consent and clear attribution of roles between regulated entities and lending service providers. The Digital Personal Data Protection Act adds individual rights of access, correction, and withdrawal, backed by penalties. When several regulated entities touch the same borrower’s data, ambiguity in consent chains quickly becomes a supervisory and reputational issue.

At the same time, co-lending remains one of the more scalable ways for banks to acquire granular assets and for NBFCs and fintechs to access lower-cost capital. Growth depends on the ability to share underwriting and servicing data across partners with confidence. The institutions that treat consent as a shared, well-designed supply chain across lead source, NBFC, and bank will be able to add partners and products faster; those that defer the problem will find that consent gaps show up as audit findings, legal disputes, and constraints on how aggressively they can scale.

In a typical Indian co-lending journey, the borrower’s first interaction is rarely with the bank. A fintech marketplace, OEM finance app, or other lending service provider captures the lead, collects basic KYC details, employment information, and often obtains access to bank statements either through document upload or Account Aggregator. That entity might operate as a lending service provider under RBI’s digital lending framework and, under the DPDP Act, may be a data fiduciary for its own marketing uses while also acting as a processor for regulated lenders.

The NBFC usually sits in the middle. It receives the lead and supporting documents, performs underwriting, and issues preliminary offers. At this stage, consents are often taken for bureau pulls, KYC verification, and risk assessment. Where co-lending is involved, the NBFC also needs to share underwriting and KYC data with the partner bank under the master co-lending agreement. In practice, this data movement often relies on implied or broadly worded consents taken earlier at the marketplace or NBFC layer, without clearly naming all downstream entities or purposes.

The bank, as a co-lender, typically books its share of the exposure and may also onboard the borrower into its own systems for servicing, collections, and portfolio management. It may run its own fraud checks, access additional financial information through the Account Aggregator framework, and use the data for internal analytics and cross-sell assessments. Each of those uses requires a lawful basis under DPDP, often consent, yet the bank may be relying on consents captured by partners over which it has limited operational control.

Across this journey, consent is captured and reused at multiple points, but the design is usually fragmented. Consent notices differ in language, purpose descriptions, revocation options, and logging standards. When an auditor or a borrower asks how a particular data attribute flowed from the first screen to a downstream system, the record is often stitched together manually across partners. That fragmentation is the core design problem executives need to address.

Three regulatory strands define how consent should work in Indian co-lending: RBI’s co-lending directions, RBI’s digital lending guidelines, and the DPDP Act. None of them is written specifically for a lead source–NBFC–bank chain, but together they set clear expectations on customer communication, risk ownership, and data use.

RBI’s Master Directions on co-lending make it clear that while banks can share credit risk with NBFCs, they cannot outsource regulatory responsibility. The directions require a clear, written agreement between the bank and NBFC, and require that borrowers receive a transparent communication of the arrangement, the pricing, and the entity responsible for customer service. Even if the NBFC is the primary customer interface, the bank is expected to ensure that documentation, disclosures, and servicing meet regulatory standards. In consent terms, this means a bank cannot credibly claim it had no visibility into how borrower permissions were taken if those permissions underpin data flows that support its own exposures.^[1]

RBI’s digital lending guidelines sharpen expectations for journeys that involve apps and lending service providers. Regulated entities must ensure that borrowers give prior, explicit consent before their data is collected or shared, that only data strictly necessary for the product is taken, and that borrowers can access information about what was collected, for what purpose, and with which parties. Lending service providers are expected to act within tightly defined roles, and regulated entities must maintain logs of all digital lending transactions and data-related activities that can be produced during supervision or audit. This effectively requires that consent capture and subsequent data movement be traceable end to end, including where co-lending partner banks and NBFCs share information.^[2]

The DPDP Act adds a horizontal layer across all entities in the chain. Any organisation that determines the purpose and means of processing personal data becomes a data fiduciary, with obligations to issue clear notices, obtain free, specific, informed, and unambiguous consent where consent is the chosen lawful basis, honour withdrawals of consent, limit retention to what is necessary, and maintain reasonable security safeguards. In co-lending, both the bank and the NBFC are clearly data fiduciaries; many marketplaces and lending service providers will also qualify in their own right. Relying on a partner’s consent is only defensible if that consent notice explicitly names or categorises the relying institution, accurately describes the purposes, and explains how the borrower can later withdraw consent across all relevant uses.^[3]

The Account Aggregator and consent manager infrastructure sets a practical benchmark for what good consent looks like in financial data sharing. AA consents are granular about data type, purpose, frequency, and duration; they are time-stamped and revocable; and they rely on regulated intermediaries whose sole job is to manage consent-based data flows.^[4]

Once you accept that fragmented consents are a structural risk, the next decision is architectural: who owns the master consent record in your co-lending journeys, and how do partners rely on it? In practice, three models dominate: NBFC-led consent, bank-led consent, and a shared consent orchestrator that may incorporate Account Aggregator artefacts and a dedicated consent management platform.

Thinking of consent as a supply chain helps frame the design problem. Just as a manufacturing supply chain needs to know which part came from where, under what specifications, and when, an effective consent chain must track which borrower authorised which data to move to which entity, for which purpose, at what time, and under which legal and contractual terms. That chain must remain intact even when your lead source changes its app, your NBFC swaps a scoring engine, or your bank replaces its loan servicing system.

The starting point is identity binding. Every consent artefact should be reliably tied to a specific individual using identifiers that survive system migrations and partner changes—typically a combination of mobile number, the government-issued ID used for KYC, and internal customer IDs. The same identifiers should be used across lead source, NBFC, and bank so a consent given at one touchpoint can be unambiguously linked to the borrower records in all downstream systems. Alongside identity, you need a consistent purpose taxonomy: a controlled vocabulary of what you use data for, such as underwriting, co-lender onboarding, collections communication, analytics, regulatory reporting, and marketing. Without this, each partner describes purposes differently, and you cannot compare or reason about consents at portfolio scale.

Next comes logging and traceability. Each consent event—grant, partial grant, rejection, or withdrawal—should create a tamper-evident record that captures the notice shown, the purposes selected, the channel and timestamp, the entity on whose behalf consent was taken, and a machine-readable reference that downstream systems can store. Many institutions are moving towards hashed consent receipts, where a cryptographic hash of the consent payload is stored in a ledger and the human-readable notice is stored in application databases. This structure makes it much easier to demonstrate that a specific data flow—for example, from a lending service provider to an NBFC or from an NBFC to a bank—was covered by a particular consent at a particular time.

Revocation and retention policies then need to be operationalised across partners. Under DPDP, withdrawal of consent should be as easy as giving it, and should stop further processing based on that consent, subject to other lawful grounds for processing. In lending, this right co-exists with contractual and regulatory obligations, including minimum retention periods and reporting to credit information companies. Practically, that means designing data states: active processing where data can be used for all consented purposes; restricted processing where data is retained only for statutory, regulatory, or contractual obligations; and archived states for the end of retention periods. When a borrower withdraws consent via an app or call centre operated by any entity in the chain, that event should cascade so that NBFCs, banks, and material processors update the consent state consistently, even if they continue to hold the data for mandatory reasons.^[3]

Finally, governance must be embedded in partner contracts and internal oversight. Master co-lending agreements should define which entity acts as data fiduciary for which data uses, which consents are relied upon jointly, which processors are sub-contracted, what logging standards apply, and how quickly each party must update consent states when a change occurs. Internally, your risk and product committees should periodically review how consent coverage tracks against portfolio growth and supervisory expectations, rather than treating consent as a one-off documentation exercise.

As co-lending programmes grow in volume and partner count, it becomes difficult to manage consent states through custom fields scattered across loan origination, servicing, CRM, and analytics systems. A dedicated consent management layer can sit across these systems and partners, acting as the single reference for what each borrower has authorised across underwriting, co-lender onboarding, servicing, analytics, and marketing. That layer can also help reconcile DPDP rights such as withdrawal and erasure with sectoral retention obligations by driving consistent data states—such as active, restricted, and archived—across your internal and partner systems.

Digital Anumarti - Service positions itself as this kind of consent orchestration capability, designed around the DPDP Act and the Indian regulatory context. In other regulated sectors, it has been used to generate hashed consent receipts that travel with sensitive data, connect each consent to specific data processor agreements, and trigger controlled data movement when consent is revoked, such as moving records from operational databases to encrypted cold storage while preserving legally required retention. The same architectural principles are applicable to bank–NBFC–fintech co-lending chains, where institutions need verifiable, partner-aware consent trails without slowing down digital journeys. If you are evaluating whether to build or buy shared consent infrastructure for co-lending, it can be useful to benchmark your current architecture against what a specialised platform like Digital Anumarti - Service offers and then decide where it makes sense to partner. To explore that option in more detail, your teams can review material available on the Digital Anumarti - Service site.^[5]