Every time you tap or insert a chip card, the card generates a unique cryptogram — a cryptographic proof that this specific transaction is legitimate and hasn’t been seen before. This single mechanism is what makes EMV fundamentally more secure than magnetic stripe, and why cloning chip cards is effectively impossible.

This article explains how EMV cryptograms work, focusing on the ARQC (Authorization Request Cryptogram) and why it’s the backbone of card-present fraud prevention.

The concepts discussed here complement the security and EMV architecture material in POINT OF SALE ARCHITECTURE — Volume 1: A Practical Guide to Secure, Certifiable POS Systems (the book), which provides the broader context for how cryptograms fit into end-to-end transaction flows.

What Is an EMV Cryptogram?

An EMV cryptogram is an 8-byte (64-bit) MAC (Message Authentication Code) generated by the chip card using:

1. Transaction-specific data — amount, currency, date, terminal info
2. Card-specific secrets — unique keys derived per card
3. A counter — the Application Transaction Counter (ATC) that increments with every transaction

The cryptogram proves three things:

• ✅ The card is genuine (knows the secret key)
• ✅ The transaction data hasn’t been tampered with
• ✅ This exact transaction has never been submitted before

Types of EMV Cryptograms

The card can generate three types of cryptograms depending on the transaction outcome:

The terminal requests a cryptogram by sending a GENERATE AC command. The card’s risk management logic determines which type to return.

For most card-present transactions today, the flow involves an ARQC sent to the issuer for online authorization.

How ARQC Is Generated

The ARQC is computed using 3DES (Triple DES) or AES in CBC-MAC mode, with inputs that make each transaction unique.

Input Data (CDOL1)

The issuer defines what data goes into the cryptogram via the Card Risk Management Data Object List 1 (CDOL1). A typical CDOL1 includes:

The Key Hierarchy

Each card has a unique derived key (UDK) that is mathematically derived from the issuer’s master key using the card’s PAN and sequence number. This means:

• No two cards share the same cryptographic key
• Compromising one card reveals nothing about other cards
• The issuer can verify any card’s cryptogram using only the master key

$$ \text{UDK} = f(\text{IMK}, \text{PAN}, \text{PSN}) $$

For each transaction, a session key is derived from the UDK using the ATC:

$$ \text{Session Key} = f(\text{UDK}, \text{ATC}) $$

ARQC Computation

The cryptogram is computed as:

$$ \text{ARQC} = \text{MAC}_{\text{SK}}(\text{CDOL1 Data}) $$

Where:

• $\text{SK}$ = Session Key (derived from UDK and ATC)
• $\text{CDOL1 Data}$ = Concatenated transaction data per CDOL1
• $\text{MAC}$ = 3DES CBC-MAC or AES CMAC (8 bytes)

The result is an 8-byte value that is unique to this exact transaction on this exact card.

The Online Authorization Flow

Here’s how the ARQC flows through the payment ecosystem:

┌─────────┐      ┌──────────┐      ┌──────────┐      ┌────────┐
│  Card   │─────▶│ Terminal │─────▶│ Acquirer │─────▶│ Issuer │
└─────────┘      └──────────┘      └──────────┘      └────────┘
     │                │                  │                │
     │  ARQC + Data   │   ISO 8583       │   ISO 8583     │
     │◀──────────────▶│   (DE55)         │                │
     │                │◀────────────────▶│◀──────────────▶│
     │                │                  │                │
     │                │   ARPC           │   Verify ARQC  │
     │◀───────────────│◀─────────────────│◀───────────────│
     │                │                  │   Generate ARPC│
     │                │                  │                │

Step-by-Step

1. Terminal sends GENERATE AC command to the card
2. Card computes ARQC using transaction data + session key
3. Card returns ARQC + ATC + other data to terminal
4. Terminal packages ARQC in DE 55 (EMV data) of ISO 8583 message
5. Acquirer forwards to the issuer (or issuer processor)
6. Issuer reconstructs the session key using:
   • Master Key + PAN + PSN → UDK
   • UDK + ATC → Session Key
7. Issuer recomputes the expected ARQC using the same transaction data
8. Issuer compares: if ARQC matches → card is genuine, data is intact
9. Issuer generates ARPC (response cryptogram) and sends approval/decline
10. Terminal sends ARPC to card for verification (optional second GENERATE AC)

