In the rapidly evolving world of secure digital payments, EMV (Europay, Mastercard, and Visa) standards have become the foundation of chip-based transaction security. At the core of any EMV-enabled device lies a critical component the EMV Level 2 Kernel. This kernel manages the transaction flow and ensures that card-present transactions are carried out in a secure, structured, and compliant manner.

The EMV Kernel operates as a middleware layer between the terminal’s application (Level 3) and the physical or contactless communication interface (Level 1). The kernel implements the EMV specifications required for transaction processing and facilitates interoperability with global card schemes. This article outlines the complete EMV Kernel transaction process, explaining each of the 14 sequential steps in great depth.

Kernel Initialization

The transaction begins with the initialization of the EMV kernel. During this step, the terminal application loads all necessary configuration parameters into the kernel, preparing it to process the transaction. These parameters include terminal capabilities, terminal country code, transaction currency code, transaction type (e.g., purchase, refund), and the transaction amount.

The terminal also identifies the type of interface in use (contact, contactless, or dual-interface) and determines whether fallback procedures are necessary (e.g., from chip to magnetic stripe).

This step also involves preparing the Application Identifier (AID) list—identifiers of applications that the terminal supports. The AID is used to match and select an appropriate application from the card.

Application Selection

Once the kernel has been initialized, the terminal initiates the Application Selection process. The terminal reads the list of supported applications on the card and compares them with its own AID list. If multiple matching applications are found, the cardholder may be prompted to choose one. If only one match is found, it is automatically selected.

This step is essential to determine which payment application (e.g., Visa Debit, Mastercard Credit) will govern the subsequent transaction flow. Proper selection ensures that both the terminal and the card are speaking the same language in terms of cryptographic protocols, authentication mechanisms, and data structures.

Get Processing Options (GPO)

After a valid application is selected, the terminal sends the “Get Processing Options” (GPO) command to the card. This command contains a structure known as the Processing Data Object List (PDOL), which defines the data the terminal must send to the card to initiate processing.

In response, the card returns:

• Application Interchange Profile (AIP): Describes the card’s capabilities, including support for offline data authentication (ODA), cardholder verification methods (CVM), and more.
• Application File Locator (AFL): Informs the terminal where to find the records it needs to read from the card.

The GPO is a handshake that ensures both the terminal and card agree on transaction capabilities and outlines the next steps.

Read Application Data

Guided by the AFL received during the GPO step, the terminal now reads the necessary data records from the card. These records include static and dynamic card data such as:

• PAN (Primary Account Number)
• Card expiration date
• Cardholder name
• CVR (Card Verification Results)
• Track 2 equivalent data
• Application usage control (AUC)
• Issuer country code

This data is vital for risk analysis, cardholder verification, and transaction authorization later in the process. These records are read using READ RECORD commands, and any failure may result in the transaction being terminated.

Offline Data Authentication (ODA)

One of the primary functions of the EMV kernel is to validate the card’s authenticity before the transaction proceeds. Offline Data Authentication (ODA) serves this purpose without requiring online communication with the card issuer.

The card and terminal may support one or more ODA techniques:

• Static Data Authentication (SDA): Uses a digital signature to verify that static card data has not been altered.
• Dynamic Data Authentication (DDA): Adds a challenge-response mechanism using a dynamic cryptogram to detect cloned cards.
• Combined DDA/Application Cryptogram Generation (CDA): Offers both DDA and transaction signing in one cryptogram for enhanced security.

The kernel invokes cryptographic operations and validates the authenticity of card-supplied data using the terminal’s public key infrastructure.

Processing Restrictions

Processing restrictions determine whether the card is permitted to be used for this transaction. The terminal evaluates multiple data elements to ensure compatibility and validity.

Checks include:

• Application version number compatibility
• Application Usage Control (AUC): Defines whether the card can be used internationally, for ATMs, etc.
• Card expiration and effective date
• Card status (e.g., blocked, test card)

