Co-lending has become the default growth route for a large number of Indian NBFCs. The originating NBFC sources and underwrites, a bank funds the larger share, and the customer sees one loan. Operationally it works. The part that receives far less attention is what happens to the customer's documents when the file crosses from one regulated entity to the other — because at that moment, a single Aadhaar copy becomes two Aadhaar copies, held by two organisations, under two retention policies, with two independent breach exposures.
Nobody decides this. It falls out of the arrangement.
The document flow nobody draws
Ask a co-lending team to draw the money flow and they will produce a clean diagram. Ask for the document flow and you usually get a pause. In practice it looks like this:
- The customer submits KYC to the originating NBFC, often through a DSA or a connector app.
- The NBFC's system stores the documents as received.
- The file — or a subset of it — is shared with the partner bank for their own KYC obligation, usually as a zip, an SFTP drop, or through an API integration built for the purpose.
- The bank stores what it receives in its own document repository, under its own retention schedule.
- Both parties retain for the life of the loan and beyond, and the periods rarely match.
Every one of those steps is reasonable. The result is that an unmasked Aadhaar number now exists in two institutions' systems, and the customer consented to a loan, not to that.
Whose problem is it when it leaks?
This is the question worth putting to your legal team before it is put to you. If the partner bank suffers a breach and the exposed documents originated from your onboarding, the reputational attribution rarely respects the contractual allocation of liability. The customer onboarded with you. The press will say your name.
The contractual position and the practical position diverge here more than in almost any other part of a co-lending arrangement. Contracts allocate liability. They do not un-share a document.
The cleanest control is also the simplest: if the document that leaves your building is already masked, the question of whose breach it was becomes much less interesting, because what leaked identifies a customer by four digits and a name rather than by a full national identifier.
"But the bank needs the full number"
Sometimes true, usually assumed. It is worth separating three things that get conflated:
| What the bank needs | What that requires |
|---|---|
| To satisfy its own KYC obligation | Evidence that identity was verified, and a record of the document collected. A masked copy is a record of the document collected. |
| To authenticate the customer against UIDAI | A licensed AUA relationship and the customer's consent at the time of authentication. Your stored copy does not enable this, masked or not. |
| To de-duplicate against existing customers | An identifier they can match on. This is the case that sometimes genuinely needs more than a masked copy — and it is worth asking whether a hash or a reference number would serve, rather than the number in the clear. |
Our experience is that the third case is the one people are actually thinking of when they say "the bank needs the full number", and it is a solvable problem that nobody has been asked to solve because the default — send everything — has never been challenged.
What to do about it
1. Find out what you actually send
Not what the integration document says. Pull a real file from last week and look at it. In most co-lending integrations the payload was defined once, early, by someone optimising for the bank not coming back with questions — which means it contains everything, including documents the bank never opens.
2. Mask at ingestion, not at hand-off
Masking on the way out solves the sharing problem and leaves your own storage problem untouched. Masking at ingestion solves both, and it means the co-lending payload is built from documents that are already safe, with no extra step in the hand-off path to fail silently.
3. Agree the document set explicitly
Write down which documents cross, in what form, and why each one is needed. This is a short conversation that has usually never been had, and it frequently removes two or three documents from the payload entirely.
4. Make retention symmetrical, or know that it is not
If you delete at seven years and they delete at ten, your customer's documents exist for ten. That may be unavoidable, but it should be a known fact rather than a discovery.
The same applies further down the chain
Co-lending is the most visible case, but the pattern repeats anywhere a loan file leaves the originating institution: direct assignment, securitisation, insurance tie-ups, collections agencies, and the increasingly common arrangement where a fintech originates on an NBFC's books and both hold the documents.
In each case the question is the same and the answer is the same. The document that leaves should not carry a readable national identifier, because you cannot recall it and you cannot govern it once it is gone.
A note on doing this retrospectively
Most institutions reading this have been co-lending for a while, which means the unmasked documents have already gone. That is not a reason to skip the change — it is a reason to make it now and stop the count increasing. Fix the outbound path first, then remediate your own archive backwards from the most recent, since recent files are the ones most likely to be re-shared.
And when you do talk to your partner bank about it, expect the conversation to be easier than you think. They have the same problem from the other side, and nobody has raised it with them either.
MaskAadhaar masks Aadhaar and PAN in loan documents through a single REST call, processed in Mumbai and never written to disk. See how NBFCs use it, read the API documentation, or tell us your document volume.