Payment Card Data Elements: What Each Field Is and How to Store It

Most card data mistakes start with not knowing which field is which: teams store the CVV "just for recurring billing", log full track data in a debug file, or call a masked screen value "truncated" in an audit. Payment card data elements are the individual pieces of information on and inside a payment card: the primary account number (PAN), the issuer identification number (IIN, usually called the BIN), the check digit, the expiry date, the service code, the card verification code, the magnetic stripe or chip track data and the PIN block. This guide explains the anatomy of a card number, what each element is for, which elements may be kept and how, and how masking, truncation, tokenisation and virtual card numbers differ. For the standard itself, see the PCI DSS 4.0 Guide.

Key takeaways

• Two classes, two rules. PCI DSS splits account data into cardholder data (PAN, name, expiry, service code), which may be stored if protected, and sensitive authentication data (card verification code, full track data, PIN and PIN block), which must not be kept after authorisation.
• The PAN is the trigger. Cardholder data at minimum is the full PAN; name or expiry stored without a PAN is not cardholder data, but anything stored with the PAN inherits its protection requirements.
• The BIN is now eight digits. ISO/IEC 7812-1:2017 moved the issuing BIN from six to eight digits, and Visa required acquirers and processors to support eight-digit BINs by April 2022, which changes truncation and fraud rules built on "first six".
• Masking, truncation and tokenisation are not synonyms. Masking hides digits on a screen or receipt, truncation permanently removes digits from stored data, and a token replaces the PAN with a substitute value; auditors treat them differently.
• A passing Luhn check proves nothing about a card. The check digit only catches typing errors; card number generators produce Luhn-valid numbers by the million, so validity checks belong at the issuer, not in your form.

What it is

PCI SSC defines account data as cardholder data and/or sensitive authentication data. Its glossary defines the PAN as the unique payment card number (credit, debit or prepaid) that identifies the issuer and the cardholder account, and says cardholder data consists at a minimum of the full PAN, optionally with cardholder name, expiration date and service code. Sensitive authentication data (SAD) is security-related information used to authenticate cardholders or authorise transactions: card verification codes, full track data, PINs and PIN blocks.

Only issuers, and companies supporting issuing with a legitimate issuing need, may keep SAD after authorisation.

How it works

Anatomy of the PAN

ISO/IEC 7812-1:2017 (Identification cards, Identification of issuers, Part 1: Numbering system, fifth edition, confirmed in 2022) specifies the numbering system, the format of the issuer identification number and the format of the PAN. A PAN has three parts:

• Issuer identification number (IIN or BIN): the leading digits. The first digit is the major industry identifier, and in practice the leading digits identify the card network and issuer (for example, Visa ranges start with 4 and American Express ranges with 34 or 37). The 2017 revision lengthened the IIN to eight digits. Visa's service provider action sheet describes it as an industry standard change announced in 2017 with an effective date of April 2022, and warns that systems built on six-digit BIN logic risk routing errors, failed data feeds and broken fraud monitoring.
• Individual account identifier: the issuer-assigned digits after the IIN.
• Check digit: the final digit, calculated with the Luhn (modulus 10) algorithm over the other digits.

Most PANs are 16 digits; American Express uses 15, and some networks issue between 12 and 19. The PCI SSC truncation FAQ sets different limits for each length.

The Luhn check digit

The Luhn algorithm works from the rightmost digit: every second digit is doubled, nine is subtracted from any result over nine, and all digits are summed. A valid number gives a total divisible by ten. It catches single mistyped digits and most adjacent transpositions. It is not a security control. It carries no secret and says nothing about whether an account exists, is open or has funds.

Track 1, track 2 and the chip

ISO/IEC 7813 (Financial transaction cards) specifies the data structure and content of magnetic tracks 1 and 2. Track 1 is alphanumeric and carries the PAN, cardholder name, expiry, service code and issuer discretionary data. Track 2 is numeric and carries the PAN, expiry, service code and discretionary data; the discretionary area holds values such as the stripe's own verification value (CVV1 or CVC1, which differs from the printed code) and PIN verification data. An EMV chip holds an equivalent of track 2 data, and contactless and chip transactions use dynamic values instead of a static stripe code. Full track data is enough to clone a card, which is why it is SAD.

Card verification codes

PCI SSC describes the card verification code as the three or four digit value printed on the front or back of a card; brands use different names, including CVV2 (Visa), CVC2 (Mastercard) and CID (American Express, four digits on the front). It exists to show that a card-not-present purchaser has the physical card. If it is stored, it no longer proves anything. The PCI SSC FAQ on card-on-file payments is explicit: the code may be collected before authorisation, must be removed once that transaction is authorised, may not be kept for recurring or card-on-file payments, and neither encryption nor customer consent makes storage acceptable.

PIN blocks

The PCI glossary defines a PIN block as a block of data used to encapsulate a PIN during processing, containing the PIN and its length and possibly part of the PAN. PIN block formats and PIN handling are specified in the ISO 9564 series; ISO 9564-1:2017 sets the basic principles for PIN creation, issuance, use and deactivation at ATMs and point of sale. PIN blocks are encrypted at the PIN entry device and translated only inside hardware security modules. See the PCI PIN Security and Key Management Operations Guide and the Payment HSMs guide.

Masking, truncation, hashing and tokenisation

