In EMV chip transactions, the card does not simply return “approved” or “declined” as plain text. It returns an application cryptogram: an 8-byte MAC bound to that transaction’s amount, date, terminal data, and counter state. The terminal and backend then read Cryptogram Information Data (CID, tag 9F27) to learn which kind of cryptogram the card produced, while the MAC itself sits in Application Cryptogram (tag 9F26). ARQC, TC, and AAC: A Field Guide to EMV Application Cryptograms That split trips up a lot of POS integrations. Logs show cryptogram invalid or 9F26 mismatch without saying whether the card asked to go online, approved offline, or declined. Backend teams chase issuer policy when the real issue is a truncated DE 55 or a misread CID. This post is a taxonomy: what each cryptogram type means, who generates it, and where it appears in a normal online EMV flow. For the cryptographic mechanics of ARQC generation, replay resistance, and key hierarchy, see the companion posts on EMV cryptograms and why chip cards resist cloning.

Two tags, one decision

Every GENERATE AC response carries at least three objects: 9F27 (CID), 9F26 (Application Cryptogram), and 9F36 (ATC). The CID is not a second copy of the MAC. It encodes the cryptogram type and optional advice or referral flags. The MAC value in 9F26 is always 8 bytes regardless of type.

Common CID type encodings (bits 8–7 of tag 9F27) map as follows, per EMV Book 3 and practitioner references such as OpenSCDP’s card action analysis tutorial:

ID TECH’s EMV trace guides use the shorthand 80 for ARQC, 40 for TC, and 00 for AAC in hex dumps — the high nibble of the CID byte (Developing for EMV, Part II).

In integration work, the useful distinction is simple: 9F26 is the cryptogram; 9F27 tells you what kind of cryptogram the card produced.

Card-generated cryptograms

The chip generates three primary outcomes through card action analysis, comparing terminal verification results (TVR) against issuer action codes (IACs). The decision hierarchy runs TC (approve) → ARQC (go online) → AAC (decline), with the card able to override a terminal proposal downward. That dual risk model — terminal and card each evaluate independently — is why two devices can disagree on whether a transaction should go online.

ARQC — Authorization Request Cryptogram

The ARQC means the card is asking the issuer to authorize this transaction online. The card produces it when offline approval is not permitted, when terminal or card risk management forces online processing, or when issuer parameters require issuer participation.

The ARQC travels card → terminal → acquirer → scheme → issuer, typically inside ISO 8583 DE 55 as TLV-encoded EMV data. The issuer (or its HSM) reconstructs the session key, recomputes the expected MAC from the transaction inputs, and compares it to tag 9F26. A match supports the conclusion that the chip participated in this specific transaction with the supplied data intact. AWS Payment Cryptography describes ARQC validation in those terms: transaction-unique proof of card validity and data integrity.

Typical inputs bound into the MAC include amount (9F02), currency, terminal country, transaction date (9A), unpredictable number (9F37), ATC (9F36), TVR (95), and other fields defined in CDOL1. The acquirer must forward DE 55 without reshaping it; any modification breaks issuer-side verification.

TC — Transaction Certificate

The TC is the card’s cryptographic approval. It appears in two main situations: offline approval when terminal and card risk parameters allow completion without issuer contact, and final online approval after the issuer responds and the terminal issues a second GENERATE AC.

In classic contact EMV, the sequence is: first GENERATE AC returns ARQC → issuer approves and may return ARPC → terminal sends issuer response to card → second GENERATE AC returns TC. The TC is the card’s signed statement that it accepts the final outcome.

In many modern contactless and online-first profiles, operational acceptance may treat issuer approval as sufficient even when the second GENERATE AC is shortened or scheme-specific. Conceptually, though, TC still means card-approved cryptogram. See online vs offline EMV transactions for how online-first terminal configuration changes how often you see TC in production traces.

AAC — Application Authentication Cryptogram

