Collecting PAN, Aadhaar, and bank details with a stated purpose

HR teams in India often collect PAN, Aadhaar, and bank details as part of building an employee record. This article is operational education on handling those identity and payment fields: why each category may be collected, how to limit purpose and access, how to avoid collecting “just in case,” how to treat documents, and how to tell employees what you are asking for. It is not legal advice. It does not state what any statute requires. It does not invent Aadhaar, UIDAI, or privacy-law rules. Confirm current obligations with qualified counsel and official sources before you treat a practice as mandatory.

The employee information checklist lists field groups to collect or audit. Dayzen employee management can store profile fields and validate PAN and Aadhaar in the add-employee wizard for data quality — presence and form, not government KYC or UIDAI verification. Who should see sensitive fields is a permissions question; see who should see what in an HR system.

Operational guidance versus legal advice

Operational guidance is how your team runs a process: which field is on the join form, who can open it, where the scan lives, what you tell the joiner. Legal advice is whether a particular collection, use, disclosure, or retention is lawful in your situation. This page stays on the first side. Where Indian organizations commonly have an operational reason to collect a category, that is described as a possible purpose, not as a legal mandate verified in Dayzen documentation. Dayzen docs do not certify a DPDP implementation and do not claim Dayzen is DPDP certified. Do not read product field validation as a compliance stamp.

If you need a rule you can defend to a regulator or a court, stop here and speak to counsel. If you need a cleaner HR workflow so PAN, Aadhaar, and bank details are not scattered across inboxes, continue.

Why each category may be collected

Collect a sensitive category only when your organization can say, in one sentence, what work the field is for. If you cannot finish the sentence, do not add the field to the form “because other companies do.”

PAN

PAN (Permanent Account Number) is a tax-related identifier issued in India. HR and payroll teams may collect it when the operational purpose is tax or statutory processing that your finance or payroll owners actually perform — for example, so payroll calculation and tax-related reporting they run can use a consistent identifier. That is a purpose statement you write for your process. It is not a claim, in this article, that a named law requires you to store PAN in an HRMS, and it is not a claim that Dayzen files returns with the Income Tax Department.

If nobody in your organization uses PAN for a defined process, storing it “for later” is collection without a purpose. Delay the field until the process exists.

Aadhaar

Aadhaar is a unique identity number issued in India. Some employers collect an Aadhaar number or copy as part of identity or statutory processing they have designed. Whether a given use is allowed, restricted, or prohibited is a legal question this page will not answer. Operationally: if you collect Aadhaar, name the internal purpose, limit access, and do not treat a stored number as proof that identity was verified with UIDAI.

Dayzen does not perform UIDAI verification. Wizard checks on an Aadhaar field are format and completeness checks. If your process requires a government identity check, that is a separate operating decision with its own vendor, legal review, and employee notice — not something to infer from an HRMS form.

Bank details

Bank account details may be collected when the purpose is salary disbursement setup or another payment process your organization actually runs. Account number, IFSC, and account holder name are a coherent set for that purpose; three extra accounts “in case” are not. Dayzen is not described here as paying via banks. If someone is not paid through a process that needs bank data, do not copy the full-time bank form onto their profile by habit.

Purpose limitation as an HR habit

Purpose limitation, as an operating habit, means: state why you collect a field, use it for that work, and do not quietly recycle it without a fresh decision. Do not use bank details collected for salary setup as a vendor-payment convenience, Aadhaar as a password or badge number, or PAN as a lookup key in an all-hands spreadsheet. Write the purpose on the form and in the SOP. When another team asks for an export of “all KYC,” ask which purpose their job requires — often they need a yes/no that documents arrived, not the numbers. This habit reduces accidental overuse. It is not a complete reading of any privacy statute.

Access control: fewer people than the directory

Name, department, and manager are operationally wide. PAN, Aadhaar, and bank details are not. Default to a small audience: HR data owners and payroll or finance roles that must process the field. Managers generally need team structure, not bank accounts. Colleagues do not need Aadhaar. IT may need an employee ID to provision a laptop; that is not a reason to copy identity scans into a ticket.

