The IAD is the card's report back to its own issuer — proprietary by design. This tool splits it byte by byte and, where the shape gives it away, labels the scheme layout: key derivation index, cryptogram version number, and the CVR block that holds the card's own verdict on the transaction.
EMV Book 3 defines tag 9F10 only as data proprietary to the issuer application, up to 32 bytes. The actual layout comes from the scheme's implementation spec — Visa VIS, Mastercard M/Chip — plus the issuer's personalisation choices, and the variant is identified by the CVN carried inside the field itself. There is no universal decode; anything a tool tells you beyond byte boundaries is inference, which is why this page labels its split a guess and shows its detection rule openly: a leading 06 reads as Visa format 0/1/3, a total length of 18, 20 or 26 bytes reads as an M/Chip candidate.
Visa format 0/1/3 — byte 1 is the length indicator 06, then DKI (which issuer master key the card keys derive from), CVN, and a 4-byte CVR whose own first byte 03 is the CVR length. Cards often append a second block: one more length indicator and issuer discretionary data.
Mastercard M/Chip — KDI, CVN, then a 6-byte CVR, followed by DAC or ICC dynamic number and plaintext counters depending on the M/Chip version. UnionPay cards follow a Visa-like structure. If the value fits none of these shapes, that is itself information: some issuers run fully custom profiles, and the per-byte grid is then the only honest reading.
The interesting cargo is the CVR, Card Verification Results: the card-side mirror of the TVR. Where the TVR records what the terminal saw, the CVR records what the card decided — whether the last transaction completed online, offline PIN outcomes and remaining tries, whether issuer authentication passed, how many issuer script commands ran. When you and the issuer disagree about what happened, the CVR is their side of the story.
This tool deliberately does not decode CVR bits. The bit layout depends on the CVN: a VIS CVN 10 CVR and a CVN 18 CVR put different meanings on the same positions, and M/Chip is different again. Decoding with the wrong table produces confident nonsense — read the CVN first, then use the matching scheme table or the issuer's personalisation profile.
The IAD earns its keep in issuer-side disputes: a decline that looks inexplicable from the terminal often carries its explanation here — offline PIN failed before the online attempt, issuer authentication failed on the previous transaction, a script counter that never moved. Quote the DKI and CVN when you raise a case with the issuer; those two bytes tell their crypto team exactly which key set and which algorithm variant to check.