9F26; tag 9F27 (the Cryptogram Information Data, CID) tells you which of the three you are looking at โ and it is the field that explains the single most confusing decline in EMV: the issuer said yes, and the transaction still failed.
An application cryptogram is a MAC the card computes over the transaction data with a key only the card and the issuer share. It proves a real card was present and that the amounts were not altered. What varies is the decision the cryptogram carries:
| Type | Name | Meaning |
|---|---|---|
ARQC | Authorisation Request Cryptogram | The card cannot decide alone โ send this online and let the issuer verify it |
TC | Transaction Certificate | Approved โ either offline, or after the issuer said yes. This is the value that lands in clearing |
AAC | Application Authentication Cryptogram | Declined by the card itself |
Note who the actor is. A DE39 decline is the issuer saying no; an AAC is the card saying no. They can disagree โ that is the whole second half of this article.
CID is one byte. The two high bits carry the cryptogram type, which is why the three values you meet everywhere are 80, 40 and 00:
| Bits | Meaning |
|---|---|
b8 b7 | Cryptogram type: 00 = AAC ยท 01 = TC ยท 10 = ARQC ยท 11 = RFU (the early-EMV AAR, since withdrawn) |
b6 b5 | RFU โ should be zero |
b4 | Advice required โ the card wants the issuer told even though nothing went online |
b3โb1 | Advice / reason code, read as a number: 0 = no information, 1 = service not allowed, 2 = PIN try limit exceeded, 3 = issuer authentication failed |
So 80 is 1000 0000 โ b8 b7 = 10, an ARQC with nothing else set. 40 is 0100 0000 โ a TC, a plain approval. 00 is an AAC. The low bits matter on declines: 0B is 0000 1011 โ an AAC, advice required, reason 3, "issuer authentication failed". A card that declines a purely offline transaction can use the advice bit to make sure the issuer still hears about it.
The terminal asks the card for a cryptogram with the GENERATE AC command, naming the type it would like. The card may return that type or a more cautious one โ asked for a TC, it can answer with an ARQC (go online first) or an AAC (no); asked for an ARQC, it can still answer AAC. The card always has the last word downwards, never upwards.
In an online transaction the command runs twice. The first GENERATE AC produces the ARQC that rides to the issuer inside DE55. When the response comes back, the terminal issues a second GENERATE AC, handing the card the issuer's answer โ including the ARPC, the issuer's own cryptogram, carried in tag 91 (look up any tag you meet along the way in the EMV tag lookup). The card verifies the ARPC and only then signs the final verdict: TC if it accepts, AAC if it does not.
Read the first exchange with real values: the card answers the first GENERATE AC with 9F27 = 80 โ drop it into the CID decoder and it reads back "ARQC โ online authorisation requested". Nothing is approved or declined yet; the card has merely asked for the issuer's opinion.
Here is the trap. You pull the authorisation log, find the 0110 response with DE39 = 00, and conclude the transaction was approved. The cardholder swears it failed at the till. Both are right.
DE39 = 00 records the issuer host's decision. But the transaction is not finished: the second GENERATE AC still has to run, and at that step the card checks the issuer authentication data it was handed. If the ARPC does not verify โ wrong key version, a host or HSM deriving the ARPC incorrectly, the response mangled in transit, a proxy that stripped or truncated tag 91 โ the card treats the "approval" as unproven. Depending on its issuer-set rules it returns an AAC, and the terminal declines a transaction the issuer approved seconds earlier.
The evidence pattern is unmistakable once you know it:
00, a normal approval.00 โ the CID decoder reads it as "AAC โ transaction declined by the card".Who to chase depends on where the ARPC broke. If every card of one profile fails, suspect the issuer's key setup or a recent HSM change. If one acquirer path fails, suspect whatever sits between the issuer and the terminal editing DE55. The card is almost never the culprit โ it is the messenger reporting that the maths did not add up.
When a chip transaction outcome makes no sense, read the cryptogram trail before anything else:
40 means it approved offline and no authorisation ever existed; stop searching the auth logs.40 TC = done; 00 AAC = the card overrode everything above.00 AAC, 01 TC, 10 ARQC. One transaction can contain two verdicts, one per GENERATE AC. DE39 is the issuer's vote; the final 9F27 is the result. When they disagree, the card's word stands.