PCI SSC's glossary puts the distinction plainly: masking conceals a segment of the PAN when it is displayed or printed, while truncation removes a segment so that the stored, processed or transmitted PAN is unreadable. The truncation FAQ adds a warning that matters in practice: keeping several differently truncated versions of the same PAN makes it much easier to reconstruct the full number, so one format per environment is the safe rule. For architectures, see the Tokenisation and Data Masking Guide and Format Preserving Encryption.

Virtual card numbers and payment tokens

A virtual card number is a real PAN issued by the card issuer, typically for one merchant, one transaction or a set spending limit, and cancellable without replacing the physical card. An EMV payment token is different: EMVCo describes it as a unique alternative value to the PAN that is constrained in how it can be used, for example to a specific merchant, device or payment scenario, with each token service provider uniquely identified by a TSP code. For a merchant, a virtual card number is still a PAN and still cardholder data; a network token held in place of a PAN reduces what you store, but the systems that request and use tokens remain part of your assessment.

Why it matters

• Scope follows the data: every system that stores, processes or transmits the PAN or SAD, and every system connected to them, is in PCI DSS scope. See the PCI DSS Scoping and Network Segmentation Guide.
• Stored SAD is what turns a breach into fraud at scale: Requirement 3.3.1 exists because these are the elements criminals pay for.
• Payment pages leak elements as typed: client-side skimmers read the PAN, expiry and CVV directly from the form before any tokenisation happens. See the PCI DSS for E-commerce Payment Page Scripts Guide and the Web Skimming Incident Playbook.
• Generated numbers drive card testing: "fake credit card generators" output Luhn-valid numbers in real BIN ranges. They are used for free-trial abuse and, combined with expiry and CVV guessing, for enumeration attacks that test which numbers are live. Your exposure is the authorisation endpoint, not the generator. See the Card Testing and Carding Attacks Defence Guide.

How to put it into practice

1. Discover first: scan databases, file shares, logs, tickets and backups for PAN patterns (Luhn-valid 13 to 19 digit strings in known BIN ranges) and for track data patterns; treat any SAD found after authorisation as an incident to purge, not a finding to schedule. See the Data Loss Prevention (DLP) Guide.
2. Purge SAD paths: check payment middleware, application logs, crash dumps and support tooling for CVV and track data written during authorisation.
3. Decide per system: if a system only needs to recognise a returning card, use a keyed hash or token; if it needs to display, mask; if it needs the full PAN, encrypt and restrict access.
4. Standardise one truncation format per environment (first six or first eight, last four), documented and checked against your acquirer's requirements.
5. Update BIN handling to eight digits across fraud, routing and reporting, and regression test with eight-digit test ranges.
6. Roll back safely: introduce tokenisation behind a feature flag with the vault in parallel, keep the old encrypted store read-only until reconciliation passes, then destroy it with evidence.

Detection and measurement

• Unexpected PAN locations: count of data stores where discovery finds full PANs outside the approved inventory (target zero).
• SAD after authorisation: number of SAD findings from scans of logs and databases (target zero).
• Tokenisation coverage: percentage of card-on-file records held as tokens rather than encrypted PANs.
• Detokenisation volume: calls per user and service, alerting on spikes.

Common misconceptions

• "Encrypted CVV is fine for recurring billing." It is not: the PCI SSC FAQ states that encryption and customer consent do not permit storing the code after authorisation. Recurring and card-on-file flows are designed to work without it.
• "Masked and truncated mean the same thing." A masked screen can sit on top of a full PAN in the database. Only truncation, hashing, tokenisation or encryption change what is stored.
• "The last four digits are harmless." On their own they are not cardholder data, but combined with other truncated forms of the same PAN, or with a BIN from another system, they help reconstruct it. Keep formats consistent.
• "A number that passes Luhn is a real card." Luhn validity is arithmetic; only an authorisation or account verification with the issuer shows whether a card exists.

Related concepts

Practitioner checklist

• Map every system that receives each card data element, not only "card data".
• Confirm by scan, not by assumption, that no CVV, track data or PIN block is retained after authorisation, including logs and crash dumps.
• Mask displays to no more than the BIN and last four digits unless a role has a documented need.
• Pick one truncation format per environment and record it with your acquirer's confirmation.
• Replace stored PANs with tokens or keyed hashes wherever the full number is not genuinely needed.
• Move BIN parsing, fraud rules and routing to eight-digit BIN support and test it.
• Treat Luhn checks as input validation only; rely on issuer verification and velocity controls against generated numbers.

Standards and references

• PCI Security Standards Council: Glossary
• PCI Security Standards Council: FAQ, acceptable formats for truncation of PANs
• PCI Security Standards Council: FAQ, storing card verification codes for card on file or recurring transactions
• ISO: ISO/IEC 7812-1:2017 Identification of issuers, Numbering system
• ISO: ISO/IEC 7813 Financial transaction cards
• ISO: ISO 9564-1:2017 PIN management and security
• EMVCo: EMV Payment Tokenisation
• Visa: Eight-digit BIN service provider action sheet

Related NHI Mgmt Group resources: PCI DSS 4.0 Guide · Tokenisation and Data Masking Guide · Card Testing and Carding Attacks Defence Guide · PCI DSS Requirements for Service Accounts and NHIs Guide (8.6)