Why ARQC Prevents Replay Attacks

The ARQC mechanism defeats the most common attack vectors:

1. Transaction Replay

Attack: Capture a valid authorization and replay it to get goods/money.

Defense: The ATC (Application Transaction Counter) increments with every transaction. The issuer tracks the last-seen ATC and rejects any transaction with an ATC ≤ the last known value.

Transaction 1: ATC = 00A1, ARQC = 3F8B2C...  ✅ Approved
Replay:        ATC = 00A1, ARQC = 3F8B2C...  ❌ Rejected (ATC already used)
Transaction 2: ATC = 00A2, ARQC = 7D4E1A...  ✅ Approved

2. Card Cloning

Attack: Copy the card data and create a counterfeit.

Defense: The cryptographic key is stored in the chip’s secure element and cannot be extracted. Without the key, the attacker cannot generate valid ARQCs for new transactions.

Even if you copy:

• The PAN ✓
• The expiry date ✓
• The track 2 equivalent ✓
• The last-used ARQC ✓

You cannot generate the next valid ARQC because you don’t have the key.

3. Data Tampering

Attack: Intercept the transaction and modify the amount (e.g., €10 → €1000).

Defense: The amount is included in the ARQC computation. Any modification invalidates the cryptogram:

Original:  Amount=€10.00,  ARQC = 3F8B2C... ✅
Tampered:  Amount=€1000,   ARQC = 3F8B2C... ❌ (ARQC doesn't match)

4. Skimming for CNP Fraud

Attack: Skim card data at a terminal and use it for online (card-not-present) purchases.

Defense: EMV doesn’t directly prevent this, but the iCVV (chip-specific CVV) differs from the magnetic stripe CVV. Modern issuers detect when chip card data is used for CNP transactions and apply additional scrutiny or decline.

ARQC vs. Magnetic Stripe CVV

The fundamental difference between EMV and magstripe security:

This is why liability shifted to merchants who don’t support EMV — the technology exists to prevent fraud, and not using it is a choice.

ARPC: The Issuer’s Response

After verifying the ARQC, the issuer generates an ARPC (Authorization Response Cryptogram) to prove the response is genuine:

$$ \text{ARPC} = \text{MAC}_{\text{SK}}(\text{ARQC} \oplus \text{ARC}) $$

Where:

• $\text{ARC}$ = Authorization Response Code (approved/declined)
• $\oplus$ = XOR operation

The card can verify the ARPC to confirm the response actually came from the issuer and wasn’t injected by an attacker.

Cryptogram Verification Failures

When ARQC verification fails, the issuer sees one of these scenarios:

Implementation Notes

If you’re building POS or issuer systems, keep these points in mind:

For Terminal Developers

• Always include the Unpredictable Number (9F37) — 4 random bytes that add entropy
• Transmit all EMV tags required by the issuer in DE 55
• Handle ARPC verification if the card requests it (second GENERATE AC)

For Issuer Processors

• Track ATC per card to detect replays and gaps
• Implement session key derivation matching the card’s method (Common Session Key Derivation or EMV CSK)
• Consider ATC gap thresholds — too strict causes false declines, too loose enables attacks

For Acquirers

• Preserve EMV data integrity — don’t modify DE 55 contents
• Ensure proper TLV encoding when forwarding to the issuer

Summary

The ARQC is the cryptographic heart of EMV security:

1. Unique per transaction — derived from amount, date, random number, and ATC
2. Tied to a specific card — generated using a key only that card possesses
3. Verifiable by the issuer — using the master key hierarchy
4. Non-replayable — the ATC ensures each cryptogram is one-time use

This mechanism is why chip card fraud at the point of sale has dropped dramatically since EMV adoption, and why the payment industry invested billions in the migration from magnetic stripe.

Understanding ARQC is essential for anyone building secure payment systems — it’s the reason EMV works.

Further Reading

• POINT OF SALE ARCHITECTURE — Volume 1 — the primary reference for POS security and EMV implementation
• EMVCo Book 2: Security and Key Management
• EMVCo Book 3: Application Specification (GENERATE AC command)
• ISO 9797-1: MAC Algorithm 1 (3DES CBC-MAC)
• EMV for Developers — companion post on this site
• DUKPT & IPEK Derivation — related key derivation concepts