Skip to main content
Commerce Security Authority
Category: Cardholder Data

Full Track Data

Also known as: Track Data, Magnetic-Stripe Data, Track 1, Track 2
Simply put

Full track data is the complete set of information encoded on the magnetic stripe or chip of a payment card, which is used to help authenticate the card during a transaction. Because it is classified as sensitive authentication data, it must never be stored after a payment has been authorized, even in encrypted form. Storing it creates a significant risk if the data is exposed.

Formal definition

Full track data (also called track data or magnetic-stripe data) refers to the complete contents of any track encoded on a payment card's magnetic stripe or chip, including data commonly designated as Track 1 and Track 2, used for authentication and/or authorization. It is a category of sensitive authentication data (distinct from cardholder data such as PAN, cardholder name, expiration date, and service code) and, per PCI guidance, must not be retained after authorization regardless of encryption. This prohibition is separate from the controls that may permit storage of certain cardholder data elements under defined protections; practitioners should confirm the exact requirement wording against the currently published version of PCI DSS, as numbering and language differ across versions.

Why it matters

Full track data represents one of the most sensitive elements in the payment ecosystem because it contains the complete authentication payload encoded on a card's magnetic stripe or chip. If this data is exposed, it can be used to help produce counterfeit cards or otherwise facilitate fraudulent transactions, which is why PCI guidance classifies it as sensitive authentication data and prohibits its retention after a transaction has been authorized. This prohibition applies even when the data is encrypted, distinguishing full track data from certain cardholder data elements such as the PAN, cardholder name, expiration date, and service code, which may be stored under defined protective controls.

The practical significance for security and compliance teams is that improper storage of full track data creates concentrated risk: a single compromised repository containing retained track data can materially increase the harm resulting from a breach. Because the storage prohibition is absolute regardless of encryption, teams cannot rely on encryption alone as a justification for retention. Practitioners should confirm the exact requirement wording against the currently published version of PCI DSS, as numbering and language differ across versions.

Misunderstanding what qualifies as full track data is a common source of compliance gaps. Some systems inadvertently capture and log the complete track contents during authorization processing, and these residual copies can persist in logs, debugging output, or transaction records without the organization's awareness. Identifying and eliminating such retained data is a recurring focus of assessment and remediation work.

Who it's relevant to

Security Engineers and Application Developers
Engineers building or maintaining payment applications must ensure that systems do not retain the full contents of any track after authorization, including in logs, debugging output, or temporary files. Because the prohibition applies even to encrypted data, encryption cannot be used as a rationale for storing track data, and code paths that handle authorization responses should be reviewed to confirm track contents are not persisted.
Compliance Officers and QSAs
Those assessing or attesting to PCI DSS compliance need to verify that full track data is not stored anywhere in the environment after authorization. This includes distinguishing sensitive authentication data such as full track data from cardholder data elements that may be stored under defined controls, and confirming the applicable requirement wording against the currently published version of PCI DSS, since numbering and language differ across versions.
Payment Processors and Acquirers
Organizations that process or route authorization traffic handle full track data in transit and must ensure it is not inadvertently captured or retained downstream. Because these entities often aggregate large volumes of transactions, unintended retention of track data can concentrate significant risk, making detection and elimination of residual track data a priority.
Merchant Risk and Fraud Teams
Merchant-side teams should understand that exposure of full track data can help facilitate counterfeit card fraud in card-present contexts. While the storage prohibition is primarily a compliance and data-protection control, awareness of what full track data enables helps these teams contextualize the downstream fraud risks associated with a compromise.

Inside Full Track Data

Track 1 data
Data encoded on the first track of a payment card's magnetic stripe, which can include the primary account number (PAN), cardholder name, expiration date, service code, and discretionary data such as card verification values used during authorization.
Track 2 data
Data encoded on the second track of the magnetic stripe, typically including the PAN, expiration date, service code, and discretionary data. Track 2 is commonly used in authorization and is frequently targeted because it can be sufficient to conduct fraudulent transactions.
Equivalent chip data
The full track-equivalent data that may be present on a chip or contactless transaction. Where this equivalent data mirrors full magnetic-stripe track data, it is treated as sensitive authentication data under PCI DSS.
Discretionary data
Additional data elements within the tracks that may include card verification values or codes. These elements are part of sensitive authentication data and are subject to the prohibition on storage after authorization.
Classification as sensitive authentication data
Full track data is categorized as sensitive authentication data (SAD), distinct from cardholder data. Under PCI DSS, sensitive authentication data must not be stored after authorization, even if it is encrypted; readers should confirm the specific requirement wording against the current published version of the standard.

