The Concept of a File System Inside a Card

An EMV chip card is not just a container of flat data — it implements a structured file system similar in concept to simplified smart card operating systems. This structure allows controlled access to data, logical separation of applications, and enforcement of security policies.

At the top level sits the Master File (MF), which acts as the root of the hierarchy. Under it are Dedicated Files (DFs), representing applications or logical groupings. Inside those, Elementary Files (EFs) store actual data.

Unlike traditional file systems, access to these files is not based on open/read/write calls but on APDU commands with strict rules. Every operation must follow a defined sequence, and access conditions are enforced at the file level.

Application Selection and AID

Before any data can be accessed, the terminal must select an application using its Application Identifier (AID). This is a unique value that identifies a payment application, such as a credit or debit scheme.

The card may contain multiple AIDs, each corresponding to a different application. During the selection process, the terminal sends a SELECT command, and the card responds with information about the chosen application.

This response often includes the File Control Information (FCI), which provides metadata such as application label, priority, and pointers to further data structures.

The AID acts as the entry point into the card’s internal data hierarchy.

File Control Information and Its Role

File Control Information (FCI) is one of the first structured data blocks returned by the card. It is encoded using TLV (Tag-Length-Value) format and contains critical information for initializing the transaction.

FCI typically includes the Dedicated File name, application label, and proprietary data elements. It may also provide references to other files that must be accessed during the transaction.

Understanding FCI is essential because it defines how the terminal navigates the rest of the card’s data. Misinterpreting it can lead to incorrect application behavior or transaction failure.

Elementary Files and Record-Based Storage

Within an application, data is stored in Elementary Files (EFs). These files are often record-based, meaning they consist of multiple records that can be read individually.

Accessing these records involves issuing READ RECORD commands with specific parameters. The structure and numbering of records are defined by the card and must be interpreted correctly by the terminal.

Each record contains TLV-encoded data elements, which represent various aspects of the card and transaction.

This record-based approach allows flexible organization but requires precise handling to avoid errors.

TLV Encoding: The Core Data Format

All EMV data is encoded using the TLV (Tag-Length-Value) format. Each data element consists of a tag that identifies its meaning, a length field, and the value itself.

Tags can be one or multiple bytes long and may be primitive or constructed. Constructed tags contain nested TLV structures, creating a hierarchical data model.

Parsing TLV data is a fundamental task for any EMV implementation. Errors in parsing can lead to misinterpretation of critical data, affecting transaction outcomes.

Efficient TLV handling is especially important in constrained environments like contactless transactions.

Critical EMV Tags and Their Meaning

Certain tags play a central role in EMV transactions. For example, the Primary Account Number (PAN) is stored under a specific tag, along with expiration date and service codes.

Other important tags include the Application Interchange Profile (AIP), which indicates supported features, and the Application File Locator (AFL), which tells the terminal which records to read.

The AFL is particularly important because it acts as a roadmap for data retrieval. It defines which Elementary Files and records contain relevant information for the transaction.

Misinterpreting these tags can break the entire transaction flow.

Application File Locator and Data Retrieval

The Application File Locator (AFL) is a compact structure that specifies which records should be read from the card. It contains entries that define the Short File Identifier (SFI), record range, and whether the data is used for offline authentication.

Using the AFL, the terminal systematically reads all required records without needing to guess the file structure. This ensures consistent behavior across different cards and implementations.

However, errors in AFL interpretation are a common source of bugs. Incorrect record ranges or SFI handling can result in missing data or failed authentication.

Data Object Lists: CDOL, DDOL, TDOL

EMV defines several Data Object Lists (DOLs) that specify which data elements must be provided during certain operations.

The Card Risk Management Data Object List (CDOL) defines the data required for generating cryptograms. The Dynamic Data Authentication Data Object List (DDOL) is used during authentication processes. The Terminal Data Object List (TDOL) is used for transaction certificate generation.

Each DOL is essentially a template that lists required tags and their expected lengths. The terminal must construct data fields according to these templates and provide them to the card.

Failure to correctly build DOL data results in transaction errors or cryptographic failures.

Issuer and Terminal Action Codes

Within the card’s data structure, there are also action codes that influence decision-making. Issuer Action Codes (IAC) and Terminal Action Codes (TAC) define how different conditions should be handled.

