An EMV application cryptogram is a one-time code that a chip card generates for every transaction to prove the card is authentic and that the transaction data has not been tampered with. The most consequential form of it, the Authorization Request Cryptogram (ARQC), is sent to the card’s issuing bank for real-time verification. Because the code is built from inputs that change with every purchase, data captured from one transaction is worthless for the next. The entire exchange, from the chip producing the code to the bank returning its decision, happens in under a second.
Why the Code Changes Every Time
Magnetic stripe cards transmitted the same data on every swipe. Someone who captured that data once, through a skimmer at a gas pump for example, could write it onto a blank card and use it indefinitely. The card had no way to prove it was the original rather than a copy, because what it transmitted never changed.
EMV chip cards close that gap by producing a fresh cryptographic code for each transaction. Even if someone intercepts the full data stream from a chip transaction, the cryptogram inside it was built using a counter that has already incremented and a random number that will never repeat. The issuing bank rejects any attempt to replay it. That is the underlying shift: the card stopped being a passive data carrier and became an active computing device that participates in its own authentication.
The card networks pushed adoption through liability shift policies. Before the shift, banks generally absorbed counterfeit fraud losses. After it, if a merchant’s terminal wasn’t chip-enabled and a counterfeit chip card was used, the merchant bore the cost. That financial incentive moved most U.S. retailers to upgrade their terminals within a few years.
The Three Cryptograms a Chip Can Produce
When the terminal issues the GENERATE AC command, the chip does not always return an ARQC. Depending on the card’s internal risk management and the terminal’s configuration, it produces one of three cryptogram types, each signaling a different decision about how to handle the transaction.1CardContact. Card Action Analysis
- Transaction Certificate (TC). The card approves the transaction offline, without contacting the bank. This happens for low-risk transactions that fall within the card’s pre-set limits for offline authorization.
- Authorization Request Cryptogram (ARQC). The card wants the issuing bank to make the final call. This is the most common outcome in markets like the U.S., where most terminals are configured to go online for every purchase.
- Application Authentication Cryptogram (AAC). The card declines outright. The chip’s own risk checks flagged something, perhaps the offline transaction count exceeded a threshold or the cumulative offline spending limit was reached.
The card communicates which type it produced through the Cryptogram Information Data field, encoding the decision in the two most significant bits of the response. The terminal reads that field to determine its next step: route the ARQC online, accept the TC, or display a decline.
What Goes Into the Calculation
Before the chip can produce a cryptogram, the terminal and card have to assemble a specific set of data elements that describe the transaction. The card tells the terminal which elements it needs through a Card Data Object List stored on the chip. The terminal supplies its items, the card contributes its own, and together they form the raw input for the cryptographic operation.
The terminal contributes:
- Amount Authorized (Tag 9F02), the transaction amount in a fixed 12-digit numeric format.2EMVLab. EMV Tag 9F02 – Amount, Authorised (Numeric)
- Unpredictable Number (Tag 9F37), a random value generated fresh for each transaction, providing the variability that keeps two identical purchases from producing the same cryptogram.3EMVLab. EMV Tag 9F37 – Unpredictable Number
- Terminal Country Code (Tag 9F1A), identifying where the transaction is taking place.4Payment Card Tools. EMV Tags
- Transaction Currency Code (Tag 5F2A), identifying the currency in use under the ISO 4217 standard.5EMVLab. EMV Tag 5F2A – Transaction Currency Code
The card contributes the Application Transaction Counter (Tag 9F36), which works like an odometer. It increments by one with every contact or contactless transaction and never resets.6Mastercard. Update Application Transaction Counter The ATC does double duty. It feeds into the cryptogram calculation, and the issuing bank watches it for gaps or anomalies. If a card’s ATC suddenly jumps by hundreds, the bank knows something is wrong. The card also contributes its internal risk management results in the Issuer Application Data (Tag 9F10), which tells the bank what security checks the card performed and whether any failed.
How the Chip Produces the ARQC
Once the inputs are assembled, the cryptographic work happens inside the chip. The card holds a secret Application Cryptogram Master Key that was loaded during manufacturing and never leaves the chip’s secure hardware. That master key is the root of trust for every transaction the card will ever perform.
For most implementations, the chip derives a temporary session key from the master key using the Application Transaction Counter as an input. Because the ATC changes every time, each session key is unique and short-lived. The derivation method varies by network. Mastercard’s M/Chip and Visa’s newer cryptogram versions use different approaches, but they share the principle that the session key is mathematically tied to a single transaction and cannot be reused.7IBM. Derive Session Key (CSNBDSK and CSNEDSK)
The chip then runs a Message Authentication Code algorithm over the assembled transaction data using the session key. The algorithm is typically Triple DES, though the industry is migrating toward AES for stronger security and better performance.8EMVCo. How EMVCo is Supporting Card Data Encryption Advancements for Card Personalisation The output is an eight-byte value stored as the Application Cryptogram in Tag 9F26.9EMVLab. EMV Tag 9F26 – Application Cryptogram That value binds three things into a single proof: the card’s identity through the master key, the specific transaction details through the amount, currency, and country, and the anti-replay protections through the ATC and unpredictable number. None of it can be forged without the secret key.
How the Bank Verifies and Responds
The ARQC, along with the transaction data and the ATC, travels through the payment network to the issuing bank’s authorization system. Verification happens inside a Hardware Security Module, a tamper-resistant server designed to handle cryptographic operations without exposing secret keys, even to the bank’s own staff.
The HSM stores the card’s master key, or more precisely a master derivation key from which each card’s unique key can be regenerated. It pulls the ATC from the authorization message, derives the same session key the chip used, runs the same MAC calculation over the same transaction data, and produces its own eight-byte result. If that value matches the ARQC sent by the terminal, two things are proven at once: the card is genuine, because only a card with the correct master key could produce the right output, and the transaction data was not altered in transit, because any change to the input would produce a completely different cryptogram.
A mismatch triggers an automatic decline. The math either works or it doesn’t. Legitimate mismatches usually trace back to corrupted data during transmission, a malfunctioning chip, or a desynchronized ATC, which can happen when a card attempts many transactions that never complete.
The bank doesn’t stop at “approved” or “declined.” It generates its own cryptographic proof, an Authorization Response Cryptogram (ARPC), so the card can verify the response actually came from the legitimate issuer rather than from someone intercepting the communication. The ARPC is delivered inside Tag 91, Issuer Authentication Data, which the terminal passes to the chip.10EFTLab. Complete List of EMV and NFC Tags The card verifies the ARPC using its session key. If verification succeeds and the bank approved, the card generates a TC as a final record. If verification fails or the bank declined, the card generates an AAC to close the session.
The response can also carry issuer scripts, commands the bank wants executed on the chip. Banks use these to update PIN retry counters, change cryptographic keys, unblock a PIN that was locked after too many failed attempts, or permanently block a card flagged for fraud. The card authenticates these commands cryptographically before executing them, so a compromised terminal cannot inject fake management instructions.
Contactless Taps and Mobile Wallets
Contactless tap-to-pay and mobile wallets use the same cryptogram architecture as contact chip transactions, with differences in how they execute. When you tap a physical contactless card, the chip generates an ARQC through essentially the same process of master key, session key derivation, and MAC over transaction data, just communicated by NFC radio instead of the chip’s contact pads. The ATC increments the same way regardless of interface.
Mobile wallets like Apple Pay add a tokenization layer on top. Your phone does not store your actual card number. Instead, the card network issues a Device Primary Account Number, a token that maps to your real account but is useless if stolen without the device’s secure hardware. When you authenticate with your fingerprint or face and hold your phone to the terminal, the device generates a payment cryptogram using keys tied to that token. The card network validates the cryptogram, de-tokenizes the DPAN back to your real card number, and sends the transaction to your bank for authorization. The bank sees a normal-looking authorization request even though the merchant never touched your actual card number.
A field called the Payment Account Reference (Tag 9F24) ties everything together in the background. The PAR is a 29-character identifier that links a card’s real account number to all of its associated tokens across different devices and wallets, letting banks and merchants reconcile transactions without needing to see the underlying card number.11U.S. Payments Forum. Role of the Payment Account Reference (PAR) within the Payments Lifecycle
When No Cryptogram Is Generated: Fallback Transactions
Sometimes the chip reader fails. The card is inserted, the terminal can’t communicate with the chip, and the system falls back to reading the magnetic stripe instead. This is called a technical fallback, and it is one of the weakest points in the EMV ecosystem because it bypasses the entire cryptogram framework. No ARQC is generated, no dynamic data protects the transaction, and the payment reverts to the static data model that chip technology was designed to replace.
Card networks scrutinize fallback transactions closely. Under Visa’s rules, the liability allocation depends on whether the merchant properly identified the transaction as a fallback in the authorization message. If a chip card is used at a non-chip terminal and fraud occurs, the merchant’s acquiring bank generally bears the loss. If the terminal correctly flags the fallback and follows proper acceptance procedures, liability may shift to the issuer.12Visa. Interlink Core Rules and Interlink Product and Service Rules Merchants with recurring fallback problems often get flagged by their payment processor, because frequent fallbacks can signal a compromised terminal or an attempted attack.
Why the Cryptogram Cannot Come Back to Haunt You
A common misconception is that transaction cryptograms sit in terminal logs as a permanent record. In reality, PCI DSS rules explicitly prohibit storing sensitive authentication data after a transaction is authorized, and that includes the data from the chip interaction. Terminals and merchants must not retain this data even in encrypted form.13PCI Security Standards Council. PCI Data Storage Dos and Donts Card verification codes, whether static or dynamic, fall squarely under this prohibition.14PCI Security Standards Council. Frequently Asked Question
Merchants can keep certain non-sensitive elements for record-keeping, including truncated card numbers, authorization codes, and transaction amounts. The cryptographic material that proves card authenticity is designed to be ephemeral. It serves its purpose during the authorization exchange and then must be purged. A merchant who stores this data, even with the cardholder’s consent, violates PCI DSS requirements and faces potential fines and increased liability for any resulting breach.
For you as a cardholder, the practical result is straightforward. Even if a merchant’s system is compromised after your chip transaction, the captured cryptogram data cannot be used to build a counterfeit card or replay the purchase. The dynamic nature of the ARQC means the stolen data is already expired the moment the transaction completes. That is the core security advantage that makes EMV chip technology fundamentally more resistant to fraud than magnetic stripes ever were.