What Is an ARQC? The EMV Online Cryptogram Explained

When a chip card transaction goes online, the card proves it is genuine by sending the issuer a cryptogram called the ARQC, the Authorisation Request Cryptogram. It is 8 bytes long, it travels in tag 9F26, and it is the single most important value in an EMV authorisation.

Where the ARQC comes from

Near the end of the transaction, the terminal sends the card a GENERATE AC command. The command asks for one of three cryptogram types:

• TC (Transaction Certificate): approve offline.
• ARQC: go online to the issuer.
• AAC (Application Authentication Cryptogram): decline.

The card runs its own risk checks and answers with a cryptogram of the requested type or a more cautious one. It can turn a TC request into an ARQC or an AAC, but never the other way round. The Cryptogram Information Data, tag 9F27, tells you which one came back: bits 8 and 7 equal to 10 mean ARQC, so a value of 80 is the usual online case.

What goes into it

The ARQC is a MAC calculated by the card over transaction data and card data:

• Terminal data, sent in the GENERATE AC command as listed by CDOL1 (8C): typically the amount, other amount, terminal country, TVR, currency, date, transaction type and the terminal's unpredictable number.
• Card data: usually the AIP (82), the Application Transaction Counter (9F36) and part of the Issuer Application Data (9F10).

The unpredictable number and the ATC change on every transaction, so the same card never produces the same ARQC twice. That is what defeats replay and cloning.

Which key signs it

Each card holds a unique key, derived from the issuer's master key and the card's PAN and PAN Sequence Number. For each transaction, the card derives a session key from that card key and the ATC, then computes the MAC with it. Older cards use Triple DES with an ISO 9797-1 retail MAC; newer ones may use AES. The exact method is set by the cryptogram version, which the issuer encodes in the Issuer Application Data.

How the issuer checks it

1. The acquirer forwards the chip data to the issuer in ISO 8583 field 55.
2. The issuer's HSM derives the same card key and session key, rebuilds the input data from field 55 and recomputes the MAC.
3. If the values match, the card is genuine and the data was not altered in transit.
4. The issuer returns an ARPC, the Authorisation Response Cryptogram, in Issuer Authentication Data (91), so the card can check the response came from its real issuer.

Why ARQC validation fails

• Data mismatch. The terminal sent the card one value but put a different one in field 55, for example a different amount or unpredictable number. Compare CDOL1 with the field 55 tags.
• Wrong PAN Sequence Number. A missing or wrong 5F34 changes the derived card key.
• Wrong key or derivation method. Test cards use test keys; check the cryptogram version in 9F10.
• Padding or ordering. The MAC input must be concatenated in exactly the CDOL1 order and padded as the cryptogram version requires.

ARQC, ARPC, TC and AAC at a glance

An example of the input data

Take a CDOL1 that asks for these terminal data objects, a common pattern:

9F02 06  Amount, Authorised   000000002500
9F03 06  Amount, Other        000000000000
9F1A 02  Terminal Country     0124
95   05  TVR                  0000008000
5F2A 02  Currency             0124
9A   03  Transaction Date     261111
9C   01  Transaction Type     00
9F37 04  Unpredictable Number 5F3C1A2B

The terminal sends only the values, concatenated in that order:

000000002500 000000000000 0124 0000008000 0124 261111 00 5F3C1A2B

The card appends its own data, typically the AIP and ATC and, depending on the cryptogram version, part of the Issuer Application Data. It pads the result and computes the MAC with its session key. The issuer must rebuild exactly the same string from field 55, so a single wrong byte, such as a TVR that changed between the card and the host, makes the check fail.

Cryptogram versions

Each payment scheme defines several cryptogram versions. A version fixes which data goes into the MAC, how the session key is derived, which algorithm is used and how the ARPC is built. The card indicates its version in the Issuer Application Data, so an issuer host reads 9F10 first to know how to validate the ARQC. When you test, make sure your HSM or simulator is set to the same version as the test card.

Testing tips

• Log the raw CDOL1 data the terminal sent in GENERATE AC, not just the field 55 tags. Comparing the two finds most mismatches in minutes.
• Check that the unpredictable number in field 55 is the one sent to the card. Some integrations generate a second random number by mistake.
• Use the scheme's test keys and test cards, and never production keys outside an HSM.
• Watch the ATC. Issuers reject cryptograms with an ATC lower than one they have already seen, which looks like a replay.

Frequently asked questions

Can the terminal check the ARQC?

No. Only the issuer, or a processor acting for it, holds the keys to recompute the ARQC. The terminal forwards it without checking it.

Is the ARQC the same as a CVV?

No. A CVV is a static code that is the same on every transaction. The ARQC changes every time, because it depends on the ATC, the unpredictable number and the transaction data.

What happens if the ARPC check fails?

The card sets issuer authentication failed in its own records and the terminal sets byte 5 bit 7 of the TVR. Depending on the card's settings, it may then decline the transaction in the second GENERATE AC even after an online approval.