AIP Decoder
Decode the Application Interchange Profile (EMV tag 82) 2-byte value to show which EMV functions are supported by the card.
Byte 1 is common across all EMV kernels (Book 3). Byte 2 bit 8 is kernel-specific: on Visa (K3) / Mastercard (K2) it indicates contactless mag-stripe (MSD) support; Kernel 8 uses Card Capabilities Information (9F810D) for interface/CVM capabilities instead.
What the Application Interchange Profile (82) declares
The Application Interchange Profile (AIP), EMV tag 82, is a 2-byte bitmap in which the card declares which EMV functions it supports for the selected application. The terminal reads it immediately after GET PROCESSING OPTIONS and uses it to plan the rest of the transaction — there is no point attempting dynamic data authentication, for example, if the card's AIP says it is not supported.
The flags that matter
Byte 1 carries the meaningful capabilities: SDA (static data authentication), DDA (dynamic data authentication), "Cardholder verification is supported", "Terminal risk management is to be performed", "Issuer authentication is supported", and CDA (combined DDA/application cryptogram generation). Byte 2 is mostly reserved, though some contactless kernels use it for EMV-mode and relay-resistance indicators. The combination of SDA/DDA/CDA bits tells you which offline authentication method the card and terminal will negotiate, which is the single most common reason a chip transaction behaves differently from another.
Common questions
SDA and DDA are both clear — how does the card authenticate?
It does not authenticate offline. The terminal must rely on going online for that transaction, and an offline-only terminal will typically decline.
Where does the AIP come from in a trace?
It is returned in the GPO response, either directly (tag 82) or inside the response message template, together with the AFL.
Bit definitions follow EMV Book 3. Decoding runs entirely in your browser.