Magnetic Stripe Track Data Explained: Track 1 & Track 2 Format Guide

Swipe a credit card through a reader and in under 200 milliseconds, a thin strip of iron oxide particles has delivered your complete payment credentials — account number, name, expiration date, and a cryptographic verification value — all encoded as magnetic flux reversals on a piece of plastic. That strip has been the backbone of card payments since the 1960s, and understanding its data format is still essential for anyone working in payment processing today.

What is Magnetic Stripe Data?

Magnetic stripe data (commonly called track data) is the information encoded on the magnetic stripe found on the back of payment cards. The stripe contains up to three tracks of data defined by ISO/IEC 7811 and ISO/IEC 7813, each with a specific format, character set, and purpose.

When a card is swiped at a point-of-sale terminal, the reader captures the magnetic flux transitions and converts them into the digital characters that make up Track 1 and Track 2 data. This data flows through the payment network inside ISO 8583 messages, ultimately reaching the card issuer for authorization.

Track data is considered Sensitive Authentication Data (SAD) under PCI DSS — it must never be stored after authorization, making it one of the most protected data elements in the entire payment ecosystem.

Try it yourself: Paste a raw ISO 8583 message containing Fields 35 or 45 into our ISO 8583 Studio to see track data parsed in context.

Also Known As…

Magnetic stripe data goes by many names across different documentation:

How the Magnetic Stripe Works

The magnetic stripe on a payment card consists of three separate tracks, each recorded at a different position on the stripe. The encoding uses a technique called F2F (Frequency/double Frequency) encoding, where data is represented as magnetic flux transitions.

Physical Layout

Card Back (magnetic stripe area):
┌──────────────────────────────────────────────────┐
│  Track 1 (IATA) — 210 bpi — 79 chars max        │  ← Top
│  Track 2 (ABA)  — 75 bpi  — 40 chars max        │  ← Middle
│  Track 3 (THRIFT) — 210 bpi — 107 chars max     │  ← Bottom
└──────────────────────────────────────────────────┘

Coercivity: HiCo vs. LoCo

The magnetic stripe itself comes in two strengths:

Payment cards universally use HiCo stripes because they resist accidental demagnetization from proximity to magnets, phones, or other cards.

Track 1 Data Format (IATA)

Track 1 is the most information-rich track. Originally defined by the International Air Transport Association (IATA) for airline ticketing, it was adopted by the banking industry because it includes the cardholder’s name — critical for card-present verification.

Field-by-Field Breakdown

%B4111111111111111^DOE/JOHN Q^26012011000000000000?
│ │                │          │                    │
│ │                │          │                    └── End Sentinel: ?
│ │                │          └── Discretionary Data + Check (LRC)
│ │                └── Field Separator: ^
│ └── PAN (Primary Account Number)
└── Start Sentinel + Format Code: %B

Worked Example

Let’s parse this complete Track 1 string character by character:

%B4111111111111111^DOE/JOHN Q^26012011000000000000?

Validate the PAN: Paste 4111111111111111 into our Luhn Validator to confirm it passes the Luhn check.

Name Encoding Rules

The cardholder name follows specific formatting conventions:

The name field is padded with spaces to fill its allocated space (up to 26 characters). Characters are limited to uppercase A-Z, spaces, periods, and a few special characters.

Track 2 Data Format (ABA)

Track 2 is the workhorse of payment processing. Defined by the American Bankers Association (ABA), it carries the same critical payment data as Track 1 but in a more compact, numeric-only format. Most modern payment systems rely on Track 2 as the primary data source.

Field-by-Field Breakdown

;4111111111111111=26012011000000000000?
│                │                    │
│                │                    └── End Sentinel: ?
│                │
│                └── Separator: =
└── Start Sentinel + PAN: ;4111111111111111

Worked Example

Parse this Track 2 string:

;4111111111111111=26012011000000000000?

Key difference from Track 1: Track 2 has no cardholder name. This is why some legacy systems that require name verification must read Track 1.

Track 3 Data Format

Track 3 was originally designed by the Thrift Industry for ATM and debit transactions. It supports read/write operations, allowing the stripe to be updated after each transaction — a concept that was eventually replaced by online authorization.

Track 3 is not included in ISO 8583 messaging. If you encounter it, you’re likely dealing with a legacy closed-loop system.

Track 1 vs Track 2: Side-by-Side Comparison

Both tracks contain the same financial data. The primary difference is that Track 1 includes the cardholder name and uses an alphanumeric character set, while Track 2 is purely numeric and therefore more compact and reliable to read.

Service Codes Explained

The 3-digit service code appears in both Track 1 and Track 2. Each digit controls a different aspect of how the card should be processed:

Service Code: [D1][D2][D3]
               │    │    │
               │    │    └── Digit 3: Allowed Services & PIN
               │    └── Digit 2: Authorization Processing
               └── Digit 1: Interchange & Technology

Digit 1 — Interchange and Technology

Digit 2 — Authorization Processing

Digit 3 — Allowed Services and PIN

Common Service Code Combinations

Look up any code: Our Reference Database has a complete, searchable service code reference with deep-linking.

CVV, CVC, and CID in Track Data

The Card Verification Value (CVV) — or CVC (Mastercard), CID (Amex/Discover) — is a cryptographic value embedded in the discretionary data portion of both tracks. Critically, the track data CVV is different from the 3-digit number printed on the back of the card.

How CVV1 Works

CVV1 is calculated using:

