AIP Decoder

What the AIP says

The Application Interchange Profile is tag 82, two bytes, and it is the card describing its own application. The card returns it in the response to GET PROCESSING OPTIONS, together with the Application File Locator, so it is one of the first things the terminal learns. Byte 1 covers the contact functions: which offline data authentication methods the card supports, whether cardholder verification is supported, whether terminal risk management is to be performed, and whether the card can authenticate the issuer.

How the terminal uses it

For offline data authentication the terminal takes the strongest method that both sides support: CDA, then DDA, then SDA. The card's side of that is AIP byte 1 b1, b6 and b7, and the terminal's side is byte 3 of Terminal Capabilities. If they have nothing in common, no authentication runs and the terminal sets byte 1 b8 of the TVR.

If b5, cardholder verification, is clear, the terminal skips the CVM List entirely. That is the first thing to check when a card that should ask for a PIN never does.

Values you will see often

3900 is DDA, cardholder verification, terminal risk management and CDA: a current contact chip card. 5800 swaps the dynamic methods for SDA, which marks an older card. 1800 has cardholder verification and terminal risk management and no offline authentication at all, so the card expects to go online every time.

Byte 1 b3, issuer authentication, says the card supports EXTERNAL AUTHENTICATE. A card with it clear can still check the ARPC inside the second GENERATE AC, so a clear bit does not mean the issuer's response goes unverified.

Byte 2 belongs to the kernels

In the contact specification byte 2 is reserved. Contactless kernels assign bits in it, and they do not agree with each other. The readings here for byte 2 are the Mastercard kernel's (EMV Book C-2): b8 for EMV mode and b1 for the relay resistance protocol. Under another kernel, treat a set bit in byte 2 as unresolved until you have that kernel's specification in front of you.

Why issuers care about the exact value

The AIP is in the data set EMV Book 2 recommends for the application cryptogram. An issuer host that validates an ARQC with a different AIP from the one the card used gets a cryptogram failure, and the cause is a profile mismatch, not a bad key. When ARQC validation fails for one card product only, compare the AIP in DE 55 with the one in the issuer's card profile.