EMV TLV Parser

What this is parsing

EMV chip data is encoded as BER-TLV: a stream of tag, length, value triples. The tag identifies the data element, the length says how many bytes the value occupies, and some tags are "constructed", meaning their value is itself more TLV.

A tag is one or two bytes (occasionally more). If the low five bits of the first byte are all set, as in 1F, the tag continues into the next byte, and keeps going while the top bit is set. That is why you see both 95 and 9F26 as tags: the second needed more room in the numbering space.

Lengths are usually a single byte. If that byte is greater than 0x7F, its low seven bits say how many following bytes hold the real length, so 81 FF means 255 bytes and 82 01 00 means 256.

Where you get this data

The most common source is ISO 8583 DE 55 (or field 55), the ICC data element in an authorisation message, and if you have the whole message rather than the element the decoder will pull DE 55 out and parse it in place. You will also meet it in terminal logs as the response to GET PROCESSING OPTIONS (template 77), SELECT (template 6F), and READ RECORD (template 70).

Those log responses carry two more bytes than the TLV does. Every APDU reply ends with an SW1SW2 status word, and it sits after the data rather than inside it, so a trailing 9000 pasted in with the rest will be read as the start of another tag and overrun the end of the buffer. Strip the last two bytes first.

One thing that trips people up: template 80 is a "Format 1" response, which is not TLV. It is a bare concatenation of values whose order is implied by the command that was sent. If a parse fails on data starting with 80, that is why.

Common tags

9F26 is the cryptogram and 9F27 tells you which kind it is. An ARQC means the card wants to go online, a TC means it approved offline, an AAC means it declined. 95 is the Terminal Verification Results, the single most useful field for working out why something went wrong. 82 is the Application Interchange Profile, which says what the card is capable of. 9F10 is Issuer Application Data, whose internal layout is proprietary and differs between Visa and Mastercard.

All three of those are bitmaps, so the parse tree gives you the bytes and not yet the meaning. The bit field decoder takes it from there and names the individual bits. If the question is specifically why a transaction declined, go straight to the IAC comparator, which masks the TVR against the Issuer Action Codes and points at the bit responsible.

Cardholder data

Tags 5A (PAN), 57 and 9F6B (track-2-equivalent), 5F20 (cardholder name) and 99 (PIN data) carry sensitive values. This parser masks them by default and never puts them in a shareable link unless you press "copy link" yourself. Storing tag 57, or its ISO 8583 counterpart DE 35, after authorisation breaches PCI DSS, so if you find either in a log, that is a finding.