1. The PAN (Primary Account Number)
2. The expiration date
3. The service code
4. A pair of DES keys known only to the issuer

The resulting 3-digit value is embedded in the discretionary data of both tracks. When the issuer receives the track data in an authorization request, it recalculates the CVV and compares it. If the values don’t match, the card is likely counterfeit.

Learn about cryptographic operations: Our HSM Basics for Developers guide explains how HSMs verify CVV values during authorization.

CVV1 vs iCVV: The Fraud Detection Trick

EMV chip cards deliberately use a different CVV value (iCVV) when generating magnetic stripe equivalent data. This allows issuers to detect a specific type of fraud:

This is why POS Entry Mode code 95 exists — it tells the issuer that the chip was read but the CVV/iCVV data may be unreliable. See our POS Entry Mode Guide for the full code breakdown.

Track Data in ISO 8583

Track data is carried in two specific ISO 8583 fields:

How It Appears in a Message

In a typical ISO 8583 authorization request (MTI 0100), the track data sits alongside other familiar fields:

MTI:  0100 (Authorization Request)

Field 2  (PAN):          4111111111111111
Field 3  (Processing):   000000
Field 4  (Amount):       000000001000
Field 22 (Entry Mode):   901        ← Full mag stripe read, PIN capable
Field 35 (Track 2):      4111111111111111=26012011000000000000
Field 45 (Track 1):      B4111111111111111^DOE/JOHN Q^26012011000000000000

Note that Field 22 value 90 means “Magnetic stripe — full track data, unaltered.” The presence of Fields 35/45 should be consistent with this entry mode.

Parse a full message: Paste raw hex data into the ISO 8583 Studio to see Fields 35 and 45 decoded alongside the bitmap and all other data elements.

Which Track Does the Network Use?

Security and PCI DSS Requirements

Track data is classified as Sensitive Authentication Data (SAD) under PCI DSS. The rules are absolute:

What Happens If You Store Track Data

Storing full track data post-authorization is the most serious PCI violation a merchant or processor can commit:

Clean your logs: Use the PCI Sanitizer to detect and mask any track data that may have leaked into log files, support tickets, or debug output.

Why Track Data Encryption Matters

When track data is captured by a terminal, it should be encrypted immediately at the point of interaction before traversing any network. This is where DUKPT comes in — the standard key management scheme for encrypting track data at POS terminals.

Card Swipe → POS Terminal → DUKPT Encrypt → Encrypted Track Data → Network → HSM Decrypt
                                                                                   ↓
                                                                           Clear Track Data
                                                                           (HSM memory only)

Deep dive: Learn how DUKPT generates a unique encryption key for every swipe in our DUKPT Key Management Guide.

JavaScript Track Data Parser

Here’s a parser for both Track 1 and Track 2 data:

function parseTrack1(raw) {
    // Track 1 format: %BPAN^NAME^YYMMSSSDDDDDDDDDDDDDD?
    const match = raw.match(
        /^%([A-Z])(\d{1,19})\^([^^]{2,26})\^(\d{4})(\d{3})(.+)\?$/
    );
    if (!match) return { error: 'Invalid Track 1 format' };

    return {
        formatCode: match[1],
        pan: match[2],
        name: match[3].trim(),
        expiration: match[4],         // YYMM
        serviceCode: match[5],
        discretionaryData: match[6]
    };
}

function parseTrack2(raw) {
    // Track 2 format: ;PAN=YYMMSSSDDDDDDDDDDDDDD?
    const match = raw.match(
        /^;(\d{1,19})=(\d{4})(\d{3})(.+)\?$/
    );
    if (!match) return { error: 'Invalid Track 2 format' };

    return {
        pan: match[1],
        expiration: match[2],         // YYMM
        serviceCode: match[3],
        discretionaryData: match[4]
    };
}

// Test with standard test card data
const t1 = parseTrack1('%B4111111111111111^DOE/JOHN Q^26012011000000000000?');
console.log(t1);
// { formatCode: 'B', pan: '4111111111111111',
//   name: 'DOE/JOHN Q', expiration: '2601',
//   serviceCode: '201', discretionaryData: '1000000000000' }

const t2 = parseTrack2(';4111111111111111=26012011000000000000?');
console.log(t2);
// { pan: '4111111111111111', expiration: '2601',
//   serviceCode: '201', discretionaryData: '1000000000000' }

100% client-side: Like all our tools, this runs entirely in your browser. No data is ever sent to a server.

Quick Reference: Track Data Fields

The Magnetic Stripe Phase-Out

The industry is actively moving away from magnetic stripes in favor of EMV chip and contactless technology:

Despite the phase-out, magnetic stripe data formats remain foundational knowledge. EMV chip transactions still generate magnetic stripe equivalent data for backward compatibility, and the track data format is embedded in ISO 8583 field definitions that are unlikely to change.

Next Steps

Now that you understand magnetic stripe track data:

1. Parse raw messages with the ISO 8583 Studio to see Fields 35 and 45 decoded in real messages
2. Look up service codes in the Reference Database for quick interchange rule lookups
3. Understand POS entry modes in our POS Entry Mode Guide — entry modes 02 and 90 indicate magnetic stripe reads
4. Learn how track data is encrypted in our DUKPT Key Management Guide — unique key per swipe
5. Protect track data with the PCI Sanitizer — mask sensitive data before sharing logs
6. Validate the PAN with the Luhn Validator — confirm the account number from track data passes checksum

This post is part of the ISO 8583 Mastery series. Follow along as we explore payment messaging in depth.