82

Tag 82 is the card's own statement of what it can do. The terminal receives it in the response to GET PROCESSING OPTIONS — the command that opens the transaction once an application has been selected — and almost every decision that follows is shaped by the two bytes it carries: which offline data authentication method to attempt, whether cardholder verification is on the table, and whether terminal risk management has to run.

Where it shows up trips up more integrations than what it means. In a Format 2 response the card returns template 77 and the AIP arrives properly wrapped as tag 82. In a Format 1 response the card returns template 80, and the AIP is simply the first two bytes of that template's value, followed immediately by the Application File Locator — with no tag 82 present anywhere in the data. A parser that searches for the literal tag finds nothing and reports a missing AIP on a completely conformant card.

Reading it is straightforward once you know that, in contact EMV, all of the meaning lives in byte 1. Bit 7 declares SDA, bit 6 declares DDA and bit 1 declares CDA; bit 5 says cardholder verification is supported; bit 4 tells the terminal that risk management is to be performed; bit 3 announces issuer authentication; bit 2 covers on-device cardholder verification. Byte 2 is reserved.

The important nuance is that the card is declaring capability, not intent. A card whose AIP advertises CDA is not promising that CDA will run — only that it could. The method actually performed is the intersection of what the card offers here and what the terminal supports, which is where most AIP debugging ends up: if you expected dynamic authentication and the transaction quietly performed static authentication instead, decode the AIP first, because the answer is usually that bit 6 is simply off.

The value 3900 is a good one to recognise on sight: DDA and CDA supported, cardholder verification supported, and terminal risk management to be performed. One caveat worth carrying into any decoder you write — byte 2 is RFU for contact EMV, but certain contactless kernels do give its bits meaning, so decoding byte 2 without first establishing the kernel produces confident nonsense.