ISO 8583 Parser
Free · Decoder · Updated 2026-08-09
online lookup

EMV AIP (Tag 82) Application Interchange Profile Decoder

The AIP is the card's capability announcement, returned in GET PROCESSING OPTIONS before anything else happens: which flavours of offline authentication it supports, whether cardholder verification is on the menu, whether the terminal must run risk management. Two bytes that shape the whole transaction.

Examples:

Bit by bit

Byte 1 carries everything: b7 SDA supported, b6 DDA supported, b1 CDA supported — the three flavours of offline data authentication, oldest to strongest. b5 says the card supports cardholder verification at all; b4 tells the terminal it must run terminal risk management even where it might otherwise skip it; b3 says the card supports issuer authentication (verifying the ARPC that comes back with an online response). Byte 2 is reserved in the contact spec — the contactless kernels reuse its b8 to announce mag-stripe (MSD) mode, so seeing 80 there on contactless data is normal.

How the terminal uses it

During application processing the terminal intersects the AIP with its own capabilities and picks the strongest offline authentication both sides support: CDA over DDA over SDA. No overlap at all sets “offline data authentication was not performed” in TVR byte 1 — on an offline-capable terminal that pushes the transaction online, and on an offline-only terminal it usually kills it.

The cardholder-verification bit gates the whole CVM chapter: b5 clear means the terminal never opens the CVM List, TSI b7 stays 0, and no PIN is ever prompted. The terminal-risk-management bit works the other way — it is the card demanding floor-limit and velocity checks even in environments that would happily skip them.

Reading it in the field

An SDA-only profile (b7 set, b6 and b1 clear) marks an old or minimally personalised card: static signatures can be copied, which is why schemes have been sunsetting SDA-only approval for years — expect these cards to be forced online. “Why was there no PIN prompt” sometimes ends here too: if b5 is clear, no terminal anywhere will ask, whatever its configuration. And if issuer authentication keeps showing “not performed” in the TSI, check b3 before blaming the terminal: a card that doesn't announce it never gets it.

Supported is not performed. The AIP says what the card can do; the TSI says what actually ran; the TVR says what failed. DDA announced here plus “offline data authentication was not performed” in the TVR is not a contradiction — it usually just means the terminal lacked the CA public key for this card's scheme.