82), TVR (tag 95) and TSI (tag 9B). All three are bitmaps, all three are "about the transaction", and they get mixed up constantly. They answer three different questions: what the card can do, what the terminal observed, and what actually got done.
The cleanest way to keep the three apart is by who writes them and when:
| Tag | Name | Length | Written by | When, and what it answers |
|---|---|---|---|---|
82 | Application Interchange Profile | 2 bytes | the card | Before any checks, with the GPO response — "here is what I support" |
95 | Terminal Verification Results | 5 bytes | the terminal | During processing, bit by bit — "here is what I observed go wrong" |
9B | Transaction Status Information | 2 bytes | the terminal | By the end of processing — "here is what was actually performed" |
Capability → process → outcome. Or, if you prefer: the promise, the incident log, and the done list.
To make that concrete, the rest of this article decodes one transaction — a chip purchase that went online and was approved — through its three values:
3D000400048000F800The AIP comes back from the card in the GET PROCESSING OPTIONS response, before the terminal has verified anything. It is mostly static personalisation: the issuer decided at card-production time which features this application supports, and every transaction sees the same declaration. The bits that matter are all in byte 1:
| Position | Meaning |
|---|---|
Byte 1 · b8 | RFU |
Byte 1 · b7 | SDA supported |
Byte 1 · b6 | DDA supported |
Byte 1 · b5 | Cardholder verification is supported |
Byte 1 · b4 | Terminal risk management is to be performed |
Byte 1 · b3 | Issuer authentication is supported |
Byte 1 · b2 | RFU (contactless kernels reuse it for on-device CVM) |
Byte 1 · b1 | CDA supported |
Byte 2 is reserved in contact EMV; some contactless kernels borrow its bits, which is why you occasionally see a non-zero second byte on tap transactions.
Our example, 3D00, is byte 1 = 0011 1101: DDA supported, cardholder verification supported, terminal risk management to be performed, issuer authentication supported, CDA supported — and no SDA. Paste it into the AIP decoder and you get exactly that list back.
Note what the AIP does not contain: anything about this particular transaction. A transaction where CDA later blew up carries the same AIP as one where it sailed through. The AIP is the menu, not the meal.
The TVR starts the transaction as five bytes of zeros. As the terminal works through offline data authentication, application checks, cardholder verification, risk management and the issuer's reply, it sets a bit for every exceptional condition it meets. It records observations, not decisions — whether an observation leads to a decline is settled later, when the TVR is compared against the terminal and issuer action codes. The full 5-byte layout has its own reference: TVR bits explained.
Our example TVR is 0400048000. Drop it into the TVR decoder and three bits light up:
That mix is typical of a real TVR: one genuine problem, one neutral observation, one routine risk-management trigger. Reading a TVR as a list of disasters is the most common way to misread it.
The TSI is the smallest of the three: two bytes, and only six bits carry meaning. The terminal sets each bit once the corresponding function has been executed, so by the end of processing the TSI is a checklist of what this transaction actually did:
| Position | Meaning |
|---|---|
Byte 1 · b8 | Offline data authentication was performed |
Byte 1 · b7 | Cardholder verification was performed |
Byte 1 · b6 | Card risk management was performed |
Byte 1 · b5 | Issuer authentication was performed |
Byte 1 · b4 | Terminal risk management was performed |
Byte 1 · b3 | Script processing was performed |
Byte 1 · b2–b1 | RFU |
Byte 2 | RFU — should be 00 |
Our example, F800, is byte 1 = 1111 1000: offline data authentication, cardholder verification, card risk management, issuer authentication and terminal risk management were all performed; no issuer script arrived. The TSI decoder reads it back the same way.
The one nuance that catches everyone: "performed" is not "passed". TSI b8 says offline data authentication happened; it says nothing about how it went. The verdict lives in the TVR — which is exactly why the two must be read as a pair.
Now line the three values up and the transaction tells its story once, in three voices:
Which tag you open first depends on the question in front of you:
And two mismatch patterns worth memorising: AIP bit set but TSI bit clear means supported but skipped (ask why the terminal bypassed it); TSI bit set plus a TVR failure bit means ran and failed (ask why it failed). If you hit other tags while walking a DE55 dump, the EMV tag lookup covers the rest.
82 is the card's promise, tag 95 is the terminal's incident log, tag 9B is the done list. Capability → process → outcome. TSI tells you a function ran; only TVR tells you how it went.