Primary Account Number
The primary account number is the card number itself — usually sixteen digits: the issuer's BIN at the front, the account identifier in the middle, a Luhn check digit at the end — the value that identifies the account on every transaction and that, with an expiry and a CVV, is enough to buy online. It is the data PCI DSS exists to protect, and the data tokens and encryption exist to keep out of everyone's systems.
- Also known as
- PAN, Card number, Account number (card)
- Used at
- every card transaction — carried in the authorisation and clearing messages, embossed or printed on the card, stored (encrypted or tokenised) wherever a card is kept on file
- Binding
- PCI DSS requirements on storing (rendered unreadable — truncated, hashed, encrypted or tokenised), transmitting (encrypted over open networks) and displaying (masked to the first six and last four) it; scheme rules on where it may appear; the ISO/IEC 7812 standard for its structure
- Typical structure
- 13–19 digits; the first digit the major industry identifier (4 for Visa, 5 and 2 for Mastercard, 3 for Amex and Diners), the first six to eight the BIN, the last a check digit computed by the Luhn algorithm, the rest the account
- Typical exposure
- a PAN with expiry and CVV is a card-not-present fraud kit; breaches are counted in PANs and cost the breached party in reissuance, fines and fraud; the value of a stolen PAN on the criminal market has fallen as tokens and 3DS made them harder to use
- Parties
- the issuer that assigns it, the network that routes on it, the merchant that captures it (or arranges not to), the PCI assessors, and the fraudsters who want it
How the primary account number works in practice
A card number 4571 2345 6789 0123: the 4 says Visa; 457123 (or 45712345 under eight-digit BINs) says the issuer, product and country; 6789 012 identifies the account within the issuer's range; and 3 is the check digit — the Luhn algorithm applied to the other digits produces it, so a mistyped number fails the check before any network is consulted. Every authorisation carries it (or a token standing for it); every system that sees it in clear is in PCI scope; every place it is stored must render it unreadable.
The industry's engineering of the last fifteen years has been about not having it. Tokenisation replaces the stored PAN with a merchant-side token; network tokens replace it with a scheme-issued substitute; point-to-point encryption hides it in transit from the terminal; hosted payment fields keep it off the merchant's page; wallets hold a device token instead. The result is that a modern merchant may accept millions of card payments and never possess a PAN — which is the goal, because the PAN's exposure is the breach, and a company that does not have it cannot lose it.
For diligence on any company that touches cards: where PANs exist in clear, why, for how long, and under whose PCI report.
Example
A retailer's technology diligence during its acquisition maps every place a PAN exists: the legacy POS system (in clear, in memory, for the duration of a transaction — in scope), a customer-service tool that displayed full numbers to agents "for verification" (a PCI violation found in the review), an archived database from a 2016 migration with 400,000 PANs in an encrypted table whose key sat on the same server, and the current e-commerce stack, which tokenised everything and held none. Remediation before completion: the CS tool masked, the archive purged under a documented process, the POS moved to P2PE. The buyer's assessor signs off; the seller's had not looked.
Common mistakes
- PANs in places nobody mapped — logs, support tickets, exports, an old backup. - Displaying full numbers to staff "for verification" when the last four would do. - Storing PANs encrypted with the key next to them. - Confusing the PAN with the account; a replaced card has a new PAN and the same account. - Assuming a company with a PCI certificate has no PANs in clear; the certificate covers the scope it was given.