EMV Bit Field Decoder

Reading EMV bit numbering

EMV numbers bits from 8 down to 1, where b8 is the most significant bit of a byte and b1 the least. Byte 1 is the leftmost byte of the value. So in a TVR of 0508008000, byte 1 is 05, and the set bits are b3 and b1: "CDA failed" and a reserved bit.

This is the opposite convention from most programming languages, which is exactly why doing it by hand goes wrong. Every table on this page follows the EMV convention.

TVR (95) and TSI (9B)

The TVR is what the terminal thinks went wrong: a five-byte running record of every check that failed, was skipped, or could not be completed. The TSI is the shorter companion, two bytes saying which processing steps actually ran at all.

Read them together or you will misread both. A clear TVR bit means nothing if the corresponding TSI bit says the step never executed — "offline data authentication was not performed" and "offline data authentication passed" are very different findings, and only the TSI separates them.

AIP (82) and Terminal Capabilities (9F33)

These are the two capability claims, and comparing them explains most of the odd outcomes in a chip trace. The AIP is the card advertising what its application supports: which offline data authentication methods it can do, whether it wants cardholder verification, whether it supports issuer authentication. Terminal Capabilities is the terminal advertising its own side — how it reads cards, which CVMs it offers, which offline authentication it can perform.

Where the two disagree, the transaction falls back to whatever both ends support. A card that supports offline PIN presented at a terminal that does not will drop through to signature or to no CVM at all, and nothing in the decline tells you that is what happened. Two related fields decode here as well: Additional Terminal Capabilities (9F40), which covers the transaction types and input hardware, and Terminal Type (9F35), which is a single coded byte rather than a bit field and says who operates the terminal, whether it is attended, and whether it can go online.

CVM Results (9F34)

Three bytes answering three separate questions, and people routinely read only the first. Byte 1 is the CVM the terminal performed, byte 2 the condition under which the rule applied, and byte 3 is the one that matters: 02 means the CVM succeeded.

Byte 1 has a trap in it. Bit 7 set means "apply the succeeding CVM rule if this one fails", so 41 and 01 are both plaintext offline PIN and differ only in what happens next. A table that ignores the high bit reports them as two unrelated methods. 1F is "no CVM required" and 3F is "no CVM performed", which are also not the same thing: the first is a decision, the second is a gap.

AUC (9F07)

The Application Usage Control holds the issuer's restrictions on where the card may be used: domestic versus international, cash versus goods versus services, ATM versus non-ATM. When a transaction violates one, the terminal sets TVR byte 2 bit 5, "requested service not allowed for card product". That pairing is worth remembering, because the TVR bit is the symptom people see and the AUC is where the reason lives.

CID (9F27)

One byte carrying the outcome of a GENERATE AC. The top two bits are the cryptogram type — TC for an offline approval, ARQC to go online, AAC for a decline. Bit 4 asks for an advice message. The bottom three bits carry a reason code, and that is where you find "PIN try limit exceeded" on an offline decline rather than anywhere more obvious. How many attempts are actually left is a different field again: the card reports that in its status word, where 63CX puts the remaining count in the low nibble and 63C0 means blocked.

TTQ (9F66) and CTQ (9F6C)

The contactless pair, and the usual answer to "why did a tap ask for a signature". The TTQ is four bytes of reader capability sent to the card in the PDOL; the card reads it and decides what to ask for. The CTQ is the card's two-byte reply in the GPO response, saying what it wants the terminal to do about CVM and about going online.

The TTQ originated as Visa qVSDC and has since been reused well beyond it, which is why a misconfigured TTQ shows up as strange CVM behaviour on cards from schemes that never defined the field.

Reserved bits

Bits marked RFU are reserved in the spec version cited. Some have since been assigned by newer kernels. Relay resistance in TVR byte 5 and on-device CVM in the AIP are recent additions. This tool shows a set RFU bit rather than hiding it, because a set reserved bit usually means one of two things: your data is misaligned by a byte, or you are looking at a kernel newer than the table.

A set bit is not a decline

This is the most common misreading. The TVR is a report, not a verdict. What decides the outcome is whether a set TVR bit overlaps an Issuer Action Code, which is what the IAC comparator is for.