The TVR, the TSI, and How a Terminal Decides to Decline You

💡 TL;DR (Too Long; Didn't Read)

The decision engine in 90 seconds:

The TVR (Terminal Verification Results, tag 95, 5 bytes) is a running list of everything that went wrong or notable during the transaction — each bit is one check result.

The TSI (Transaction Status Information, tag 9B, 2 bytes) records which functions were performed at all. TVR says "what happened"; TSI says "what we even attempted."

The verdict is pure bitwise logic. The terminal ANDs the TVR against action codes — IAC (Issuer Action Codes, from the card) and TAC (Terminal Action Codes, from the acquirer config) — for Denial, Online, and Default.

Denial match → AAC (decline offline). Online match on an online-capable terminal → ARQC (go online). No match → TC (approve offline).

Ninety percent of "why was this declined / why did it go online" investigations end the moment you decode the TVR and line it up against the action codes. This is that skill.

In the first part of this series I described a chip transaction as the terminal assembling a picture of the card, tag by tag, until it has enough to make a decision. This article is about the decision itself — the step EMV calls Terminal Action Analysis — and about the two tags that carry the state it runs on. If you have ever stared at a decline you could not explain, or watched a low-value transaction inexplicably go online and add latency, the answer was almost certainly written in five bytes you did not decode: the Terminal Verification Results, tag 95.

The beautiful thing about this phase is that there is no magic in it. After all the reading and authenticating and PIN-checking, the accept/online/decline verdict comes down to bitwise AND. Learn the bit layouts and the AND rule and you can predict a terminal's decision on paper, which means you can debug one in production. Everything here is EMVCo Book 3, §10.7 and Annex C5/C6 — I will cite the structure, not reproduce the spec.

Two bit fields, two different questions

Keep these straight, because engineers conflate them constantly.

The TVR (tag 95) answers "what went wrong, or what is worth flagging?" Its five bytes are a catalogue of negative and notable outcomes: offline authentication failed, the application expired, PIN entry was required but no pad was present, the amount exceeded the floor limit, issuer authentication failed. A freshly initialized TVR is all zeros — a clean transaction. Bits get set as checks produce concerning results. In the TVR, set bits are bad news (or at least news).

The TSI (tag 9B) answers a different question: "which functions did we perform at all?" Its two bytes record that offline data authentication was performed, that cardholder verification was performed, that terminal risk management was performed, and so on. The TSI is not about pass or fail; it is about attempted or skipped. You need it because "the SDA-failed bit in the TVR is zero" is ambiguous — did SDA pass, or did SDA never run? The TSI disambiguates: check its "offline data authentication was performed" bit and you know which world you are in.

Decoding the TVR, byte by byte

Let us decode a real one. Suppose a terminal presents 95 05 00 00 00 80 00 — tag 95, length 5, value 00 00 00 80 00. Five bytes, each a bit field. Here is the map for the bits you will actually encounter, grouped by byte and by concern.

Byte 1 — Offline Data Authentication. The high bit (b8) means offline data authentication was not performed. Below it: SDA failed (b7), ICC data missing (b6), card appears on the terminal exception file (b5), DDA failed (b4), CDA failed (b3). This byte is where a cloned or tampered card, or a broken certificate chain, announces itself.

Byte 2 — Processing Restrictions. ICC and terminal have different application versions (b8), expired application (b7), application not yet effective (b6), requested service not allowed for this card product (b5), new card (b4). The "requested service not allowed" bit is the usual culprit behind "this card works everywhere except here" — a domestic card refused on an international terminal, encoded in one bit.

Byte 3 — Cardholder Verification. Cardholder verification was not successful (b8), unrecognised CVM (b7), PIN Try Limit exceeded (b6), PIN entry required but the PIN pad is absent or broken (b5), PIN entry required and pad present but PIN not entered (b4), online PIN entered (b3). This byte is the forensic record of the CVM phase from Part 1.

Byte 4 — Terminal Risk Management. Transaction exceeds the floor limit (b8), lower consecutive offline limit exceeded (b7), upper consecutive offline limit exceeded (b6), transaction selected randomly for online processing (b5), merchant forced the transaction online (b4). None of these are "failures" — they are reasons a terminal wants an issuer in the loop.

Byte 5 — Issuer / Completion. Default TDOL used (b8), issuer authentication failed (b7), script processing failed before the final GENERATE AC (b6), script processing failed after it (b5). In contactless profiles the lower bits of this byte carry relay-resistance results. This byte is mostly written after the online exchange.

Now decode our example 00 00 00 80 00. Bytes 1, 2, 3, and 5 are zero — no authentication problems, no restriction issues, no CVM concerns, no issuer/script failures. Byte 4 is 0x80 = 1000 0000, so b8 is set: the transaction exceeded the floor limit. That is the entire story this TVR tells: a perfectly healthy card whose amount crossed the offline ceiling. Nothing failed. But that single set bit is about to send the transaction online, and understanding why requires the action codes.

The action codes: IAC and TAC

A set TVR bit is a fact, not a decision. "Floor limit exceeded" does not mean anything until something maps it to a consequence. That mapping is the job of the action codes, and there are two sources of them, which is the part that confuses people.

The TAC (Terminal Action Codes) are configured by the acquirer into the terminal. They express the acquirer's risk appetite: "for my terminals, these conditions must decline, these must go online, these are the default." The IAC (Issuer Action Codes) live on the card and are read during Part 1's READ RECORD phase (tags 9F0D IAC-Denial, 9F0E IAC-Online, 9F0F IAC-Default). They express the issuer's risk appetite for their own cards.

Both come in the same three flavours, and each is a 5-byte mask with the exact same bit layout as the TVR:

Denial (TAC-Denial, IAC-Denial 9F0D): conditions under which the transaction must be declined offline, without even asking the issuer.
Online (TAC-Online, IAC-Online 9F0E): conditions under which the transaction must be sent online for an issuer decision.
Default (TAC-Default, IAC-Default 9F0F): conditions under which to act when the terminal cannot go online (offline-only terminal, or online attempt failed).

Because the action codes share the TVR's layout, "does this TVR trigger this action code" is a single bitwise AND: line the two 5-byte fields up and see if any bit is set in both.

The AND logic that produces the verdict

Here is the actual algorithm the terminal runs. It is worth memorizing because it is small and it is the whole ballgame.

Read it top to bottom. Denial first: AND the TVR with both IAC-Denial and TAC-Denial; if either produces a non-zero result, the terminal requests an AAC and the transaction declines offline — the issuer is never contacted. Online second: if the terminal can go online, AND the TVR with IAC-Online and TAC-Online; a non-zero result means request an ARQC and route to the issuer. Default third: only relevant when the terminal cannot go online — AND against the Default codes to decide between declining and approving offline. If nothing matches at any stage, the terminal requests a TC and approves offline.

Note the priority: Denial dominates Online dominates Default. A bit that appears in both the Denial and the Online masks will decline, because Denial is checked first. This ordering is not incidental — it is how the system guarantees that "must never approve" always wins over "should ask the issuer."

Two worked examples

Let us run our floor-limit TVR through it. TVR = 00 00 00 80 00. Assume typical action codes: TAC-Denial = 00 00 00 00 00 (this acquirer declines nothing purely offline), TAC-Online has byte 4 b8 set (floor-limit-exceeded should go online), and the card's IAC values do not force a denial.

Denial: 00 00 00 80 00 AND 00 00 00 00 00 = 0; AND IAC-Denial = 0. No denial.
Online (terminal is online-capable): 00 00 00 80 00 AND TAC-Online (00 00 00 80 00) = 00 00 00 80 00 ≠ 0. Match.
Verdict: request ARQC, go online.

That is the complete explanation for "why did my $4 coffee go online?" The amount crossed the floor limit, the floor-limit bit set in TVR byte 4, and the acquirer's TAC-Online mapped that bit to "go online." No failure, no fraud — just configuration meeting arithmetic.

Now a darker example. Suppose offline data authentication failed on an offline-only terminal (a transit gate, say). SDA failed → TVR byte 1 b7 set → TVR = 40 00 00 00 00. The card's IAC-Denial has byte 1 b7 set (issuers routinely say "if my card's authentication fails, decline — do not even try online").

Denial: 40 00 00 00 00 AND IAC-Denial (40 00 00 00 00) = 40 00 00 00 00 ≠ 0. Match.
Verdict: request AAC, decline offline. The issuer is never contacted, correctly — a card whose authentication failed should not get a second chance from a gate that cannot verify it online.

Two set bits, two different bytes, two opposite outcomes, both fully determined by AND. This is why decoding the TVR is the single highest-leverage debugging skill in terminal-side EMV.

Battle scars

The card can still overrule the terminal. Terminal Action Analysis produces a request — the P1 of the first GENERATE AC. The card runs its own Card Action Analysis and can downgrade: you request a TC, the card returns an ARQC or an AAC based on its internal risk state and its IAC evaluation. So "the TVR said approve" and "the transaction approved" are different claims. Always confirm the outcome in the returned Cryptogram Information Data (tag 9F27), not in your own pre-decision.

Empty action codes are a decision, not an absence. A TAC-Denial of all zeros does not mean "safe defaults" — it means "decline nothing offline no matter what," including a failed CDA. Misconfigured all-zero TAC-Denial with an offline-capable path is a genuine fraud exposure. The action codes are security policy; treat blank ones as a finding, not a default.

TVR byte 5 is written late. The issuer-authentication and script-processing bits in byte 5 are set after the online exchange, during second-generate-AC processing. If you snapshot the TVR before going online and treat it as final, you will miss issuer-authentication failures entirely. Decode the TVR that comes back with the completion, not just the one from the first decision.

Where this fits

You now understand the decision. What you have not yet seen is what the ARQC actually is — the cryptogram the terminal requests when this logic says "go online." That is Part 4: building an Application Cryptogram from scratch, with real test keys, so the assertion the issuer validates stops being a black box. And the bit fields you decoded here are exactly the kind of structure the gsstk EMV Tag Dictionary already breaks down per tag — 95 (TVR) and 9B (TSI) — with a dedicated TVR/TSI Decoder on the roadmap to turn five hex bytes into a plain-English list of set conditions, the difference between guessing at a decline and reading it.

What Actually Happens When You Dip a Chip: The EMV Transaction Flow End-to-End — Part 1: where the TVR gets populated across the transaction.
Reading BER-TLV by Hand — and Why You Shouldn't — Part 2: parsing the tags before you decode their bits.
ARQC from Scratch: Application Cryptograms Without the Black Box — Part 4: what "go online" actually sends.

Tools: decode the two bit fields on their tag pages — 95 (TVR) and 9B (TSI) — plus the issuer action codes 9F0D / 9F0E / 9F0F in the EMV Tag Dictionary. (A dedicated TVR/TSI Decoder is on the roadmap.)

Filed under: EMV · Payments · POS · Acquiring · Contactless

This article was human-architected and synthesized with AI assistance under the Nexus (AI) persona.