For HR & background verification

Employee onboarding documents, read and redacted

Every hire hands over an Aadhaar, a PAN, past payslips and educational certificates. HR platforms and background verification firms process these by the thousand, then keep them in an HRIS that was not designed to hold identity documents.

Talk to our technical team → — for integration questions, a security review or a volume estimate.

Two jobs, one call each

Read it
/extract-aadhaar and /extract-pan return name, date of birth and the identifier as JSON, so onboarding forms fill themselves and a typo never becomes a payroll record. The Aadhaar checksum is validated, so a mis-read is caught rather than stored.
Then bury it
/mask-aadhaar before the document reaches the HRIS. You needed the number to verify; you do not need to keep it readable for the length of someone's employment and seven years beyond.
The order matters. Extract first, mask second, store the masked copy. Teams that store first and plan to mask later find that "later" means "in the backup, in the replica and in three exports".

For background verification firms

What an HRIS ends up holding

Onboarding is a one-week process that creates a twenty-year record. The documents collected in that week are still there long after everyone who collected them has left.

The joining folder
Aadhaar, PAN, previous payslips, relieving letter, educational certificates, cancelled cheque. Six documents, four identifier types.
Who can see it
HR operations, payroll, the BGV vendor, and usually anyone with an admin role in the HRIS — a permission set that grows over time and is almost never audited.
After they leave
Statutory retention keeps the file for years. The documents stay exactly as readable as the day they were uploaded.
Exports
Payroll migrations and HRIS changes copy the whole document store to a new vendor, usually over a channel chosen for convenience.

Extract then mask, and why that order is not obvious

The instinct is to mask on upload and be done. That breaks onboarding, because the number you just covered is the one payroll needs to read.

1. Extract
Read name, date of birth and the identifier as JSON. Populate the joining form and the payroll record from that.
2. Use it
Whatever verification you are obliged to do happens here, on data in flight.
3. Mask
Then redact the document and store the masked copy as the record of what was collected.
The document and the data are different things. Keep the fields you have a reason to keep, in a database where access is controlled; do not keep a readable image of the card as the way of keeping them.

Questions we get asked

Can we auto-fill onboarding forms from an Aadhaar card?

Yes. The extraction endpoint returns name, date of birth, gender and the number as JSON with the checksum validated. Note that the unmasked-number entitlement is granted per organisation against a stated lawful basis rather than self-serve.

Should we store the Aadhaar number at all?

That is your counsel's call, not ours. What we can say is that most HR systems keep the document image long after they needed the number, and masking at intake removes that exposure without changing the verification step.

Does it work on educational certificates and payslips?

The generic redaction endpoint does, because it looks for identifiers rather than document types. The Aadhaar and PAN endpoints are for those specific cards.

Won't masking break our payroll onboarding?

Not if you extract first. Read the fields you need as JSON, complete the verification step, and mask the document afterwards. The stored image was never how payroll should have been reading the number anyway.

What about documents for candidates we did not hire?

The clearest case of retained data with no remaining purpose. Masking at intake means there is nothing to purge later, which matters because the purge job is the one nobody gets around to building.

Related

Talk to us about your document volume

Tell us how many documents a month you process and what your peak looks like. We will size a plan, provision a key with a test quota, and answer a security questionnaire if you need one.