TVR Decoder
Decode the Terminal Verification Results (EMV tag 95) 5-byte bitfield into human-readable flag descriptions.
Follows EMV 4.4 Book 3 Annex C5 · Book C-2Terminal Verification Results (tag 95), incl. Kernel 2 byte 5·verified Oct 2026· double-checked Oct 2026— every bit checked against openemv/emv-utils, proxmark3 and binaryfoo
Try it as a puzzle: set the TVR flags a terminal would raise →
What the Terminal Verification Results (95) capture
The Terminal Verification Results (TVR), EMV tag 95, is the single most important diagnostic field in a chip or contactless transaction. It is a 5-byte bitmap in which the terminal records every exception it encountered: offline data authentication results, processing restrictions, cardholder verification problems, terminal risk management outcomes, and issuer-script results. If you debug one EMV field, it is this one.
The TVR does not decide anything by itself. At the action-analysis step the terminal masks the TVR against the Terminal Action Codes (Default, Denial, Online) and the card's Issuer Action Codes. A bit set in the TVR only forces a decline or a go-online if the matching action-code bit is also set — which is why two terminals can treat the same card differently.
Reading the five bytes
Byte 1 covers offline data authentication: ODA not performed, SDA, DDA or CDA failed, ICC data missing, card on the exception file, and which method was chosen ("SDA selected", "XDA selected"). An XDA failure is recorded in byte 4 bit 1, not byte 1. Byte 2 covers processing restrictions (application versions, expiry and effective dates, usage control) plus "New card". Byte 3 covers cardholder verification (CVM not successful, PIN try limit, PIN pad problems, online CVM captured). Byte 4 covers terminal risk management (floor limit, velocity checks, random and merchant-forced online). Byte 5 covers the default TDOL, issuer authentication and issuer scripts. Pair the TVR with the TSI to see not just what failed but what was performed.
EMV 4.4 filled most of the bits that used to be reserved: "XDA selected" and "XDA signature verification failed" for the elliptic-curve authentication method, six biometric flags in bytes 2–4 (byte 2 bits 2–1, byte 3 bits 2–1, byte 4 bits 3–2), and "CA ECC key missing" and "ECC key recovery failed" in byte 5 bits 3 and 2. It also renamed byte 3 bit 3 from "Online PIN entered" to "Online CVM captured". Byte 5 bits 4 and 1 are left to the contactless specifications.
Contactless kernels use byte 5 bits 4–1 for their own results. In Kernel 2 (Mastercard) data, Book C-2 defines bit 4 as "Relay resistance threshold exceeded", bit 3 as "Relay resistance time limits exceeded" and bits 2–1 as the relay resistance status (00 not supported, 01 not performed, 10 performed, 11 RFU). A normal Mastercard tap with relay resistance performed therefore has byte 5 = 02, which a contact-only reading would show as "ECC key recovery failed". When any of these bits is set the decoder shows both readings and does not count them as issues. The Kernel 2 meanings come from Book C-2 alone (single source in our checks).
Not every set bit is a problem. "SDA selected", "XDA selected", "Biometric performed and successful", "Online CVM captured", "Transaction selected randomly for online processing" and "Default TDOL used" record what happened rather than an exception, so the decoder lists them as informational.
Common questions
A TVR bit is set but the transaction still approved — is that wrong?
No. A set TVR bit is only acted upon if the corresponding terminal or issuer action code bit is set. Many TVR bits are informational and routinely set on approved transactions.
Which byte explains a "floor limit exceeded" go-online?
Byte 4. Terminal risk management sets "Transaction exceeds floor limit" there, which the online action code then turns into a go-online decision.
Bit definitions follow EMV 4.4 Book 3 Annex C5; the Kernel 2 reading of byte 5 follows EMV Contactless Book C-2. All decoding happens locally in your browser.