Primary Account Number (PAN): Definition and Use in Compliance

What is Primary Account Number (PAN)?

The Primary Account Number is the 13- to 19-digit numeric identifier on a payment card. It's printed on the card face, encoded on the magnetic stripe, embedded in the EMV (Europay Mastercard Visa) chip, and stored in the NFC antenna for contactless payments. Every card authorization message starts with the PAN. Without a valid one, the transaction doesn't route.

The structure follows ISO/IEC 7812-1:2017, published by the International Organization for Standardization, which defines the numbering system for identification cards. The first digit is the Major Industry Identifier (MII): "4" for Visa, "5" for Mastercard, "3" for American Express. The first six to eight digits together are the Issuer Identification Number (IIN), previously called the Bank Identification Number (BIN). These digits identify the issuing bank, the card program (consumer, commercial, prepaid), and the card's home country. The digits after the IIN up to position 18 are the individual account number assigned by the issuer. The final digit is generated by the Luhn algorithm, a mod-10 checksum that catches most transcription errors.

Card length varies by network. Visa and Mastercard use 16 digits. American Express uses 15. Maestro accepts 13 to 19. UnionPay can reach 19.

The Payment Card Industry Data Security Standard (PCI DSS) places PAN at the top of its protected data hierarchy. Requirement 3 of PCI DSS v4.0, published by the PCI Security Standards Council in March 2022, requires that stored PANs be rendered unreadable. Accepted methods include one-way hashing (SHA-256 minimum), truncation to first-six/last-four only, tokenization, or AES-256 encryption with documented key management. Displaying the full number in receipts, application logs, or database exports is a direct violation.

The practical security problem: a PAN can't be changed without physical card re-issuance. Issuers estimate re-issuing a compromised card costs $5 to $15. When a breach hits 10 million cards, the cost isn't theoretical.

How is Primary Account Number (PAN) used in practice?

Fraud analysts use PAN as the primary identifier when investigating suspicious card activity. The IIN identifies the issuing bank and card product. A high-value transaction on a consumer card from a specific issuer in an unexpected geography is a common opening signal. The analyst pulls the full transaction history tied to that PAN, correlates device data, IP addresses, and velocity patterns, then decides whether to file a Suspicious Activity Report (SAR) or close the alert.

Transaction monitoring systems index on PAN. When a rule fires, whether it's the fifth transaction in ten minutes or a transaction 4,000 miles from the previous one, the PAN is the key that retrieves authorization history, customer profile, and prior alert records. Getting this lookup fast matters: most card authorization decisions happen in under 200 milliseconds.

PCI DSS scope management centers on locating every system where a full PAN lives. That means scanning databases, flat files, log archives, email attachments, and network captures. Any system that touches a live PAN is in scope for PCI DSS assessment. Systems that handle only tokens or truncated data (first-six/last-four) can be excluded. Shrinking the Cardholder Data Environment (CDE) is the goal: fewer in-scope systems means lower audit cost and a smaller breach surface.

Chargeback and dispute workflows use PAN to reconcile issuer records against acquirer authorization logs. A cardholder disputes a transaction. The issuer submits the PAN from their records. If it doesn't match the acquirer's authorization log, that's an immediate flag for possible fraud staging.

Most enterprise payment platforms now tokenize PANs at point of capture. The real number never reaches application databases, which is the correct architecture.

Primary Account Number (PAN) in regulatory context

PCI DSS v4.0, published by the PCI Security Standards Council in March 2022, is the primary framework governing PAN handling globally. Requirement 3 mandates that stored PANs be rendered unreadable. Acceptable methods: one-way hash (SHA-256 or stronger), truncation to no more than first-six and last-four digits, tokenization with associated key management, or strong encryption (AES-256) with documented key storage. Requirement 4 mandates PAN encryption in transit: TLS 1.2 minimum. PCI DSS v4.0 also tightens requirements on scanning for clear-text PANs in memory and storage, and extends MFA requirements to all non-console administrative access to the CDE.

GDPR classifies PAN as Personally Identifiable Information (PII). A database containing full PANs is personal data processing under Article 4(1). This triggers Article 5 data minimization requirements, Article 25 data protection by design obligations, and Article 33's 72-hour breach notification window to the supervisory authority. Article 17 right-to-erasure claims can attach to PAN records, though transaction records subject to AML retention requirements may qualify for the Article 17(3)(b) exemption.

In the EU, Payment Services Directive 2 (PSD2) adds a transaction-level requirement. Strong Customer Authentication (SCA) mandates that card payments above threshold amounts require two of three authentication factors. The PAN alone isn't sufficient to authorize a payment in scope.

