My TVR is all zeros but the transaction declined. Why?

Because the TVR is the terminal's report, not the issuer's. It records what the terminal checked and what it found — offline authentication, cardholder verification, floor limits, risk management. An issuer decline arrives separately in tag 8A, the authorisation response code, and leaves the TVR untouched. An all-zero TVR with a decline therefore means the terminal was satisfied and the host was not, which points your investigation at the authorisation rather than at the card or the reader.

How are the bits numbered?

Five bytes, numbered 1 to 5 as the specification numbers them, and within each byte the bits run 8 down to 1 with bit 8 the most significant. So byte 1 bit 8 is the top bit of the first byte — 'offline data authentication was not performed' — and byte 4 bit 8 is the top bit of the fourth byte, 'transaction exceeds floor limit'. Almost every wrong reading of a TVR is an off-by-one in the byte index, which is why it is worth decoding both ends of the range to check.

A bit is set that my table says is RFU. What does that mean?

Almost always that the value is misaligned rather than that something exotic happened. Reserved bits are reserved precisely because nothing sets them, so a set one usually means the five bytes you are reading are not the TVR — commonly because a preceding TLV length was wrong and everything after it shifted. Treat it as a parsing fault before treating it as a payments one.

What is the difference between the TVR and the TSI?

The TVR (tag 95) records what was checked and what failed. The TSI (tag 9B) records what was performed at all. Reading them together answers a question neither answers alone: a check that shows no failure in the TVR might simply never have run, and the TSI is where that shows. If you are asking 'was this even attempted?', the TSI is the field you want.

What the EMV TVR bits actually mean

Five bytes of hex that answer 'what did the terminal find'. Read the wrong byte and you debug the wrong thing — and a set reserved bit almost always means you are a byte out.

18 August 2026

Tag 95 is five bytes of hex inside EMV chip data, and it is the first thing worth reading on a chip transaction that went wrong. It is also the field most often read incorrectly, because reading it means counting bits off a specification table and it is very easy to be one byte out.

It records what the terminal found, not what the issuer decided

This is the misunderstanding that wastes the most time. The Terminal Verification Results are the terminal's report: what it checked, and what it did not like. Offline data authentication, cardholder verification, floor limits, risk management.

An issuer decline is not in there. That arrives in tag 8A, the authorisation response code, and it leaves the TVR completely untouched.

How the bits are numbered

Five bytes, numbered 1 to 5 as the specification numbers them. Within each byte the bits run from 8 down to 1, with bit 8 the most significant — so byte 1 bit 8 is the very first bit of the field.

Byte 1 — offline data authentication

bit 8   Offline data authentication was not performed
bit 7   SDA failed
bit 6   ICC data missing
bit 5   Card appears on terminal exception file
bit 4   DDA failed
bit 3   CDA failed

Byte 4 — terminal risk management

bit 8   Transaction exceeds floor limit
bit 7   Lower consecutive offline limit exceeded
bit 6   Upper consecutive offline limit exceeded
bit 5   Transaction selected randomly for online processing
bit 4   Merchant forced transaction online

A worked example

Take the value 0080008000. Two bits are set, in two different bytes:

TVR 0080008000

byte 2, bit 8   ICC and terminal have different application versions
byte 4, bit 8   Transaction exceeds floor limit

Together those say: the terminal did not perform offline data authentication, the card and terminal disagreed about the application version, and the amount was over the floor limit so the transaction went online. None of that is a failure — it is a transaction that behaved exactly as it should and went to the issuer for a decision.

The mistake to expect: being one byte out

Reading the same five bytes shifted by one gives a completely different and entirely plausible story:

TVR 0000800080 — the same findings, one byte later

byte 3, bit 8   Cardholder verification was not successful
byte 5, bit 8   Default TDOL used

Nothing about that output looks wrong. It names real bits with real meanings, and it sends you to investigate something that never happened. This is why decoding both ends of the range matters: if the bits you get do not match the transaction you observed, suspect the offset before you suspect the terminal.

The TVR and the TSI answer different questions

Tag 95 says what was checked and what failed. Tag 9B, the Transaction Status Information, says what was performed at all.

That distinction resolves a question neither answers alone. A check showing no failure in the TVR might simply never have run — and the TSI is where that shows. If you are asking “was this even attempted?”, the TSI is the field you want, and reading the two together is how you tell “passed” from “skipped”.

Finding it in an ISO 8583 message

The TVR lives inside field 55, the ICC data, as a BER-TLV object. Field 55 is binary and carries a run of EMV tags, so tag 95 is not at a fixed offset — it has to be found by parsing the TLV structure, which is exactly the step people skip when they start counting bytes by hand.

Most ISO 8583 parsers show field 55 as an opaque run of hex and stop there. The ISO 8583 parser & builder on this site decodes it in place, and EMV tag decoder takes the field on its own and breaks the TVR, AIP and TSI out bit by bit — including flagging a set reserved bit rather than quietly dropping it. Both run entirely in your browser.

Check it against the tool

EMV tag decoder — BER-TLV and ISO 8583 field 55
Decode EMV chip data into named tags, with the TVR, AIP and cryptogram broken out bit by bit.
ISO 8583 message parser and builder
Decode the MTI, bitmap and data elements of an ISO 8583 message, or assemble one field by field with the bitmap computed for you.

Frequently asked questions

My TVR is all zeros but the transaction declined. Why?: Because the TVR is the terminal's report, not the issuer's. It records what the terminal checked and what it found — offline authentication, cardholder verification, floor limits, risk management. An issuer decline arrives separately in tag 8A, the authorisation response code, and leaves the TVR untouched. An all-zero TVR with a decline therefore means the terminal was satisfied and the host was not, which points your investigation at the authorisation rather than at the card or the reader.
How are the bits numbered?: Five bytes, numbered 1 to 5 as the specification numbers them, and within each byte the bits run 8 down to 1 with bit 8 the most significant. So byte 1 bit 8 is the top bit of the first byte — 'offline data authentication was not performed' — and byte 4 bit 8 is the top bit of the fourth byte, 'transaction exceeds floor limit'. Almost every wrong reading of a TVR is an off-by-one in the byte index, which is why it is worth decoding both ends of the range to check.
A bit is set that my table says is RFU. What does that mean?: Almost always that the value is misaligned rather than that something exotic happened. Reserved bits are reserved precisely because nothing sets them, so a set one usually means the five bytes you are reading are not the TVR — commonly because a preceding TLV length was wrong and everything after it shifted. Treat it as a parsing fault before treating it as a payments one.
What is the difference between the TVR and the TSI?: The TVR (tag 95) records what was checked and what failed. The TSI (tag 9B) records what was performed at all. Reading them together answers a question neither answers alone: a check that shows no failure in the TVR might simply never have run, and the TSI is where that shows. If you are asking 'was this even attempted?', the TSI is the field you want.
Where do I find the TVR in an ISO 8583 message?: Inside field 55, the ICC data, as a BER-TLV object with tag 95. Field 55 is a binary field carrying a run of EMV tags, so the TVR is not at a fixed offset — it has to be found by parsing the TLV structure. Most ISO 8583 parsers show field 55 as an opaque run of hex, which is why the value is so often read by counting bytes by hand.