If the card violates any processing restrictions, the kernel may decide to decline the transaction immediately.

Cardholder Verification

Cardholder Verification Method (CVM) confirms whether the person presenting the card is its legitimate holder. The EMV kernel evaluates the Cardholder Verification Method List (CVM List) supplied by the card and applies it based on terminal capabilities and transaction context.

Common CVMs include:

• Offline PIN (plaintext or enciphered)
• Online PIN (sent to issuer)
• Signature
• No CVM Required (for low-value transactions or contactless)

The kernel checks for CVM results and passes any required prompts to the terminal application. Failure of CVM may lead to transaction rejection.

Terminal Risk Management

Before initiating authorization, the terminal performs risk management to assess the level of risk involved in continuing the transaction offline. This includes:

• Comparing transaction amount against the floor limit
• Checking exception files for blacklisted PANs
• Applying velocity checking or random transaction selection criteria

If the risk is deemed high, the kernel may recommend an online authorization, even if the card could support offline approval.

Terminal Action Analysis

Based on outcomes from previous steps, the kernel performs Terminal Action Analysis (TAA) to determine whether the transaction should be approved offline, declined, or sent online for issuer authorization.

This decision is based on Terminal Action Codes (TACs) and Issuer Action Codes (IACs). These are bitmaps representing actions to take under various conditions (e.g., if CVM failed, if ODA failed).

The terminal creates a Terminal Verification Results (TVR) structure summarizing the transaction status, and the final decision is used to trigger the next action—usually the first Generate AC.

Generate Application Cryptogram (1st AC)

The terminal sends the first Generate AC command to the card, requesting it to generate an Application Cryptogram (AC) based on the transaction data. The card responds with one of the following:

• ARQC (Authorization Request Cryptogram): Indicates that the card wants online authorization.
• AAC (Application Authentication Cryptogram): Indicates that the card declines the transaction.
• TC (Transaction Certificate): Approves the transaction offline.

The cryptogram is a signed hash of transaction data, confirming the integrity and origin of the data.

Online or Offline Authorization

If the card returns an ARQC, the terminal sends the transaction data and cryptogram to the issuer over a secure network for real-time authorization. The issuer responds with:

• Approval or denial of the transaction
• Authorization response code (ARC)
• Optional issuer scripts for post-processing

In an offline scenario (TC or AAC), the terminal does not communicate with the issuer and continues based on terminal and kernel analysis.

Generate AC (2nd)

Following issuer authorization (or offline decision), the terminal sends a second Generate AC command to the card. This step finalizes the transaction state.

The card responds with:

• TC (Transaction Certificate): Transaction is approved.
• AAC (Application Authentication Cryptogram): Transaction is declined.

The EMV kernel uses this information to determine final transaction outcome, and this is passed back to the terminal application.

Issuer Script Processing

If issuer scripts were received during online authorization, the kernel processes them now. These scripts allow the issuer to update card parameters or instruct the card to perform specific actions (e.g., block card, change offline PIN).

The kernel parses the scripts and executes them as per EMV-defined tags and commands. Failure in script processing could impact the transaction result or trigger further action.

Transaction Completion

The transaction is now complete. The kernel returns a final result (approved or declined) along with any data necessary for receipt printing, reconciliation, or settlement.

At this stage, the terminal may:

• Display or print the transaction result
• Prompt for signature if required
• Store transaction data for end-of-day batch upload

In contactless environments, the entire process must be optimized for speed and minimal cardholder interaction, often bypassing CVM for small-value transactions.

Understanding the EMV Kernel transaction flow is essential for payment terminal developers, QA engineers, EMV certification teams, and fintech providers. Each step, from kernel initialization to transaction completion, ensures a high level of transaction integrity, cardholder protection, and fraud mitigation.

With the growing demand for secure and contactless payments, the role of the EMV Level 2 kernel remains indispensable in the payment ecosystem. Its layered, deterministic approach ensures interoperability with a wide range of cards and schemes while upholding international standards of security and compliance.