TVR Explained: Every Bit of Tag 95

The Terminal Verification Results, tag 95, are five bytes the terminal fills in as an EMV transaction runs. Every bit records the outcome of one check. When a transaction is declined or unexpectedly goes online, the TVR is usually the first place to look.

How to read it

The terminal starts the transaction with all 40 bits set to 0. Each check that finds something worth noting sets its bit to 1. An all-zero TVR, 0000000000, means no check raised anything. Each byte covers one stage of the transaction:

A worked example

Take the value 8000048000:

• Byte 1 is 80: bit 8 is set, so offline data authentication was not performed.
• Byte 3 is 04: bit 3 is set, so the cardholder entered an online PIN. This bit is informational, not a failure.
• Byte 4 is 80: bit 8 is set, so the amount exceeds the terminal floor limit.

Read together: an online-only flow where the card's authentication step was skipped, the cardholder entered a PIN for the issuer to check, and the amount was too high to approve offline. That transaction will go online.

The TSI tells you what was attempted

The Transaction Status Information, tag 9B, records which functions the terminal performed, not whether they passed. Read it next to the TVR:

• TSI says offline data authentication was performed and TVR byte 1 shows DDA failed: the card's signature did not verify.
• TSI says it was not performed and TVR byte 1 b8 is set: the step was skipped, often because the card and terminal share no method.

From TVR to a decision

In terminal action analysis, the terminal compares the TVR with two sets of action codes: the issuer action codes from the card (9F0E Denial, 9F0F Online, 9F0D Default) and the terminal action codes from its own configuration.

1. If any TVR bit matches a Denial code, the terminal asks for an AAC and the transaction is declined offline.
2. If the terminal can go online and any TVR bit matches an Online code, it asks for an ARQC.
3. If the terminal cannot go online, it checks the Default codes instead: a match means decline, no match means approve offline.
4. Otherwise the terminal asks for a TC, an offline approval.

The card then has the final say in its GENERATE AC response. It can downgrade a TC request to an ARQC or an AAC, but never upgrade.

Common surprises

• Every transaction goes online. Check byte 4 b8 against a floor limit of zero, which many acquirers configure on purpose.
• Byte 1 b8 is always set on contactless. Many contactless flows do not perform offline data authentication for online transactions.
• Byte 5 bits look strange. Contactless kernels use the low bits of byte 5 for relay resistance. Check your kernel specification.

Where to find the TVR

• In field 55 of the authorisation request, as tag 95. This is the value the terminal had when it asked the card for the first cryptogram.
• Inside the GENERATE AC command, when CDOL1 includes tag 95. The card then uses the TVR as an input to the cryptogram, so the value in field 55 must match exactly.
• In terminal logs and clearing records, where the final TVR may include byte 5 bits set after the online response, such as issuer authentication failed.

TVR in contactless kernels

Contactless kernels reuse tag 95, but not always with the same layout. Mastercard's Kernel 2 keeps the EMV Book 3 bits and uses byte 5 bits 4 to 1 for relay resistance. EMVCo's Kernel 8 redefines several bytes: byte 1 reports local authentication instead of SDA, DDA and CDA, and byte 5 bit 8 marks the Kernel 8 format. Visa's Kernel 3 does not use the TVR at all: in its qVSDC path the card makes the decision and returns the cryptogram in the GET PROCESSING OPTIONS response, so the reader performs no terminal action analysis. The reader's requirements travel in the Terminal Transaction Qualifiers (9F66) instead, and the card's in the Card Transaction Qualifiers (9F6C). Always check which kernel processed the transaction before reading the bits; the TVR decoder has a layout for each.

TVR and CVR: terminal view and card view

The TVR records what the terminal saw. The card keeps its own record, often called the Card Verification Results, inside the Issuer Application Data (9F10). Its layout depends on the scheme and cryptogram version. When the TVR and the card's results disagree, for example the terminal says offline PIN was verified but the card says the PIN try limit was exceeded, the card's view is usually the one the issuer acts on.

A debugging checklist by symptom

Frequently asked questions

Does an offline approval need an all-zero TVR?

No. A terminal approves offline when no set bit matches the Denial or Online action codes, so some bits can be set as long as the issuer and acquirer have chosen not to act on them.

Can the TVR change after the first cryptogram?

Yes. Issuer authentication and script processing happen after the online response, so byte 5 bits can be set before the second GENERATE AC. That is why the TVR in a clearing record can differ from the one in the authorisation.

Who sets the action codes?

The issuer personalises the IACs on the card. The acquirer or payment scheme sets the TACs in the terminal configuration.