95, five bytes) is the terminal's record of everything it checked and everything that went wrong during an EMV transaction. It travels in DE55 and it is the single most useful field when you are trying to answer "why did the chip transaction behave that way?"
TVR is five bytes, usually written as ten hex characters — for example 0000008000. Each byte covers one category of checks, and within a byte the bits are numbered b8 (most significant) down to b1. A bit set to 1 means "this condition occurred". Bits marked RFU below are reserved and should be zero.
Byte 1 records whether the terminal could cryptographically verify the card offline, and how that verification failed.
| Position | Meaning |
|---|---|
Byte 1 · b8 | Offline data authentication was not performed |
Byte 1 · b7 | SDA failed |
Byte 1 · b6 | ICC data missing |
Byte 1 · b5 | Card appears on terminal exception file |
Byte 1 · b4 | DDA failed |
Byte 1 · b3 | CDA failed |
Byte 1 · b2 | RFU |
Byte 1 · b1 | RFU |
Byte 2 covers mismatches between what the card offers and what the terminal supports, plus card lifecycle problems such as expiry.
| Position | Meaning |
|---|---|
Byte 2 · b8 | ICC and terminal have different application versions |
Byte 2 · b7 | Expired application |
Byte 2 · b6 | Application not yet effective |
Byte 2 · b5 | Requested service not allowed for card product |
Byte 2 · b4 | New card |
Byte 2 · b3 | RFU |
Byte 2 · b2 | RFU |
Byte 2 · b1 | RFU |
Byte 3 is the CVM story: whether the cardholder was verified, and if not, what got in the way. This is the byte that most often explains a PIN-related dispute.
| Position | Meaning |
|---|---|
Byte 3 · b8 | Cardholder verification was not successful |
Byte 3 · b7 | Unrecognised CVM |
Byte 3 · b6 | PIN try limit exceeded |
Byte 3 · b5 | PIN entry required and PIN pad not present or not working |
Byte 3 · b4 | PIN entry required, PIN pad present, but PIN was not entered |
Byte 3 · b3 | Online PIN entered |
Byte 3 · b2 | RFU |
Byte 3 · b1 | RFU |
Byte 4 explains why the terminal decided to go online rather than approve offline. If you are investigating unexpected online traffic from a merchant, start here.
| Position | Meaning |
|---|---|
Byte 4 · b8 | Transaction exceeds floor limit |
Byte 4 · b7 | Lower consecutive offline limit exceeded |
Byte 4 · b6 | Upper consecutive offline limit exceeded |
Byte 4 · b5 | Transaction selected randomly for online processing |
Byte 4 · b4 | Merchant forced transaction online |
Byte 4 · b3 | RFU |
Byte 4 · b2 | RFU |
Byte 4 · b1 | RFU |
Byte 5 records what happened after the issuer replied: whether issuer authentication passed and whether issuer scripts ran successfully.
| Position | Meaning |
|---|---|
Byte 5 · b8 | Default TDOL used |
Byte 5 · b7 | Issuer authentication failed |
Byte 5 · b6 | Script processing failed before final GENERATE AC |
Byte 5 · b5 | Script processing failed after final GENERATE AC |
Byte 5 · b4 | RFU |
Byte 5 · b3 | RFU |
Byte 5 · b2 | RFU |
Byte 5 · b1 | RFU |
No. TVR records observations, not decisions. A perfectly normal approved transaction routinely carries set bits — "transaction exceeds floor limit" simply means the terminal went online, which is what you want it to do.
The decision comes from comparing TVR against the Terminal Action Codes and Issuer Action Codes. Those masks say which observations should force a decline, which should force going online, and which can be ignored. Reading TVR without the action codes tells you what happened, not why the outcome was what it was.