EMV AID List: Application Identifiers by Scheme

How an AID is built: RID + PIX

An AID is 5 to 16 bytes long and splits into exactly two parts:

• RID (Registered Application Provider Identifier) — always the first 5 bytes (10 hex characters). RIDs are registered and assigned under the ISO/IEC 7816-5 framework, so a given RID belongs to exactly one application provider: A000000003 is Visa, A000000004 is Mastercard, A000000333 is UnionPay.
• PIX (Proprietary Application Identifier Extension) — everything after the RID, up to 11 bytes. The PIX is defined by the scheme itself, and each scheme uses it to tell its own products apart.

Byte by byte, Visa's main application AID A0000000031010 is 7 bytes — A0 00 00 00 03 10 10:

The PIX length varies by scheme: Amex's A00000002501 carries a single PIX byte (01), while UnionPay's A000000333010101 carries three (010101). Reading an unknown AID always works the same way — take the first 10 hex characters to identify the scheme, then look the remainder up in that scheme's product list.

Full AID table, grouped by RID

22 AIDs across 11 RIDs — the well-established set, matching the AID lookup tool entry for entry. Product names are deliberately conservative: schemes add PIX values over time, and the complete authoritative list for any RID is that scheme's own specification.

Three of these deserve a note. The US Common Debit rows (Visa A0000000980840, Mastercard A0000000042203, Discover A0000001524010) exist because the US Durbin Amendment requires every debit card to support at least two unaffiliated networks: the scheme's global AID routes over its own network, while the common AID lets the merchant route to regional debit networks — both on one card is normal in US acquiring, not a misconfiguration. And UnionPay's electronic cash application (A000000333010106) is offline low-value payment whose balance lives in the chip, so those transactions never go online for authorization — worth checking when a purchase appears to have no authorization record.

Where the AID shows up: tags 9F06 and 4F

Two different EMV tags carry an AID, and they answer different questions:

Both can appear inside DE 55 of an ISO 8583 authorization — paste the field's hex into the EMV TLV parser and it splits out each tag, or check any single tag in the EMV tag lookup. The two values do not have to be identical, and a mismatch is usually not corruption — it is partial matching at work, covered next. Tag-by-tag context for everything else in the field is in the EMV tag reference, the field itself in the ISO 8583 field guide.

Partial matching and the ASI: why 9F06 and 4F can differ

A terminal does not need the full AID of every card application it accepts. Each entry in its candidate list can be a prefix of a card AID — just the RID, or even shorter — and each entry carries an ASI (Application Selection Indicator) flag saying whether only an exact match counts, or whether any card application starting with that prefix counts too. This is the application selection mechanism EMV Book 1 defines; the flag is set per entry in the terminal configuration.

With partial matching enabled, a terminal entry of A000000003 matches the card's A0000000031010, A0000000032010 and every other Visa application. In the resulting transaction data, 9F06 holds the terminal's (shorter) entry while 4F holds the card's full AID — seeing them differ is the mechanism working, not an error. Compare the two as prefix-against-full before treating a mismatch as a defect.

The same mechanism explains two classic field complaints:

• "Card inserted, terminal says not supported." Application selection produced an empty candidate list: none of the terminal's configured entries matched (exactly or by prefix) any application on the chip. The transaction dies before any authorization message exists, so there is nothing to find in the ISO 8583 logs — the place to look is the terminal's AID table.
• "Same card works at terminal A but not terminal B." The two terminals carry different AID configurations — different entries, or the same entry with a different ASI setting. The card did not change between the two attempts; the candidate lists it was matched against did.

Multi-AID cards: the selected application decides the path

One chip can host several applications — a card carrying a domestic scheme's application alongside an international one is the classic case, and the US Common Debit pairs in the table above are another. Terminal and card settle on one application through selection (the PSE/PPSE directory plus the priority each application declares), and the AID that wins determines which scheme's system the transaction runs through.

That makes tag 4F the starting point when the same card produces two transactions that were processed differently: pull DE 55 from both and compare the selected AID first. If they differ, the two transactions genuinely ran as two different applications, and everything downstream follows from that. Which application a given terminal ends up selecting, and what routing or pricing follows, is governed by scheme rules and your acquiring agreement — check your counterparty's specification rather than assuming.

👉 The parser decodes DE 55 inside a full ISO 8583 message, AID included. For a single value, the AID lookup tool searches this same table by prefix or scheme name.

Read next

• EMV Chip Data & DE 55: A Deep Dive
• EMV Tag Reference: Every Tag in DE 55
• ISO 8583 Field Quick Reference