Card Data Record vs Magnetic Stripe Track Data
Published: October 20, 2026 · By Marcus Hale, Payment Systems Analyst
Two formats, two standards, two purposes. A card data record is defined by ISO/IEC 7812 and carries a structured set of fields. A magnetic stripe track record is defined by ISO/IEC 7813 and carries the legacy stripe encoding. Knowing which is which matters for anyone validating, storing or parsing card data.
Card data record (ISO/IEC 7812)
A card data record is a structured set of fields. The core identifier is the PAN, which carries an issuer identifier, an account identifier and a check digit. Around it sit cardholder-specific elements such as name, address, postal code, date of birth and personal identifiers. Each element has a defined length, character set and validation rule, which is what makes a record machine-checkable rather than free text.
Magnetic stripe track record (ISO/IEC 7813)
ISO/IEC 7813 defines two record formats for the magnetic stripe. Track 1 is alphanumeric and carries the cardholder name alongside the PAN. Track 2 is numeric and carries the PAN, expiry, service code and discretionary data. Both use sentinel characters, a single field separator and a terminator. This is the format a terminal reads when it swipes a card.
Side by side
| Feature | Card data record | Track record |
|---|---|---|
| Standard | ISO/IEC 7812 | ISO/IEC 7813 |
| Structure | Named fields with types | Delimited positional fields |
| Cardholder name | Yes, as a field | Track 1 only |
| Expiry | As a field | Encoded, order differs per track |
| Service code | Not part of the record | Present in both tracks |
| Used at | Data stores, tokenisation, ecommerce | Card-present terminals, legacy |
| Validation | Per-element format rules | Structural plus Luhn on the PAN |
Why the distinction matters operationally
They fail differently and need different checks. A card data record fails per element: a valid PAN with a malformed expiry, a name field that contains free text, a postal code in the wrong national format. A track record fails structurally: a wrong sentinel, a missing separator, a field count that does not match, a PAN that does not pass the Luhn check. A validator written for one will silently accept garbage in the other.
Validation checklist
- For card data records: check every element against its own format rule, not just the PAN
- For track records: check sentinel, separators, field count and PAN checksum before reading content
- Confirm the expiry representation matches the format you are reading
- Treat a record that fails any structural check as untrusted