One byte returned with every GENERATE AC. The top two bits say what kind of cryptogram the card produced — decline, approve, or go online — and the bottom bits say whether the issuer should hear about it, and why. Paste the byte, read the verdict.
Bits b8 b7 carry the answer everyone cares about — which cryptogram sits in tag 9F26: 00 AAC, the card declines; 01 TC, the card approves; 10 ARQC, the card wants the issuer to decide. 11 is reserved (early EMV defined an AAR here; it was withdrawn). Bits b6 b5 are reserved and should be zero. Bit b4 asks the terminal to send an advice message to the issuer, and b3–b1 are the reason: 0 no information, 1 service not allowed, 2 PIN try limit exceeded, 3 issuer authentication failed.
At the first GENERATE AC the terminal asks for what its action analysis concluded — TC, ARQC or AAC. The card may downgrade the request (asked for a TC, returns an ARQC or AAC) but never upgrade it: a card cannot approve what the terminal wanted checked online. On online transactions there is a second GENERATE AC after the issuer's response, and its CID is the final word — TC or AAC.
The CID always labels the cryptogram it travelled with: 9F27 and 9F26 are a pair, and in DE55 you should find both. A cryptogram without its CID is unverifiable data.
A TC in the clearing record is the card's signed approval — offline, or after an issuer OK. An AAC with reason 2 says the card itself declined for PIN try limit: the transaction may never have reached the issuer host, so don't search the authorisation logs for it. An AAC with the advice bit set means the card wants the issuer informed even though nothing went online — terminals that drop advices silently lose that trail. And an ARQC in a record that never got an online answer is a transaction that died in transit, not a decline.