Track 2 and the Service Code: What the Magstripe Still Tells the Chip

💡 TL;DR (Too Long; Didn't Read)

Track 2 in 90 seconds:

• Track 2 Equivalent Data (tag 57) is the magnetic-stripe track carried inside the chip: PAN, a separator, expiry (YYMM), a 3-digit service code, and discretionary data, packed into nibbles.
• The service code is three digits that quietly decide interchange, authorization routing, and whether a PIN is expected — and its first digit is why a chip card's stripe says "use the chip."
• Discretionary data carries issuer verification values (CVV/CVC on the stripe, PVKI/PVV for PIN verification) — and it is exactly what you must never log.
• Luhn validates the PAN's check digit in a few lines and catches most typos and malformed captures before you spend a network round-trip on them.
• Track 2 is legacy in origin and everywhere in practice; you will parse it long after the stripe itself is gone.

The magnetic stripe is supposed to be dead, and in a sense it is — but its data model outlived it. When a chip card presents its account data, it does so in a field called Track 2 Equivalent Data, tag 57, which is precisely the layout of magnetic-stripe track 2 reproduced in the chip. Learn to read it once and you can read a stripe swipe, a chip read, and half the fields inside an authorization message, because they all speak this format. This is a field-by-field guide, with particular attention to the three-digit service code that most engineers skip past and that quietly governs how every transaction is routed and restricted. It follows ISO/IEC 7813 and EMVCo Book 3; I cite the structure, not the spec text.

The shape of Track 2

Track 2 is compact by design — the stripe had limited capacity, so the format is dense. In the chip's tag 57 it is packed two digits per byte (BCD nibbles), terminated by a padding nibble. Laid out logically, it is:

PAN  =  'D'  YYMM  SSS  DiscretionaryData  ['F' pad]
 │      │     │     │          │
 │      │     │     │          └─ issuer data: CVV/CVC, PVKI, PVV, etc.
 │      │     │     └─ 3-digit service code
 │      │     └─ expiry: year, month
 │      └─ field separator (hex 'D')
 └─ Primary Account Number (up to 19 digits)

The field separator is the hex nibble D — it marks the end of the PAN, which is variable length. Everything after it is fixed in shape: four digits of expiry as YYMM, three digits of service code, then discretionary data filling the rest, padded with F nibbles to a byte boundary. So the entire parse is: read digits until you hit D, that is the PAN; the next four are expiry; the next three are the service code; the rest, minus trailing F, is discretionary data. There is no length field inside track 2 — the separator and fixed offsets are the grammar.

A worked example. Suppose tag 57 decodes to the digit string:

4761739001010119 D 2512 201 1234567890

The PAN is 4761739001010119 (16 digits, ending at the D), the card expires 2025-12 (YYMM = 2512), the service code is 201, and 1234567890 is discretionary data. Four facts, one field. Note that the expiry is YYMM — year first — which is the single most common transposition bug when people hand-build test data.

The service code is doing more than you think

Those three digits after the expiry are the most under-read part of the card. Each digit is an independent code, and together they influence interchange, authorization, and cardholder verification.

First digit — interchange and technology. 1 = international interchange. 2 = international interchange, ICC (chip) preferred — the card has a chip and it should be used. 5 = national interchange. 6 = national, ICC preferred. 7 = private. 9 = test. The chip-present cards you handle almost all start with 2 or 6, and that leading digit is the stripe telling the terminal, "I have a chip — fall back to me only if you must." This is why a service code of 201 on a swiped transaction is a fraud signal: a chip card being swiped when its own stripe says to use the chip.

Second digit — authorization processing. 0 = normal. 2 = must be authorized online by the issuer. 4 = authorized by the issuer unless a bilateral agreement applies. This digit is a routing hint: a 2 here means "don't approve me offline."

Third digit — services and PIN. This one bundles allowed services with PIN expectations. 0 = no restrictions, PIN required. 1 = no restrictions. 2 = goods and services only, PIN required. 3 = ATM only, PIN required. 4 = cash only. 5 = goods and services only, no PIN required. 6 = no restrictions, PIN required. 7 = goods and services only, PIN required. So the same card can say "always require a PIN" or "goods and services with no PIN," in one digit.

Read our example service code 201: international interchange with chip preferred (2), normal authorization (0), no restrictions with no PIN requirement (1). That is a standard international chip profile. Once you can read the three digits, a service code stops being noise and becomes a compact statement of how the issuer wants this card treated.

Discretionary data: the part you must not keep

After the service code comes discretionary data — issuer-defined, and the reason PCI exists. On the magnetic stripe this field carries the CVV/CVC (the card verification value encoded in the stripe, distinct from the CVV2 printed on the back) and, for PIN-verification schemes, the PVKI (PIN Verification Key Index) and PVV (PIN Verification Value). These are cryptographic values the issuer uses to validate the card and the PIN.

The rule is absolute: you do not store discretionary data after authorization, and you never log full track data at all. The stripe CVV and the PVV are exactly the secrets that let a fraudster reproduce a working stripe. PCI-DSS forbids retaining them post-authorization, and every real card-data breach of consequence involved someone keeping track data they had no business keeping. When you parse tag 57, treat the discretionary-data tail as radioactive: use it in the moment if you must, and drop it.

Luhn: the cheapest validation you are skipping

Before you send a PAN anywhere, one check costs almost nothing and catches most malformed captures: the Luhn algorithm (ISO/IEC 7812), the check-digit formula every valid card number satisfies. Walk the digits right to left; double every second digit; if a doubled digit exceeds 9, subtract 9; sum everything; a valid PAN makes the total a multiple of 10.

luhn_ok(pan):
    total = 0
    double = false
    for digit d from rightmost to leftmost:
        x = d
        if double:
            x = d * 2
            if x > 9: x = x - 9
        total = total + x
        double = not double
    return total % 10 == 0

Luhn does not tell you the card is real, active, or funded — only that the number is internally consistent. But it turns a class of garbage (a transposed digit, a truncated capture, a fat-fingered test PAN) into a local rejection instead of a wasted authorization round-trip and a confusing decline. It is four lines. Run it at the edge.

Battle scars

Expiry is YYMM, not MMYY. The stripe and tag 57 put the year first. Reverse it and you will "expire" every valid card and pass every actually-expired one. This is the single most common track-2 bug and it survives code review because both orders look plausible.

A 2xx service code on a swipe is a story. When you see a chip-preferred service code arriving from a magnetic-stripe entry mode, something forced a fallback — a broken chip, a malicious downgrade, or a cloned stripe. It is not automatically fraud, but it is automatically worth a second look, and mature acquirers score it.

The stripe CVV is not the printed CVV2. They are different values computed differently and living in different places — the stripe CVV in track discretionary data, the CVV2 printed on the signature panel for card-not-present. Conflating them in your data model leads to storing the wrong secret or validating against the wrong one. Keep them distinct, and keep neither longer than the transaction needs.

Where this fits

Track 2 is the account data that the transaction flow reads out of the card and that ISO 8583 carries to the issuer. It is BER-TLV-wrapped like everything else, so the parsing skill from Part 2 gets you to the field; this article gets you inside it. Resolve 57 (Track 2 Equivalent Data) and 5A (PAN) in the tag dictionary as you go.

Related Reading on gsstk

• What Actually Happens When You Dip a Chip: The EMV Transaction Flow End-to-End — where tag 57 is read from the card.
• Reading BER-TLV by Hand — and Why You Shouldn't — parsing the tag that holds this field.
• ISO 8583 Is Still Everywhere: Parsing the Message That Runs the Rails — where Track 2 travels as DE 35.

Tools: resolve 57 (Track 2 Equivalent Data) and 5A (Application PAN) in the EMV Tag Dictionary.

Filed under: EMV · Payments · POS · Acquiring · Card Issuing

This article was human-architected and synthesized with AI assistance under the Athena (AI) persona.