These codes are bitmaps that specify whether a transaction should be approved offline, declined, or sent online under certain conditions.

They are stored as TLV data elements and processed by the kernel during risk management.

Understanding these codes is essential for interpreting transaction outcomes and debugging unexpected behavior.

Track Data Emulation Inside the Chip

Interestingly, EMV chips often store track-equivalent data to maintain compatibility with legacy systems. This includes Track 2 Equivalent Data, which mirrors the format of magnetic stripe data.

However, this data is not used in the same way as in magnetic stripe transactions. It is typically combined with dynamic elements and cryptographic protections.

The presence of this data highlights the transitional nature of EMV systems, bridging old and new technologies.

Proprietary and Scheme-Specific Tags

In addition to standardized EMV tags, cards often include proprietary or scheme-specific data elements. These tags may contain additional parameters, risk settings, or features unique to a particular payment network.

Handling these tags requires access to scheme documentation and careful implementation. Ignoring or misinterpreting them can lead to subtle bugs or certification issues.

This adds another layer of complexity to EMV data handling, as not all tags are universally defined.

Security of Stored Data

Data stored within the chip is protected by access conditions and, in some cases, encryption. Not all data is readable, and some elements can only be accessed under specific circumstances.

Sensitive operations, such as generating cryptograms, are performed internally by the chip. The terminal never gains direct access to secret keys or critical internal states.

This controlled access model ensures that even if a terminal is compromised, the card’s core security remains intact.

APDU Commands: How Terminals Talk to the Chip

All interaction with an EMV card happens through APDU (Application Protocol Data Unit) commands. These are low-level messages exchanged between the terminal and the chip, forming the backbone of the entire transaction process.

Each APDU consists of a header (CLA, INS, P1, P2), an optional data field, and an expected response length. The card processes the command and returns a response APDU containing data and a status word.

Key commands include SELECT, GET PROCESSING OPTIONS (GPO), READ RECORD, GENERATE AC, and VERIFY. Each of these triggers specific logic inside the chip and drives the transaction forward.

Strict sequencing is required. Sending commands out of order or with incorrect parameters typically results in immediate failure.

SELECT and GPO: Entering the Application

The transaction begins with the SELECT command, which targets a specific AID. The response includes FCI data, providing the initial context for further processing.

Next comes the GET PROCESSING OPTIONS (GPO) command. This is where the terminal submits data constructed from the PDOL (Processing Data Object List), if present.

The GPO response is critical. It usually contains the AIP (Application Interchange Profile) and AFL (Application File Locator), effectively defining the capabilities of the card and the roadmap for data retrieval.

Errors at this stage often cascade into larger issues later in the transaction.

READ RECORD: Extracting Structured Data

Once the AFL is known, the terminal issues READ RECORD commands to retrieve data from Elementary Files. Each command targets a specific record within a file identified by its Short File Identifier (SFI).

The returned data is TLV-encoded and may contain multiple tags. The terminal must parse and store this data for later use in the transaction.

A common mistake is assuming that records are uniform across cards. In reality, different issuers may structure records differently, requiring flexible parsing logic.

Another frequent issue is improper handling of missing or optional records, which can lead to incomplete data sets.

GENERATE AC: The Core Cryptographic Operation

The GENERATE APPLICATION CRYPTOGRAM (GENERATE AC) command is one of the most important steps in the EMV flow. It instructs the card to produce a cryptogram based on the provided data.

The terminal constructs input data according to the CDOL and sends it to the card. The card processes this data along with its internal state and secret keys to generate a response.

The response includes the cryptogram, a Cryptogram Information Data (CID) field, and additional TLV data.

This step determines whether the transaction will proceed offline, go online, or be declined. Any mismatch in input data formatting or ordering will result in incorrect cryptogram generation.

VERIFY and PIN Handling

For transactions requiring PIN verification, the VERIFY command is used. This command interacts with the card’s internal PIN verification logic.

Offline PIN verification happens entirely within the chip, while online PIN involves external systems. The kernel must correctly interpret the CVM list and trigger the appropriate flow.

Timing and user interaction are critical here. Delays or incorrect handling of PIN entry can cause the transaction to fail.

Additionally, retry counters and blocking conditions must be respected, as repeated failures can permanently disable PIN verification on the card.