The European Central Bank's Card Fraud Report series, published periodically by the ECB, has consistently documented card-not-present transactions as the dominant fraud vector in EU card payments, accounting for over 80% of total card fraud value in recent reporting periods. This is a direct consequence of PAN exposure: once the number is compromised, it enables online fraud without requiring physical card access.

For US institutions, the Financial Crimes Enforcement Network (FinCEN) SAR instructions recommend masking PAN data in report narratives and supporting documentation to first-six/last-four where feasible, to limit exposure of the full number in regulatory systems.

Common challenges and how to address them

PAN leakage into application logs is the most common PCI DSS finding on assessments. Developers building payment integrations often log full request bodies for debugging. A single log line containing "pan": "4111111111111111" in an unencrypted archive is a violation, regardless of how well the database is protected. The fix is a log sanitizer that detects patterns matching 13- to 19-digit Luhn-valid sequences and masks them before writing. Several open-source libraries handle this at the framework level; the harder part is retrofitting existing services.

Third-party vendor exposure is more difficult to control. Merchants share PANs with payment gateways, fraud analytics vendors, and loyalty platforms. Each integration is a breach surface. PCI DSS Requirement 12.8 requires documented vendor agreements and annual risk assessments for all third parties that touch PAN. In practice, most significant card data breaches in recent years involved a third-party processor or technology supplier, not the primary merchant. The 2013 Target breach, traced to network access compromised through a third-party HVAC contractor, is still the reference case in most enterprise PCI training programs.

The Verizon Data Breach Investigations Report 2024 places financial services and retail among the highest-frequency sectors for payment card data compromise. The consistent finding: stolen PANs are used for card-not-present fraud (CNP fraud) within hours of compromise. Account takeover (ATO) attackers often target saved card data as a secondary objective: take over the account, change the delivery address, then make CNP purchases using the PAN already on file.

Migrating from PAN-based to token-based architectures is the structural solution, but it requires updating every system that currently handles a raw PAN: authorization APIs, dispute systems, reporting pipelines, fraud detection engines, and customer service tooling. Banks that have completed this migration report it taking 18 to 36 months for a mid-sized institution. The latency tradeoff is real: tokenization adds a vault lookup to each transaction. Most production vault implementations add 2 to 5 milliseconds, which is acceptable, but it requires upfront capacity planning.

Related terms and concepts

The Issuer Identification Number (IIN), still commonly called the Bank Identification Number (BIN), is the first six to eight digits of the PAN. It identifies the card issuer and program. BIN lookup tables are a standard tool in fraud screening: a card presenting as a US consumer Visa but carrying a corporate BIN from a foreign issuer is an immediate anomaly worth investigating. Most fraud platforms maintain enriched BIN databases that include country of issuance, card type, and historical fraud rates by BIN.

Tokenization replaces the PAN with a surrogate token that has no mathematical relationship to the original number. The real PAN stays in a secure token vault. Tokens are format-preserving: they look like a 16-digit card number but are useless outside the vault that issued them. Network Tokens go further: issued directly by Visa and Mastercard, they're device-specific and merchant-specific, so a token stolen from one merchant can't be used elsewhere. Network tokenization adoption has grown substantially since 2021, driven by issuer incentives and interchange rate reductions.

Truncation is simpler but more limited. You keep the first six and last four digits (for example, 411111______1111) and discard the middle. Truncated PANs satisfy PCI DSS display requirements but can't be used for transaction processing or fraud.

The Card Verification Value (CVV or CVC) is a three- or four-digit code generated from the PAN and an issuer-held cryptographic key. PCI DSS explicitly prohibits storing CVV after authorization, even when the PAN itself is stored in encrypted form. This is a common misconception: compliance teams assume encrypting the PAN is sufficient protection. Storing CVV alongside it, even in encrypted form, remains a separate violation.

EMV (Europay Mastercard Visa) chip technology doesn't eliminate the PAN from the transaction flow. The PAN still appears in the authorization message. What EMV adds is dynamic authentication data per transaction, making card-present counterfeiting extremely difficult. Because the PAN itself remains static even in chip transactions, fraud migrated online after EMV adoption in the US and EU, which is why CNP controls and 3-D Secure became more important as chip adoption rose.

For compliance teams managing Customer Due Diligence (CDD) programs, PAN data intersects with financial crime controls when high-risk customers use payment cards. A PAN associated with a customer flagged for Enhanced Due Diligence (EDD), or with a Politically Exposed Person (PEP), warrants transaction scrutiny beyond standard card fraud rules.