Practical access patterns:

• Separate view rights for directory fields versus identity and bank fields.
• Separate rights to open scans versus to see a masked number, if you mask.
• No shared “HR” password. Named users, so you can answer who opened a file.
• Exports treated as events: who pulled the list, why, where it went, when it was deleted.

Align this with the visibility model in HR system permissions. This page does not claim security certifications.

Minimizing unnecessary collection

Minimization means collecting the least that still runs the stated process. Operational checks:

1. Is the process live this month, or only imagined?
2. Do you need the number, the scan, or a confirmation that a check was done elsewhere?
3. Do you need it at offer, at join, or only if the person becomes payroll-eligible?
4. Do contractors, interns, and employees actually share the same need?
5. Can you stop a duplicate copy in email once the HRMS profile holds the field?

A common failure is collecting every identifier because the add form has a slot. Empty optional slots are better than populated unused ones. Another is collecting family members’ identity numbers with no workflow that uses them. Leave unused fields off; do not skip a field your payroll owner actually processes, and do not clone another company’s join pack unread.

Document handling beside the fields

Numbers are fields. Cards and cancelled cheques are files. Store files against the employee record, labelled by type, with tighter access than the directory. Do not keep a WhatsApp album called “KYC” and a second copy in a founder’s drive. Do not name files with the full Aadhaar number in the filename, which leaks into backups and search.

When a document is only needed to evidence a field at join, say whether you still need the scan after the field is entered, or only the field. Indefinite duplicate copies increase exposure without improving operations. Retention and deletion periods are legal and policy questions; this page does not set them. It only asks you not to treat “keep forever in every channel” as a default.

Dayzen profiles can hold documents alongside personal and job information. Attach files to the same person identity so inbox copies can be retired.

HR workflows that keep purpose visible

Build collection into the join path instead of a side channel:

1. HR creates or activates the person in the system of record after a duplicate search.
2. The form asks only for identity and bank fields that your SOP has a purpose for, at the stage you need them.
3. Validation checks that values look complete and well-formed.
4. Documents of the matching class are attached, not emailed into a group.
5. Access stays with the roles that process those fields.
6. The employee can see that the organization holds the categories, through a channel you choose, without exposing the values to managers who do not need them.

Dayzen’s five-step add-employee wizard includes personal information and verification documents, with validation for email, employee ID, PAN, and Aadhaar fields where used, plus auto-generated employee IDs with organization prefixes. Use the wizard as a data-quality gate. Do not describe it to employees as “government verification complete.”

Corrections follow the same purpose: a documented bank or identity-number request, applied by HR or payroll — not a chat edit, and not a leftover value in an old export.

Employee transparency

People should not discover that you hold Aadhaar only when a leaked spreadsheet appears. In plain language, tell joiners:

• Which categories you are asking for (PAN, Aadhaar, bank details — only those you actually ask for).
• The operational purpose in one sentence each.
• Who inside the company typically can see them (HR/payroll, not the whole team).
• How to request a correction.
• That field validation in software is not the same as a government identity check, if you use such validation.

Transparency here means fewer surprises and better corrections. How notice or consent must be structured under current law is for counsel and official guidance, not for this article to specify.

What this page refuses to claim

• Dayzen is not described as DPDP certified.
• Dayzen is not described as performing UIDAI or Income Tax Department verification.
• Dayzen is not described as filing PF or ESI, or as paying via banks.
• No invented statistics about breaches, adoption, or “what most employers must do.”
• No field on a form is, by itself, a legal conclusion.

For the list of field groups, use the employee information checklist. For storing profiles, directory, and the add wizard, use employee management. For who may view sensitive versus directory fields, use HR system permissions.

Collect PAN, Aadhaar, and bank details only with a stated operational purpose, a small audience, as little extra copy as you can, and an honest explanation to the employee. That is HR data-handling hygiene. It is not a substitute for the law.