Common questions

Answers to the questions practitioners most commonly ask about Full Track Data.

Can full track data be stored after authorization if it is encrypted?
No. Full track data is sensitive authentication data, and sensitive authentication data must not be stored after authorization even when it is encrypted. Encryption does not create an exception here; the prohibition applies to the data itself once authorization is complete. This differs from certain cardholder data elements, such as the PAN, which may be stored after authorization under defined controls. Confirm the current requirement wording against the published version of PCI DSS, since numbering and phrasing differ between versions.
Is full track data the same thing as the PAN, or just another form of cardholder data?
No. Full track data is not simply the PAN and is not classified as cardholder data. It is sensitive authentication data, a separate category that also includes CAV2/CVC2/CVV2/CID values and PINs and PIN blocks. Full track data is the complete contents of a magnetic stripe track (or the equivalent data on a chip), which can contain the PAN plus additional elements. Because it is sensitive authentication data, it is subject to the stricter storage prohibition that does not apply to all cardholder data.
Where in a transaction flow is full track data typically present, and where should it not persist?
Full track data may be present during the capture and authorization stages, for example when read at the point of interaction and transmitted for authorization. After authorization completes, it should not persist in logs, databases, trace files, memory dumps, or backups. Implementers should review each component that touches the data path to confirm it is not retained after authorization, and should validate handling against the current published PCI DSS requirements.
How can teams verify that full track data is not being inadvertently retained?
Teams commonly review application code, debug and error logs, transaction trace files, database tables, temporary files, memory handling, and backup images for any retention of track contents after authorization. Because storage can occur unintentionally through logging or debugging, searches should cover both intended data stores and incidental locations. Any detection approach has trade-offs, including false negatives if a search pattern does not match how the data is encoded, so results should be corroborated across multiple methods and validated against the current standard.
How does truncation, masking, tokenization, or hashing relate to full track data handling?
These techniques transform or reduce data differently and are most often discussed in the context of the PAN and other cardholder data rather than as a means to retain full track data. Because full track data is sensitive authentication data that must not be stored after authorization, applying a transformation is not a substitute for the prohibition against retention. Whether any technique affects scope depends on its specific implementation and validation, not on the label alone. Confirm applicable handling against the current published PCI DSS.
What documentation and controls help demonstrate that full track data is not stored after authorization?
Organizations typically document their data flows to show where full track data enters and confirm it is not retained beyond authorization, along with configuration of logging and debugging to avoid capturing it, and procedures for handling temporary files, memory, and backups. Evidence may include data-flow diagrams, review results, and process controls. The specific validation expectations and requirement wording vary by PCI DSS version, so map controls to the current published standard rather than to a fixed requirement number.

Common misconceptions

Full track data can be stored after authorization as long as it is encrypted.
Full track data is sensitive authentication data, which must not be retained after authorization even when encrypted. Encryption does not create an exception to the prohibition on storage of this data under PCI DSS.
Full track data and cardholder data are the same thing and follow the same storage rules.
They are distinct categories. Certain cardholder data elements (such as the PAN) may be stored under defined controls, whereas full track data belongs to sensitive authentication data and is subject to the no-storage-after-authorization rule. The data elements can overlap, but their storage treatment differs.
Chip and contactless transactions never involve full track data, so the storage prohibition does not apply.
Where chip or contactless transactions produce full track-equivalent data, that data is treated as sensitive authentication data and is subject to the same prohibition on storage after authorization.

Best practices

Confirm that no system, log, database, or file retains full track data or track-equivalent data after authorization, and verify this against the current published version of PCI DSS rather than assuming a fixed requirement number.
Inventory and map all locations where authorization data may transiently exist, including application logs, debug traces, memory dumps, and error messages, to ensure full track data is not inadvertently persisted.
Treat full track data as sensitive authentication data and apply the no-storage-after-authorization rule regardless of whether the data is encrypted.
Distinguish full track data from stored cardholder data in policies and controls, so that permitted cardholder data storage under defined controls is not confused with prohibited sensitive authentication data.
Include chip and contactless transaction flows in scope reviews to ensure any full track-equivalent data is handled under the same prohibition.
Validate storage and handling controls through review and testing, and document that discretionary data and card verification values within the tracks are not retained after authorization.