The AAC is the card’s decline cryptogram. The chip can return it before any online request — for example when card risk management fails or IAC-Denial bits fire — or after online processing when the issuer response is missing, invalid, or not accepted by the card.

TC and AAC are opposites at the card layer: TC means the card signed approval; AAC means the card signed decline. Neither replaces the issuer’s authorization decision on an ARQC path; they finalize what the card will record for the session.

AAR — Application Authorization Referral

AAR is the fourth card-side cryptogram type, and it is uncommon in day-to-day retail POS. CID bits 8 and 7 both set (11) signal that the card wants referral — manual intervention such as voice authorization — rather than a standard online authorization path. EMV Book 3 defines the encoding; OpenSCDP documents it alongside AAC, TC, and ARQC.

Most unattended terminals, SoftPOS profiles, and online-only configurations never surface AAR in production. When they do, terminal behavior is profile-dependent: some implementations map referral to a voice-auth workflow; others decline because no operator is present. Treat AAR as a real EMV outcome you may see in certification traces, not as a fifth everyday integration path beside ARQC.

Issuer-generated cryptogram: ARPC

ARPC — Authorization Response Cryptogram — breaks the pattern. The issuer generates it, not the card.

After validating the ARQC, the issuer makes an authorization decision. On approval, it may compute an ARPC and return it inside Issuer Authentication Data (tag 91). The terminal forwards tag 91 to the card. The card verifies that the response genuinely came from the issuer before accepting scripts or issuing a final TC. IBM’s EMV transaction services documentation describes ARQC/ARPC processing as paired authorization request and response cryptogram operations.

ARPC is not interchangeable with DE 39 (response code). DE 39 tells the terminal whether the issuer approved or declined. ARPC gives the card cryptographic proof about the issuer’s response. A decline may carry no ARPC at all; approvals are where ARPC most often appears.

Reference table

A normal online EMV flow

The sequence below is the contact-chip mental model. Contactless kernels may compress steps, but the cryptogram roles stay the same.

1. Terminal reads the card and runs EMV processing through GPO, READ RECORD, and CVM as required.
2. Terminal and card perform risk management; TVR and TSI are populated.
3. Terminal sends the first GENERATE AC command with its proposed outcome.
4. Card returns ARQC (9F27 = 80) in tag 9F26, plus ATC and related tags.
5. Terminal builds an authorization message; EMV data rides in DE 55.
6. Acquirer forwards to scheme and issuer without altering the TLV blob.
7. Issuer validates ARQC, approves or declines, and may return ARPC in tag 91.
8. Terminal passes issuer authentication data and scripts to the card.
9. Terminal sends a second GENERATE AC; card returns TC (approve) or AAC (decline).

The compact mnemonic: ARQC = card asks the issuer; ARPC = issuer answers the card; TC = card approves; AAC = card declines.

What to watch in POS and backend work

Three failure modes show up repeatedly in traces.

CID misread. Teams treat any 9F26 value as “the ARQC” even when 9F27 shows TC or AAC. That sends the wrong message to the issuer and produces verification failures that look like keying problems.

DE 55 handling. Gateways that reorder TLVs, strip tags, or log raw DE 55 contents break issuer verification and create compliance exposure. Forward the blob; do not parse it for display in production logs.

Second GENERATE AC skipped. Online-only contactless flows sometimes stop after issuer approval. That is often allowed by scheme rules, but certification and dispute evidence may still expect a final TC. Know which profile your terminal certifies against before assuming issuer approval alone is enough.

For broader EMV context — kernels, tag lists, and developer-facing flow — see EMV for developers.

Further reading

• EMVCo, EMV Book 3: Application Specification — GENERATE AC, CID encoding, card action analysis
• EMV tag 9F26 (Application Cryptogram) — EMVLab reference
• EMV tag 9F27 (Cryptogram Information Data) — EMVLab reference
• EMV cryptograms: how ARQC prevents fraud — key hierarchy and MAC computation
• Online vs offline EMV transactions — when ARQC vs TC appears in production configuration