PAN Card Validation: Format, Checksum, and Detection Patterns

PAN Format Explained

PAN follows the format: AAAAA9999A — positions 1-3 are alphabetic (sequence code), position 4 is alphabetic (entity type), position 5 is alphabetic (surname first letter for individuals), positions 6-9 are numeric (sequence), position 10 is alphabetic (checksum character).

Position 4 entity types: P = Person (individual), C = Company, H = Hindu Undivided Family, F = Firm, A = Association of Persons, T = Trust, B = Body of Individuals, L = Local Authority, J = Artificial Juridical Person, G = Government.

Validation Beyond Regex

The basic regex [A-Z]{5}[0-9]{4}[A-Z] matches the format but allows invalid PANs. The 10th character (checksum) is computed based on the first 9 characters using a modulo-based algorithm. Validating this checksum eliminates false positives on strings that happen to match the PAN format (e.g., product codes like 'ABCDE1234F' in non-financial contexts).

Additionally: if position 4 is 'P', position 5 must be the first letter of the taxpayer's surname — you can use this for context validation in KYC flows. Check that the PAN is not in the CBDT blacklisted PAN list (available via Income Tax API) for high-risk transactions.

Detection in LLM Contexts

PAN appears in: tax forms, investment account onboarding, high-value transaction records, salary slip PDFs converted to text, and user-pasted documents in support tickets. Context keywords: 'PAN', 'permanent account number', 'Form 16', 'ITR', 'TDS certificate'.

False positives: product SKUs with similar format, airline booking codes, and engineering part numbers can match PAN regex. Context detection (adjacent keywords) significantly reduces false positives. If no PAN-adjacent keyword is present and the string appears in a code block or product catalogue, skip PAN detection.

Data Types operational checklist

PAN Card Validation: Format, Checksum, and Detection Patterns should be reviewed as an operating control, not only as a reference article. The minimum checklist is a data inventory, a stated processing purpose, owner approval, PII detection at the AI boundary, redaction or tokenisation where possible, retention limits, vendor transfer records, and a tested user-rights workflow. This checklist gives engineering and compliance teams a shared language for deciding what must be blocked, what can be allowed in shadow mode, and what needs human review before production release.

For AI systems, the review should include prompts, retrieved context, tool call arguments, model responses, logs, traces, analytics events, exports, and support attachments. Many incidents happen because teams scan only the visible form field while sensitive data moves through background context or observability tooling. CrewCheck's recommended pattern is to place the scanner at the request boundary, record the policy version, and keep audit evidence that shows which identifiers were detected and what action was taken.

A practical rollout starts with representative samples from production-like traffic. Run a DPDP scan, sort findings by identifier sensitivity and blast radius, fix Aadhaar, PAN, financial, health, children's, and precise-location exposure first, then move to consent wording, retention, deletion, and vendor review. Use shadow mode when false positives could disrupt users, and promote to enforcement only after the exceptions have owners and expiry dates.

This page is educational and should be paired with legal review for final policy interpretation. The operational proof should still come from repeatable evidence: scanner results, audit exports, pull-request checks, policy configuration, and a documented owner for the workflow. That combination is what makes the content useful during buyer diligence, board review, regulatory questions, or an incident investigation.