TSI Decoder

What the TSI records

Transaction Status Information is tag 9B, two bytes, and only six bits of the first byte are assigned. Each one says that a processing step was performed. It says nothing about how the step turned out: "cardholder verification was performed" is set whether the PIN was right or wrong.

Byte 2 is entirely reserved. A TSI with anything in its second byte is usually a value that has been misaligned by a byte, not a new feature.

Why the TVR needs it

The TVR sets a bit when something goes wrong, so a clear bit can mean the check passed or that it never happened. The TSI is what separates the two. If TVR byte 5 b7, "issuer authentication failed", is clear and TSI byte 1 b5 is set, the ARPC was checked and verified. If both are clear, no ARPC was ever checked, and the clear TVR bit tells you nothing.

Values you will see often

E800 is b8, b7, b6 and b4: offline data authentication, cardholder verification, card risk management and terminal risk management all ran. That is a complete contact transaction up to the first GENERATE AC. F800 adds b5, issuer authentication, which appears once the response has come back and the card has checked the ARPC. FC00 adds b3 as well, because an issuer script was processed.

6800 is the same as E800 without b8: no offline data authentication. Expect the TVR alongside it to have byte 1 b8 set, and if it does not, one of the two values was captured at a different point in the transaction.

When it was captured matters

The terminal sets these bits as it goes, so the TSI in an authorisation request is a snapshot taken before the issuer has replied. Issuer authentication and script processing cannot be set in it yet. The final value is the one in the terminal's own record after the second GENERATE AC, and the two are often quoted as if they were the same.

The TSI belongs to the contact flow. Several contactless kernels do not define it, so a tap that carries no 9B is not necessarily broken.