ARQC from Scratch: Application Cryptograms Without the Black Box

💡 TL;DR (Too Long; Didn't Read)

The cryptogram in 90 seconds:

• The ARQC (Authorisation Request Cryptogram) is a MAC over the transaction, generated by the card, that only the issuer can verify. It is what makes a chip transaction unforgeable and unreplayable.
• Building one is a chain: Issuer Master Key → ICC Master Key (diversified by PAN + sequence number) → Session Key (diversified by the ATC) → MAC over the transaction data.
• The MAC is ISO/IEC 9797-1 Algorithm 3 (Retail MAC) for the DES-era cryptogram versions, or AES-CMAC for the modern ones. The CVN in the Issuer Application Data tells you which.
• The issuer replies with an ARPC, a response cryptogram derived from the ARQC, so the card can verify the issuer too.
• The rule that makes this shippable: key-bearing crypto runs client-side (WebCrypto/WASM) or on-prem. You never send a production key to someone else's server — including ours. The deterministic tool, checked against published test vectors, is the source of truth; AI never is.

Every part of this series so far has been building toward this one object. In Part 1 the card ended the transaction by returning an Application Cryptogram in tag 9F26. In Part 3 the terminal's decision logic decided which cryptogram to request. Now we open the cryptogram itself. The ARQC — the online-authorization variant of the Application Cryptogram — is the single mechanism that makes EMV worth the enormous cost of deploying it: a value that proves this specific transaction was authorized by this specific card, that cannot be replayed, and that only the card's issuer can validate. Understand how it is built and you understand why chip beat magstripe.

I am going to build one from the ground up, and I am going to do it honestly, which means two disciplines you should hold me to. First, I will not print a specific 8-byte "this is the correct ARQC" hex value, because a fabricated cryptographic output is worse than useless — it is a landmine for anyone who copies it. The real intermediate and final values come from the test vectors in EMVCo Book 2 and are reproduced by a deterministic implementation you can check. I will show the process with clearly-labelled illustrative inputs and tell you exactly where the authoritative vectors live. Second, every step here that touches a key is a step that must run where the key already lives — the cardholder's card, the issuer's HSM, or, for learning, a browser tab with test keys that never leave it. That is not a compliance footnote; it is the architecture.

The problem the ARQC solves

A magstripe transaction sends static data: the PAN, the expiry, the service code, all copied straight off the track. Capture it once and you can replay it forever. That is the entire magstripe fraud economy in one sentence. EMV's answer is to make every transaction carry a dynamic value bound to that transaction's details and to a counter, computed under a secret the card holds and never reveals.

That value is a Message Authentication Code — a keyed checksum. The card computes a MAC over the transaction data using a key derived from a secret it shares (indirectly) with its issuer. The issuer, holding the parent secret, can re-derive the same key and re-compute the same MAC to verify it. An attacker who captures the ARQC learns nothing reusable: change any input — the amount, the counter — and the MAC changes completely; and without the key they cannot forge a MAC for a transaction that did not happen. The counter, the Application Transaction Counter (ATC), increments every transaction, so even an identical-looking purchase produces a different cryptogram. Replay is dead.

The elegance is in the key hierarchy that lets one issuer secret protect billions of transactions across millions of cards without ever putting that secret on a card.

Step 1 — From Issuer Master Key to ICC Master Key

At the top sits the Issuer Master Key for Application Cryptograms (IMK-AC) — a double-length key held in the issuer's HSM and, by policy, nowhere else. You do not put the IMK on a card; if you did, extracting one card would compromise every card. Instead each card gets a diversified key, unique to it, derived from the IMK using data that identifies the card.

The derivation (EMV Book 2, Annex A1.4, "Option A") diversifies by the PAN and PAN Sequence Number:

Illustrative inputs (NOT a real key — for shape only):
  IMK-AC (double-length 3DES key) : held in HSM
  PAN                              : 4761 7300 0000 0119
  PAN Sequence Number (PSN)        : 00

  X  = rightmost 16 digits of (PAN || PSN), zero-padded on the left → 8 bytes
  ZL = 3DES_encrypt(IMK-AC, X)
  ZR = 3DES_encrypt(IMK-AC, X XOR 0xFFFFFFFFFFFFFFFF)
  MK-AC = adjust_parity( ZL || ZR )     // the card's unique 16-byte ICC master key

Two details matter and both are common bugs. The input X is the rightmost sixteen digits of the PAN concatenated with the sequence number — for a 16-digit PAN with a one-byte PSN you drop the leftmost digits, and for shorter PANs you left-pad with zeros. And the final key gets odd-parity adjusted per DES convention; skip the parity adjustment and you will derive a key that is "almost right," which in cryptography means entirely wrong. The result, MK-AC, is the master key for this card — still never used directly for a transaction.

Step 2 — From ICC Master Key to Session Key

Deriving one key per card is not enough, because a per-card key reused across every transaction would let an attacker collect many MACs under the same key. So EMV diversifies again, per transaction, using the ATC. This is the Session Key derivation, and the common method (EMV Book 2, Annex A1.3, "Common Session Key") looks like this:

Illustrative (shape only):
  MK-AC : the card's master key from Step 1
  ATC   : 0x0005   (this is the 5th transaction on this card)

  F_L = ATC || 0xF0 || 0x00 0x00 0x00 0x00 0x00      // 8-byte block
  F_R = ATC || 0x0F || 0x00 0x00 0x00 0x00 0x00      // 8-byte block
  SK_L = 3DES_encrypt(MK-AC, F_L)
  SK_R = 3DES_encrypt(MK-AC, F_R)
  SK-AC = adjust_parity( SK_L || SK_R )              // per-transaction session key

The ATC threads through the whole design: it makes the session key unique per transaction, it appears in the MAC input, and it lets the issuer detect cloned cards by watching for counters that go backward or duplicate. One two-byte counter, doing three jobs.

Now — and this is where discipline matters — the exact derivation depends on the scheme and the cryptogram version. The block above is the common method; Visa's older CVNs use a different session-key scheme (some effectively use the master key directly with the ATC folded into the MAC data). Which one applies is not something you guess.

Step 3 — The Cryptogram Version Number decides everything

The Issuer Application Data (tag 9F10) returned with the cryptogram contains a Cryptogram Version Number (CVN). The CVN is the single most important byte for anyone trying to validate an ARQC, because it selects the entire recipe: which session-key derivation runs, exactly which data elements go into the MAC and in what order, whether padding is applied, and which MAC algorithm is used. A validator that assumes one CVN and receives another will compute a perfectly-formed, completely-wrong cryptogram.

This is why "implement ARQC" is not a single algorithm but a family of them keyed by CVN, and why the correctness burden is real. You cannot eyeball a CVN mismatch; you catch it by running your implementation against the published test vectors for that CVN and confirming a byte-exact match.

Step 4 — Computing the MAC

With the session key derived and the CVN telling you what to feed it, the ARQC is a MAC over the transaction data. For the DES-family cryptogram versions the algorithm is ISO/IEC 9797-1 MAC Algorithm 3 — the "Retail MAC":

Data = concatenation, in CDOL1 order, of the required elements, typically:
  Amount Authorised, Amount Other, Terminal Country Code,
  Terminal Verification Results (the tag 95 from Part 3!),
  Transaction Currency Code, Transaction Date, Transaction Type,
  Unpredictable Number, AIP, ATC, and CVN-specific extras (e.g. IAD/CVR)

1. Pad Data with 0x80 then 0x00... to a multiple of 8 bytes (ISO 9797-1 padding method 2)
2. CBC-MAC all blocks with single-DES using the LEFT half of SK-AC
3. On the final block, apply the 3DES transform:
     decrypt with the RIGHT half, then encrypt again with the LEFT half
4. ARQC = the resulting 8-byte block (leftmost 8 bytes)

Look at what goes into that MAC: the amount, the currency, the country, the date, the type, a random Unpredictable Number, the AIP, the ATC — and the TVR from Part 3. The cryptogram cryptographically binds the terminal's own verification results into the assertion. Tamper with the amount after the fact and the MAC breaks. Replay yesterday's cryptogram and the ATC and Unpredictable Number no longer match. That is the anti-fraud property, and it is nothing more exotic than a MAC over the right inputs.

The modern cryptogram versions replace the DES Retail MAC with AES-CMAC over analogous data, following the same principle with a stronger primitive. The migration from 3DES to AES cryptograms is one of the quiet, multi-year re-platformings happening across the issuing world right now; if you are building new, you build for AES CVNs.

Step 5 — The ARPC: the issuer answers

Authentication in EMV is mutual. After the issuer validates the ARQC, it computes an ARPC (Authorisation Response Cryptogram) so the card can verify the issuer — this is how the card knows the "approved" it hears actually came from its issuer and not from a man in the middle. The classic derivation (Method 1) is compact:

Illustrative (shape only):
  ARC = Authorisation Response Code (2 bytes, e.g. "00" = approved)
  ARPC = 3DES_encrypt( SK-AC,  ARQC XOR (ARC || 0x00 0x00 0x00 0x00 0x00 0x00) )

The issuer sends the ARPC and the ARC back down; the terminal passes them to the card in the second GENERATE AC; the card recomputes and compares. If it matches, issuer authentication succeeded — and if it does not, the card sets the issuer-authentication-failed bit in TVR byte 5, exactly the bit we met in Part 3. The newer cryptogram versions use a CMAC-based ARPC (Method 2) over the ARQC plus a Card Status Update, but the intent is unchanged: prove the response is genuine.

The rule that makes this safe to ship

Now the architecture, because everything above is only responsible if it runs in the right place.

Key-bearing cryptography runs where the key already is. A real ARQC is computed on the card, under a key that never leaves it. A real validation runs in the issuer's HSM, under the IMK that never leaves it. When gsstk builds an ARQC Calculator as a tool, it runs the computation client-side — in your browser via WebCrypto/WASM — with test keys you supply that never traverse the network. We do not have a "send us your IMK" endpoint. We never will. In a domain where trust is the entire product, a payments tool that asks for a production key on a remote server is not a tool, it is an incident waiting for a subpoena. This is written into our EMV rules as policy, not preference.

And the AI layer sits on top of the deterministic computation, never underneath it. A language model can explain a CVN, narrate a flow, or spot that your ATC looks stale — but it is never the thing that computes a cryptogram, because a plausible-looking wrong MAC is the most dangerous output in this field. The deterministic implementation, validated byte-for-byte against Book 2's test vectors, is the source of truth. That is the same principle that closed Part 2 (the tested decoder over the clever loop) and it is the spine of the whole product: correctness you can reproduce, not correctness you hope for.

Where this leaves you

You can now trace a cryptogram from an issuer secret to a verifiable assertion and back to mutual authentication, without any part of it being magic. That is the hardest concept in card-present payments, and everything the schemes are building for the agentic era — the mandates and scoped tokens from the bridge piece earlier in this series — is a variation on this exact pattern: a signed, counter-protected, key-derived assertion that a specific action was authorized.

The regional finale takes all of this rigor somewhere unexpected: the QR code that all of Brazil uses. PIX and the EMVCo Merchant-Presented Mode are the same discipline — structured, checksummed, spec-defined payment data — in a form you can print on a napkin. When gsstk ships the ARQC Calculator, it will do the computation above in your browser, with your test vectors, so you can watch each intermediate value resolve and check it against Book 2 yourself.

Related Reading on gsstk

• The TVR, the TSI, and How a Terminal Decides to Decline You — Part 3: the TVR that gets bound into this MAC.
• What Actually Happens When You Dip a Chip: The EMV Transaction Flow End-to-End — Part 1: where 9F26 and GENERATE AC live.
• Agentic Commerce and the Return of HTTP 402 — the mandate/token = "a cryptogram for delegation" analogy.
• PIX, BR Code, and the EMVCo MPM — Part 5: the same discipline as a QR code.

Tools: inspect the cryptogram tags in the EMV Tag Dictionary — 9F26 (AC), 9F10 (IAD), 9F36 (ATC) — and the Public Key Table for the CA keys behind offline data authentication. (A client-side ARQC/ARPC Calculator is on the roadmap.)

Filed under: EMV · Payment Crypto · Payments · Acquiring · Card Issuing

This article was human-architected and synthesized with AI assistance under the Daedalus (AI) persona.