The TSI is two bytes recording which processing steps the terminal actually ran — not how they went. Paste your hex value; the performed steps light up. Read it next to the TVR: the TSI says what was executed, the TVR says what failed.
All the information lives in byte 1; byte 2 is entirely reserved. Six bits are defined, and each one answers the same question — did this step run at all: b8 offline data authentication (SDA, DDA or CDA was executed), b7 cardholder verification (CVM processing ran), b6 card risk management, b5 issuer authentication (the terminal verified the issuer's ARPC), b4 terminal risk management (floor limit, velocity and random-selection checks), b3 issuer script processing (scripts from tag 71 or 72 were processed).
Note what is missing: there is no success or failure anywhere in this list. E800 says offline authentication, cardholder verification and terminal risk management all ran — it says nothing about whether any of them passed.
The TVR records which checks did not pass; the TSI records which steps were executed. Neither is meaningful alone. A clean TVR byte 3 does not mean cardholder verification succeeded — if TSI b7 is 0, it was never attempted, and “no failure recorded” is just silence. Conversely, TVR byte 1 b8 (“offline data authentication was not performed”) should line up with TSI b8 being 0; if they disagree, one of the two values was taken from a different transaction.
That cross-check is the fastest sanity test when someone hands you a TVR/TSI pair from a log: the two values must tell a consistent story before you spend time on either.
Pull tags 95 and 9B from DE55 together. If the issuer host declined with “issuer authentication failed” in the TVR, first confirm TSI b5 is set — if issuer authentication never ran, the terminal may simply not support it, which is a terminal configuration finding, not a cryptography one. If an issuer script was sent (tag 71/72 in the response) but TSI b3 is 0, the terminal never processed it — the card never received your PIN unblock or parameter update, and the follow-up transaction will fail the same way.
On contactless transactions many steps are legitimately skipped, so a sparse TSI (0000 included) is normal there. On a contact chip transaction, a TSI of 0000 almost always means the transaction never got past application selection.