EMV Tag Reference: All 66 DE55 Tags — Length, Format, Meaning

Every tag this site's parser knows, in one printable table — grouped by what the tag is for, not by hex order — plus the three rules that let you read raw TLV by eye.

How to read a TLV before you read the table

A tag table is only useful if you can find the tag boundaries in the first place. Three rules cover everything DE55 will throw at you:

• Rule 1 — when a tag is two bytes. Look at the low five bits of the first tag byte. If they are all ones (xxx1 1111, i.e. the byte ends in F after masking: 9F, 5F, BF, DF…), the tag continues into the next byte. That is why 9F26 is a two-byte tag while 95 is complete in one. (A subsequent tag byte with its top bit set would extend the tag further still — three-byte tags are legal in BER, you just won't meet them in DE55.)
• Rule 2 — when the length is more than one byte. If the length byte is 00–7F, that is the length. If its top bit is set, the low seven bits say how many following bytes hold the actual length: 81 C8 means "length in the next 1 byte" = 200 bytes, 82 01 04 means 260 bytes. You meet this on long templates and issuer scripts.
• Rule 3 — when the value is itself TLV. Bit 6 of the first tag byte (0x20) marks a constructed tag: the value is another run of TLVs, not a final value. 77 (0111 0111) is constructed — expand it. 80 (1000 0000) is primitive, despite being named a "template". The tag byte, not the name, is the truth.

Worked example — a minimal GENERATE AC response fragment, 771082023D00950500000080009F3602004B:

Paste that string into the EMV TLV parser and you get the same walk back: one top-level tag, four tags in total, with the AIP, TVR and ATC broken out. For a whole DE55 that is always the faster route — this section exists so the output never looks like magic.

The 66 tags, grouped by purpose

Grouped the way you actually query them: by what stage of the transaction the tag belongs to. Formats: b = binary, n = numeric (BCD digits), cn = compressed numeric (BCD, padded with F), an / ans = alphanumeric (with specials), template = constructed, the value is more TLV. Byte counts are value lengths — the tag and length bytes come on top.

Application selection & templates (14)

Everything the card and terminal exchange to agree which application runs. The AID — the answer to "what is an AID in EMV" — is a registered identifier of 5–16 bytes: a 5-byte RID naming the scheme plus an optional PIX naming the product; A0000000031010, for instance, is Visa's main credit/debit application (the AID lookup has the common ones). Templates are wrappers: expand them and read the tags inside.

Card data (15)

Personalised onto the chip by the issuer; the same values come back transaction after transaction. This is also where the cardholder data lives — 5A, 57 and 5F20 are PAN-equivalent and fall under PCI DSS: mask them before a DE55 dump goes into a log, a ticket or a screenshot.

Terminal & transaction data (19)

Supplied by the terminal, per transaction. These are the fields the card's cryptogram is computed over — which is why a DE55 repeats information (amount, currency, date) that also exists elsewhere in the ISO 8583 message: the copy in DE55 is the one the chip signed.

Cryptograms & online authentication (8)

The reason DE55 exists at all. 9F26 is the ARQC in the request; 91 carries the issuer's ARPC back; the rest give both sides the context to verify each other. If a "what is ARQC" question brought you here: it is the 8-byte cryptogram in 9F26 when the card asks to go online — see ARQC vs TC vs AAC for the full story.

Verification results & status bit strings (4)

The tags that look like gibberish until decoded bit by bit — and the ones that answer most troubleshooting questions. Each is expanded below.

Issuer scripts (3)

The issuer's channel for managing a card it can no longer touch physically: script commands ride the authorization response, the terminal relays them to the chip, and 9F5B reports back in a later transaction.

Scheme & proprietary (3)

Three tags the parser recognises by their most common use, but which are not defined by the public EMV books — the authoritative layout lives in each scheme's own specification.

The bit-string tags, one by one

Seven tags in DE55 pack their meaning into individual bits, and one more (the ATC) into a plain counter. For each: the question it answers, a real value, and the decoder that expands it. Every example below was run through the linked decoder — the readings are the tool's output, not paraphrase.

TVR — tag 95, 5 bytes

Answers: "what did the terminal see go wrong?" Starts as five bytes of zeros; the terminal sets a bit for every exceptional condition it meets — offline authentication failures, CVM problems, floor-limit triggers, issuer-authentication failures. Observations, not decisions: whether a set bit declines the transaction is settled against the action codes (9F0D/0E/0F). Example: 0400048000 decodes to three set bits — CDA failed (byte 1·b3), online PIN entered (byte 3·b3), transaction exceeds floor limit (byte 4·b8). One real problem, one neutral fact, one routine online trigger — a typical mix. Decode yours in the TVR decoder; the full bit map is in TVR bits explained.

AIP — tag 82, 2 bytes

Answers: "what does this card support?" Static personalisation, declared with the GPO response before any check has run: which offline authentication methods (SDA / DDA / CDA), whether cardholder verification and issuer authentication are supported, whether terminal risk management must run. Example: 3D00 announces DDA, cardholder verification, terminal risk management, issuer authentication and CDA — but no SDA. Check any value in the AIP decoder; how AIP relates to TVR and TSI is the subject of AIP vs TVR vs TSI.

TSI — tag 9B, 2 bytes

Answers: "which EMV functions actually ran?" Six meaningful bits, all in byte 1, each set once the corresponding function executed — regardless of how it went. Example: F800 means offline data authentication, cardholder verification, card risk management, issuer authentication and terminal risk management were all performed, and no issuer script was. "Performed" is not "passed": the verdict lives in the TVR. Decode in the TSI decoder.

CID — tag 9F27, 1 byte

Answers: "what kind of cryptogram is 9F26?" The top two bits classify it — 00 AAC (decline), 01 TC (approve), 10 ARQC (go online) — and the low bits carry advice flags. Example: 80 = ARQC, online authorisation requested. Decode in the CID decoder; the three cryptogram types are compared in ARQC vs TC vs AAC.

CVM Results — tag 9F34, 3 bytes

Answers: "how was the cardholder actually verified?" Three bytes: the method performed, the condition under which it applied, and the result. Example: 410302 = plaintext PIN verified by the ICC (41, with permission to fall through to the next rule on failure), applied because the terminal supports the CVM (03), and it succeeded (02). Decode in the CVM Results decoder.

CVM List — tag 8E

Answers: "in what order did the card want verification attempted?" Two 4-byte amounts (X and Y) followed by 2-byte rules, each a method plus a condition, tried top to bottom. Example: 000003E800000000420344031E031F02 = X 1000, Y 0, four rules — enciphered PIN online, enciphered PIN by ICC, signature, then "no CVM required" when the conditions allow. One placement note: 8E is personalised in the card's records and consumed by the terminal during CVM selection — it is not one of the 66 tags above because it does not normally travel in DE55; what travels is the outcome, 9F34. Decode one in the CVM List decoder; the rule-by-rule logic is in the CVM List article.

IAD — tag 9F10, up to 32 bytes

Answers: "what is the issuer telling itself?" The one tag in this section without a public bit map: EMV reserves the container, the issuer (via its scheme's template) defines the content — typically a derivation key index, the cryptogram version number (CVN), and the Card Verification Results, the card's own view of the transaction. Example: 06101203A40000 reads, under the common Visa-style layout, as length 6, DKI 10, CVN 12 (= version 18), CVR 03A40000 — but any such split is a heuristic until confirmed against the CVN and the scheme spec, which is exactly how the IAD decoder labels it. Background: IAD tag 9F10 explained.

ATC — tag 9F36, 2 bytes

Answers: "how many transactions has this chip done?" Not a bit string — a big-endian counter that increments every time the application starts a transaction. Example: 003C = 60. Issuers compare it against the last ATC seen: gaps are normal (offline transactions not yet cleared), but a repeated or decreasing ATC is a strong cloning signal. Convert values in the ATC decoder; more in the ATC article.

Reading a DE55 in practice

Given a raw DE55, look at five tags before anything else. Paste the whole string into the TLV parser, then read: 9F27 (what the chip recommended), 9F26 (the cryptogram backing it), 95 (what the terminal saw go wrong), 9F34 (how the cardholder was verified), 9F36 (the counter, for cloning checks). Those five answer "what happened and does it look legitimate" for most tickets; everything else is supporting detail.

Know which direction a tag travels. Most tags ride the request. Three exist only in the response: 91 (issuer authentication data), 71 and 72 (issuer scripts). If you find them in a request dump, the dump is mislabelled. Conversely 9F5B (script results) shows up in a later request, reporting on scripts delivered earlier — a one-transaction lag that regularly confuses log correlation.

Know which side wrote the value. When a value looks wrong, the tag tells you whom to call. Card-personalisation tags (82, 9F07, 9F08, 5F24, the IACs) can only be fixed by the issuer's card profile. Terminal-configuration tags (9F1A, 9F33, 9F35, 9F40, 9F1C) point at the acquirer or the device estate. A terminal country code of 0000 is a terminal-fleet bug, not a card problem.

Expand templates before counting tags. If a dump starts with 77 or 70, the payload is one level down — a naive scan that treats the template as opaque will report "one tag" and miss everything. Same for 6F/A5/BF0C nesting in selection data. The parser expands these automatically; when walking by hand, apply Rule 3 above and recurse.

Watch for the encoding trap. DE55 is binary TLV inside a message that may otherwise be ASCII or EBCDIC. If tag bytes look shifted by a constant or every second character is 3, the DE55 was re-encoded as text somewhere upstream — fix the extraction, not the parse. The hex viewer helps spot this quickly.

Private and scheme tags: where this table stops

This reference covers tags with public, EMV-book-level definitions (plus the three scheme-assigned ones explicitly flagged above). Beyond it lie the private classes, and the honest answer about them is shorter than any table:

• DF- and FF-prefixed tags are private-class by construction — the tag byte itself says "context-defined". DF60, a common search, is a good example: different kernels, vendors and schemes each assign it their own meaning, and there is no public definition to cite. The only correct reading comes from the spec of the system that produced the message.
• Much of the 9F50–9F7F range is assigned by individual schemes rather than the EMV books. The same tag number can mean different things on different networks — which is why 9F53 and 9F63 carry a "confirm against your scheme" note above rather than a confident one-liner.
• Scheme private layouts (the internal structure of IAD variants, contactless kernel data and the like) are documented in each scheme's own closed specifications. Where this page touches them — the IAD split above — it says so and labels the reading as heuristic.

A tag table that invents meanings for private tags is worse than none: it reads as authoritative exactly where it is guessing. When you hit an unknown DFxx, the productive move is to identify the producing system and ask for its tag dictionary.

Read next

• EMV TLV Parser — paste a full DE55 and get this table applied to it
• EMV Chip & DE55 Deep Dive: ARQC / TVR / CVM
• AIP vs TVR vs TSI: What EMV Tags 82, 95 and 9B Each Record
• EMV Glossary: ARQC, TVR, AIP, CVM & Friends