TLV Parsing: Real-World Pitfalls

While TLV encoding appears straightforward, real-world implementations are full of edge cases. Tags may be multi-byte, lengths may be variable, and constructed tags can contain deeply nested structures.

One common mistake is assuming fixed lengths for certain tags. In reality, lengths can vary depending on the card and context.

Another issue is improper handling of constructed tags. Failing to recursively parse nested TLVs leads to incomplete data extraction.

Buffer management is also critical. Overflows, truncation, or incorrect memory handling can introduce subtle bugs that are difficult to trace.

Robust TLV parsing requires defensive programming and thorough validation.

Handling Optional and Missing Data

EMV specifications allow for optional data elements. Not all cards provide the same set of tags, and terminals must handle these variations gracefully.

Assuming the presence of a tag can lead to crashes or incorrect behavior. Instead, implementations must check for existence and apply fallback logic where appropriate.

Default values, conditional flows, and scheme-specific rules often come into play when dealing with missing data.

This variability is one of the reasons why EMV implementations are so complex compared to simpler data formats.

Status Words and Error Interpretation

Every APDU response ends with a status word (SW1, SW2), which indicates the result of the command. Correct interpretation of these values is essential.

Status words can indicate success, warnings, or errors. Some values require additional action, such as issuing a GET RESPONSE command to retrieve remaining data.

Misinterpreting status words is a common source of bugs. For example, treating a warning as a success or ignoring required follow-up actions can break the transaction flow.

Developers must implement comprehensive handling for all relevant status codes defined in EMV and ISO standards.

Timing Constraints and Contactless Challenges

In contactless transactions, APDU exchanges must occur within strict timing limits. Delays in processing or communication can cause the transaction to abort.

This places additional pressure on TLV parsing, data construction, and cryptographic operations. Everything must be optimized for speed without sacrificing correctness.

Retry mechanisms are limited, and error recovery options are fewer compared to contact transactions.

As a result, even minor inefficiencies can have a noticeable impact on transaction success rates.

Data Consistency Across the Transaction

Throughout the transaction, data is collected from multiple sources: terminal configuration, card responses, and user input. Maintaining consistency across these data sets is critical.

For example, values used in cryptogram generation must match those expected by the card. Any discrepancy can lead to authentication failure.

This requires careful data management, including proper storage, retrieval, and synchronization of TLV elements.

Inconsistent data handling is a frequent cause of hard-to-debug issues in EMV implementations.

Logging and Trace Analysis

Given the complexity of APDU interactions, detailed logging is indispensable. Logs should capture command sequences, raw APDU data, parsed TLV structures, and decision points.

Trace analysis allows developers to reconstruct transaction flows and identify where things went wrong.

However, logging must be implemented carefully to avoid exposing sensitive data. Masking or omitting critical fields is often required for compliance.

Effective logging strikes a balance between visibility and security.

Interoperability Issues Across Cards

Different issuers and card profiles may exhibit subtle variations in behavior. Some cards may include additional tags, omit optional ones, or interpret specifications differently.

Terminals must be robust enough to handle this diversity. Rigid implementations that only work with a narrow set of card profiles are prone to failure in real-world deployments.

Interoperability testing with a wide range of cards is essential to ensure compatibility.

Why Parsing Is Harder Than It Looks

At first glance, EMV data structures and APDU commands may seem manageable. However, the combination of nested TLVs, optional fields, strict sequencing, and cryptographic dependencies creates a highly complex system.

Parsing is not just about reading data — it is about understanding context, maintaining state, and ensuring that every piece of information is used correctly.

Small mistakes can propagate through the transaction, leading to failures that are difficult to diagnose.

In practice, reliable EMV parsing requires deep expertise, careful design, and extensive testing.

Closing Perspective: Data as a Controlled Interface

The EMV chip does not expose its internal state freely. Instead, it presents a carefully controlled interface through files, tags, and APDU commands.

Every piece of data is structured, validated, and often protected by cryptographic mechanisms. This design ensures that the card remains secure even in untrusted environments.

Compared to the simplicity of magnetic stripe data, EMV represents a shift toward structured, interactive, and secure data exchange.

Understanding this structure is key to building reliable payment systems — and to appreciating why working with EMV data is both powerful and challenging.