Build an Indian identifier test set without collecting real identity numbers

A realistic-looking identifier is not automatically safe test data. Randomly assembling characters in a recognised format can produce a string that resembles, or potentially coincides with, an issued identifier. Copying a number from a public document is an even weaker shortcut: public visibility does not make it suitable for a development fixture.

An identifier test set needs a clear purpose. Testing a recogniser’s format logic, testing an application workflow and verifying a person’s identity are different activities. Keep their data and acceptance criteria separate.

Decide what the test is meant to prove

A format test asks whether a recogniser handles the structure it is designed to detect. It can include deliberate invalid cases, punctuation variations and truncated strings. An application test asks what happens when the recogniser returns a candidate. It may use a mocked detector result or a clearly non-functional placeholder.

Neither test needs to establish that a number belongs to a real person. Do not send synthetic candidates to live identity-verification services to see whether they exist. That changes both the data path and the purpose of the exercise.

For PAN, the Income Tax Department describes a ten-character alphanumeric structure. The cited field specification uses five letters, four digits and a final letter. Use the official definition when designing format tests. A library’s entity catalogue can help identify a recogniser, but it should not outrank the issuing authority on the identifier’s structure.

Use a layered fixture strategy

A hypothetical onboarding team wants to test a proposed privacy filter for uploaded forms. It can build three layers of fixtures.

The first layer tests application behaviour using explicit placeholders such as “PAN_TEST_VALUE” and injected recognition results. These values are intentionally unsuitable for real identity checks.

The second layer tests recogniser rules using controlled positive and negative cases. Prefer documented test values or sandbox fixtures where an authoritative provider supplies them for this purpose. If no safe positive fixture is available, record the limitation rather than presenting invented values as guaranteed unissued.

The third layer tests document layout using synthetic names, addresses and identifiers designed for the approved environment. Maintain a manifest explaining where each value came from, what it tests and why it is appropriate to retain.

A production-like appearance should never be the only acceptance criterion.

Cover errors around the identifier

A detector can fail even when its core pattern is correct. Include spaces or line breaks around the value, punctuation immediately after it, nearby labels, multiple candidates and incomplete values. Test whether ordinary order references are incorrectly captured.

Separate these cases by purpose. A deliberately malformed string can be an excellent negative test, but it cannot prove that the recogniser detects a correctly formatted identifier. A mocked recogniser result can test redaction behaviour, but it cannot establish recognition accuracy.

Presidio’s supported-entity catalogue lists recognisers for several Indian identifier types. That listing describes available categories, not validated performance on your forms. Record the recogniser version and configuration used, and verify important format details against the relevant official source.

Do not confuse masking with test-data safety

UIDAI’s description of masked Aadhaar explains that the first eight digits are obscured while the last four remain visible. That is a specific representation. It does not establish that an entire document is anonymous.

A masked document may still contain a person’s name, address, image or other identifying content. A test-data review should inspect the whole fixture and any embedded content within scope. Removing one visible identifier is not a substitute for checking the rest of the file.

Similarly, changing one digit in a real customer’s number leaves the fixture derived from customer data and may create a plausible different number. Prefer fixtures created for the test from the outset.

Keep the evaluation honest

Presidio’s evaluation guidance supports use-case-specific measurement. For an identifier suite, publish a small coverage table with the identifier category, case type, expected result and actual result. Name untested conditions.

Before accepting the suite, check:

• Every fixture has an approved origin and an explicit test purpose.
• No fixture requires a live identity lookup to establish its safety.
• Format recognition, transformation and workflow tests have separate results.
• Negative cases include plausible non-identifier strings.
• Generated templates are separated appropriately between development and evaluation.
• Reports make no claim that syntax or checksum validity proves identity.

The most useful test set is one the next engineer can understand and extend safely. Its value comes from controlled cases and clear limits, not from making a demonstration look as though it contains real people.