Why an EMV Contact Transaction Was Declined: AAC, TVR and Action Analysis

contact@corebaseit.com (Vincent Bevia) — Tue, 28 Jul 2026 15:00:00 +0200

An EMV contact decline is not a single error. It is the outcome of decisions made by the terminal, the card, or the issuer at different stages of the transaction. Treating “declined” as one failure class usually sends debugging into the wrong subsystem.

This post is a contact-chip troubleshooting path. It starts from the two values that fix most misdiagnoses, then walks Terminal Action Analysis, second-GENERATE AC completion, Offline Data Authentication (ODA) side effects, and a common Application Usage Control trap. The same decision model is covered in depth in POINT OF SALE ARCHITECTURE: A Practical Guide to Secure, Certifiable POS Systems (the book), Chapter 3: EMV Principles, which frames EMV risk as a dual-layer control between terminal and card.

Start with the cryptogram

The fastest diagnostic opening is:

What cryptogram did the terminal request?
What cryptogram did the card return?

During the first or second GENERATE AC command, the terminal requests one of three outcomes:

Cryptogram	Meaning
ARQC	Go online for issuer authorization
TC	Approve offline
AAC	Decline offline

The returned type is carried in Cryptogram Information Data (CID, tag 9F27). The card may return a more restrictive result than the terminal requested. The terminal can request an ARQC while the card returns an AAC. That distinction decides where you look next:

If the terminal requested AAC, investigate why Terminal Action Analysis selected a decline.
If the terminal requested ARQC or TC but the card returned AAC, Card Action Analysis (or issuer-influenced completion) made the decline decision. Terminal logs may narrow the cause, but they often do not expose the card’s internal risk-management reason.

For the broader online versus offline decision path, see Online vs Offline EMV Transactions. For how ARQC binds transaction data, see EMV Cryptograms: How ARQC Prevents Fraud.

Open the image below for the full diagnostic path (or click to view full size).

If the terminal requested AAC at the first GENERATE AC

For an online-capable terminal, compare the Terminal Verification Results (TVR, tag 95) with:

Terminal Action Code — Denial (TAC-Denial)
Issuer Action Code — Denial (IAC-Denial)

A bit set in both the TVR and the applicable Denial action code identifies a condition that can drive the terminal to request AAC. EMV Book 3 Terminal Action Analysis evaluates Denial before Online; Default applies when the terminal cannot complete the online path.

For an offline-only terminal, perform the same Denial comparison first. If no Denial condition matches, compare the TVR with Terminal and Issuer Action Codes — Default. Default action codes apply when a transaction cannot be completed online.

The useful debugging operation is a bitwise comparison, not a visual comparison of whole hexadecimal strings:

denial_match = TVR AND (TAC-Denial OR IAC-Denial)
default_match = TVR AND (TAC-Default OR IAC-Default)

Decode every matching bit against EMV Book 3 Annex C (TVR bit definitions) and the TAC values actually loaded for the selected AID. IAC values come from the card application for that AID. Do not reuse TAC packs from another kernel, region, or scheme profile without checking what was certified for this terminal configuration.

If the terminal requested AAC at the second GENERATE AC

Check the online path first:

Issuer declined: confirm the authorization response and the host decision.
Unable to go online: compare the TVR with TAC-Default and IAC-Default.

Before the second GENERATE AC, verify that the payment application supplied the correct issuer data to the kernel. Elements that matter for completion include:

Authorization Response Code, tag 8A
Authorization Code, tag 89, when present
Issuer Authentication Data, tag 91, when present
Issuer Script Templates, tags 71 and 72, when present

Malformed issuer authentication data, an incorrect response code, or invalid issuer scripts can cause the card to return AAC during completion. In the dual-layer model from Chapter 3, the second GENERATE AC embeds the issuer-influenced outcome into EMV state: TC for final approval, AAC for final decline.

This completion path is also where teams confuse true offline EMV approval with deferred host authorization. Those are different mechanisms; see Offline EMV vs Store-and-Forward.

Do not misdiagnose an ODA failure

A missing Certification Authority Public Key (CAPK) does not automatically mean that the kernel must decline. It causes Offline Data Authentication (ODA) to fail and sets the corresponding TVR condition. Terminal Action Analysis then determines the requested cryptogram by comparing the TVR with the applicable TAC and IAC values.

Missing CAPK → ODA failure → TVR bit set → action analysis → AAC, ARQC or TC

The configured action codes decide whether that failure becomes an offline decline, an online request, or another permitted outcome. Chapter 3 makes the same architectural point: CAPKs are trust anchors in the terminal; missing or stale keys break certificate recovery, but the decline decision still flows through action analysis rather than a hard-coded “no CAPK ⇒ AAC” rule.

Watch for “requested service not allowed”

TVR byte 2, bit 5 indicates that the requested service is not allowed for the card product. One input to that processing-restrictions check is Application Usage Control (AUC, tag 9F07).

A recurring integration failure mode is to populate cashback amount fields—tags 9F03 or 9F04—for a transaction that has no cashback. In several kernels I have worked with, the presence of either element is treated as a cashback request even when its value is zero. If the AUC does not permit cashback, the kernel may set “requested service not allowed,” Terminal Action Analysis may request AAC, and the field looks like a mysterious decline rather than a data-object mistake.

Interpretation note: EMV Book 3 defines the TVR bit and AUC-driven service checks; whether a zero-value 9F03/9F04 counts as “cashback present” is kernel- and configuration-dependent. Confirm against your scheme and kernel specification. If the transaction is not cashback, omit the cashback amount elements unless those specs explicitly require them.

A compact decline checklist

Capture both GENERATE AC command-response pairs.
Record the cryptogram requested by the terminal and returned by the card (CID, tag 9F27).
Decode the TVR bit by bit.
Export the TAC and IAC values used for the selected AID.
Reproduce Terminal Action Analysis with bitwise comparisons.
For a second-GENERATE AC decline, validate tags 8A, 89, 91, 71, and 72.
Confirm the transaction type and avoid unintended cashback fields.
If the card returned AAC against an ARQC or TC request, involve the issuer or scheme when the available card data does not expose the reason.

References

POINT OF SALE ARCHITECTURE: A Practical Guide to Secure, Certifiable POS Systems — Chapter 3: EMV Principles (dual-layer risk management, TVR, TAC/IAC, GENERATE AC outcomes, CAPKs, and Offline Data Authentication).
EMVCo — EMV Contact Chip
EMVCo — Specifications and Associated Bulletins
EMV Integrated Circuit Card Specifications for Payment Systems, Book 3: Application Specification — Terminal Action Analysis, Terminal Verification Results, Card Action Analysis, and GENERATE AC.
EMV Integrated Circuit Card Specifications for Payment Systems, Book 4: Cardholder, Attendant, and Acquirer Interface Requirements — terminal transaction processing and online completion.
CardContact OpenSCDP — Terminal Action Analysis — worked examples of TVR / IAC / TAC matching and GENERATE AC P1 coding.

Generate-Ac on Corebaseit — POS · EMV · Payments · AI · Telecommunications