Unique beneficiary IDs: why not to use Aadhaar
Every NGO that runs more than one programme eventually asks the same question: what number should identify each person we serve? Our answer is a programme ID your own system generates, plus a matching workflow that catches duplicates before they reach a report. Aadhaar looks like a ready-made shortcut, but as a primary key it brings legal and security exposure most nonprofits are not set up to carry.
This deep dive sits under our guide to the beneficiary management system, which covers the full data model. Here we go into the ID itself.
What a good beneficiary ID looks like
A good ID has four properties:
- System-generated. Nobody types it. Typed IDs pick up typos, and typos become duplicates.
- Never reused. When a person leaves or a record is merged, their ID retires with them.
- Meaningless. Don’t encode the district, centre or programme. People move, centres close and programmes end, but the ID has to outlive all of them. Store those facts as fields instead.
- Readable. A short organisation prefix and a running number (for example ABC-004817) is easy to read out on a phone call or write on a paper register during an outage.
Give households their own IDs in the same style with a different prefix, so nobody confuses a family with a member. Our sibling deep dive on household vs individual beneficiary records covers how the two link.
A worked example: catching a duplicate
Illustrative scenario. A field worker in a new block registers “Lakshmi K”, age 34, from Kallipatti, with a phone number. The system already holds “Laxmi Kumar”, born 1991, from Kallipatti, with a different phone number.
A single-field check would miss this. The names differ, and so do the phones. A combined match catches it:
| Signal | New registration | Existing record | Match? |
|---|---|---|---|
| Name (phonetic) | Lakshmi K | Laxmi Kumar | Likely |
| Age / DOB | 34 | 1991 | Yes, within a year |
| Village | Kallipatti | Kallipatti | Yes |
| Phone | Different | Different | No (common in joint families) |
Three of four signals match, so the system flags the pair rather than blocking the registration. The field worker sees the existing record, asks one confirming question (husband’s name, or the SHG she belongs to) and chooses “same person”. The new enrolment attaches to the existing ID.
If she registers offline, the pair lands in an intake table instead, and a supervisor reviews it before the record joins the main list. If two records do slip through, the fix is a merge: histories combine under the older ID, the newer ID retires, and the merge is logged with who did it and when. Never delete. Deleting loses attendance and service history that a funder may already have counted.
One practical warning from our builds: filter dashboards and access rules on IDs, not names. Where filters ran on staff names, two people with the same name ended up seeing each other’s rows.
Why Aadhaar makes a poor primary key
It is tempting. Most adults in India have one, and it is unique. But four facts make it the wrong key for an NGO system:
- Private authentication was restricted. In Puttaswamy (September 2018), the Supreme Court struck down the part of Section 57 of the Aadhaar Act that let private bodies use Aadhaar authentication on the basis of a contract (MediaNama summary).
- The 2025 opening is narrow. The January 2025 amendment to the Aadhaar Authentication for Good Governance Rules lets non-government entities authenticate only after a proposal is approved by the relevant ministry, the Central Government and UIDAI, and only for listed purposes such as preventing leakage of welfare benefits (Khaitan & Co analysis). It is not a general licence.
- Storage rules are strict. UIDAI requires requesting entities to keep Aadhaar numbers only in a separate, encrypted Aadhaar Data Vault (UIDAI Circular 14 of 2025). A primary key appears in every table, export and log, which is the opposite of a vault.
- DPDP raises the stakes. The DPDP Act’s main obligations (notice, consent, purpose limitation, security safeguards, retention and erasure, and verifiable parental consent for children’s data) apply from 13 May 2027 under the phased rules notified in November 2025 (Mondaq summary). MeitY has consulted on bringing that date forward, so plan as if it could arrive sooner.
There is also a plain practical problem: not everyone you serve will have, or want to share, an Aadhaar number. A key that some people lack forces workarounds on day one.
Our default Aadhaar rule
Write this down as policy, get leadership to sign it, and put it in field staff training. Then audit your forms: if an old registration form still asks for the full number “just in case”, drop the field. Our DPDP compliance checklist for NGOs has the wider list of fields and practices to review before May 2027, and the consent notice template gives plain-language wording for the purpose you collect it for.
Get your identity layer right first
Unique IDs are the cheapest thing to get right at the start and the most expensive to fix later. If you’re not sure whether your current setup counts people or just counts forms, start with an honest look at where you are.
Take the free technology assessment →