Most digital lending arrangements we review were drafted as ordinary service contracts and then patched for the RBI's directions. That order is the problem — the framework changes who may hold the customer, who may collect money, and what must be disclosed before the borrower commits.
A pattern shows up repeatedly when we are asked to review a digital lending stack. The commercial arrangement between the lender and its technology partner was negotiated first, as a services contract with a revenue share. The Reserve Bank of India's digital lending directions were then addressed by adding a compliance schedule at the back. The schedule says the right things. The operative clauses in the body of the agreement contradict it.
That is not a drafting nicety. The framework allocates responsibility in a way that a services contract, left to its own logic, will tend to reverse.
The borrower belongs to the regulated entity
The starting principle is that the regulated entity — the bank or NBFC whose balance sheet carries the loan — remains answerable for the lending relationship regardless of how much of the journey a partner operates. A loan service provider may source the customer, run the interface, score the application and service the account. None of that transfers the regulatory obligation.
Where agreements go wrong is in the provisions that assume otherwise: exclusive control of the customer relationship granted to the platform, restrictions on the lender contacting its own borrowers, or data and marketing rights that treat the borrower base as the platform's asset. Those clauses are commercially understandable and regulatorily untenable.
Disclosure: the Key Fact Statement is the document that matters
Before the borrower commits, they must receive a Key Fact Statement setting out the all-in cost of the loan expressed as an annual percentage rate, together with the recovery mechanism, the grievance officer's details and the cooling-off period. The rule that gives this teeth is the corollary: a charge not disclosed in the KFS cannot be recovered from the borrower later.
In practice this requires the product and legal teams to agree on something they often have not — a single number. Processing fees, insurance premiums bundled into the disbursement, platform convenience charges and penal amounts all have to be accounted for. We have seen arrangements where the platform's fee was structured as a separate charge to the borrower precisely so that it sat outside the lender's rate card. Under the current framework that is a disclosure failure with a direct revenue consequence.
Money should not pass through the partner
Disbursement must go from the lender's account to the borrower's account, and repayment from the borrower's account to the lender's, without the loan service provider's pool account in between. The exception is narrow and specific. This single requirement invalidates a good number of older escrow-and-sweep designs, and it is worth checking against the actual payment flow rather than the flow diagram in the agreement, because the two are not always the same.
Data: need-based, consented, and not the platform's to keep
Data collection must be limited to what the product needs, with the borrower's explicit consent and an option to withdraw it. Access to the borrower's contact list, media files and location — historically the source of the sector's worst conduct — is outside what is permissible for a lending app. The loan service provider must not store borrower data other than basic minimum data required for its function.
The Digital Personal Data Protection Act, 2023 now runs alongside this. The two regimes have different architectures and are best handled together at the design stage: the RBI's rules restrict what may be collected in this specific context, while the DPDP Act governs notice, purpose limitation, retention and the borrower's rights over the data once collected. Building consent flows for one and retrofitting the other is how organisations end up with a notice that does not describe what the product does.
Recovery and grievance
Recovery agents must be identified to the borrower and their conduct is the regulated entity's responsibility. A nodal grievance redressal officer must be named and reachable, and unresolved complaints escalate to the RBI's ombudsman scheme. Agreements should therefore specify not merely that the partner will comply with recovery norms, but the audit rights, conduct standards, escalation timelines and termination consequences that make compliance verifiable.
What to do with an existing arrangement
- Map the actual payment flow, end to end, and compare it with the agreement. Discrepancies here are the most common and the most serious.
- Reconcile the KFS against every charge the borrower actually pays, including anything invoiced by the platform.
- Review the app's permissions and the data the partner stores, then align the notice, the consent flow and the contract with what the product genuinely requires.
- Check the operative clauses — customer relationship, data rights, exclusivity — for anything that contradicts the compliance schedule, and fix the body of the agreement rather than the schedule.
- Confirm the cooling-off mechanism works in the product, not just on paper.
None of this is difficult once the arrangement is looked at as a regulated lending relationship that happens to be delivered digitally, rather than as a technology partnership that happens to involve credit. The sequence of drafting is what usually needs to change.