AID Selection & Priority
The Application Identifier (AID) tells a terminal which payment application resides on the chip. Most dual-scheme cards carry multiple AIDs; the terminal selects the mutual candidate with the highest priority number (lowest byte value). Standard AIDs used in production programmes include:
A0000000031010— Visa Credit (VSDC)A0000000032010— Visa Debit (VSDC)A0000000033010— Visa ElectronA0000000041010— Mastercard Credit (M/Chip)A0000000043060— Mastercard MaestroA0000002281010— mada (Saudi Arabia domestic)
Priority bytes in the Application Priority Indicator (tag 87) must be
assigned carefully. Domestic scheme AIDs are typically given priority 1 within their
home market, with international AIDs at priority 2, ensuring local scheme routing where
mandated by the central bank.
AFL (Application File Locator) Construction
The Application File Locator (tag 94) tells the terminal exactly where to
find each data object on the card — which Short File Identifier (SFI 1–10) and which
record number. AFL entries also flag which records must be included in the offline
authentication hash (signed static or dynamic data). A typical AFL for a Visa Credit
profile might read:
SFI 2, Records 1–3 (signed) | SFI 3, Records 1–2 (unsigned) | SFI 4, Records 1–1 (unsigned)
Record distribution must account for mandatory data objects (PAN, Track 2 Equivalent, Application Expiry Date, CVR, IAC) as well as optional objects (Issuer URL, PDOL parameters). Over-packing SFI 1 record 1 creates interoperability issues on older terminals with small APDU buffer limits.
CVM List Design
The Cardholder Verification Method (CVM) List (tag 8E) is an ordered
sequence of CVM rules. Each rule contains an X amount, a Y amount, a CVM code and a
condition code. The terminal attempts each rule in order, stopping at the first
successful one. Amounts are expressed in the card's minor currency unit (e.g., for USD
amounts are in cents). A production CVM list for a contactless-enabled credit card
typically follows this order:
- Enciphered PIN verified online — if terminal supports online PIN and transaction exceeds contactless CVM Required Limit
- Enciphered PIN verified offline — for contact chip transactions below the UCOL floor (if offline PIN is in scope)
- Signature — fallback for terminals that do not support PIN
- No CVM required — for contactless tap-and-go below the CVM Required Limit
X and Y amounts serve as transaction value thresholds used with specific condition codes
(e.g., "if unattended terminal", "if supported by terminal"). Setting them to zero with
condition code 03 (always) creates an unconditional rule. Incorrect CVM
list design is the most common cause of failed scheme certification test cases.
Issuer Action Codes (IAC)
The three IAC objects — IAC-Denial (9F0E), IAC-Online (9F0D)
and IAC-Default (9F0F) — are 5-byte bitmasks that map directly onto the
Terminal Verification Results (TVR). They instruct the card how to behave when specific
risk conditions are flagged during offline processing. The table below shows representative
flag settings for a standard credit card profile:
| TVR Flag | Byte.Bit | IAC-Denial | IAC-Online | IAC-Default | Meaning |
|---|---|---|---|---|---|
| Offline data auth not performed | 1.7 | 0 | 1 | 1 | Go online; approve offline if unavailable |
| SDA failed | 1.6 | 1 | 0 | 0 | Deny — card authentication has failed |
| ICC data missing | 1.5 | 1 | 0 | 0 | Deny — malformed chip data |
| Card appears on terminal exception list | 1.4 | 1 | 0 | 0 | Deny — terminal hot-card file match |
| DDA failed | 1.3 | 1 | 0 | 0 | Deny — dynamic auth signature invalid |
| Cardholder verification failed | 2.7 | 0 | 1 | 1 | Go online; approve if comms unavailable |
| Unrecognised CVM | 2.6 | 0 | 1 | 0 | Go online; decline if unable |
| PIN try limit exceeded | 2.5 | 1 | 0 | 0 | Deny — card is PIN-blocked |
| Expired application | 2.4 | 1 | 0 | 0 | Deny — card past expiry date |
| Upper offline transaction limit exceeded | 3.7 | 0 | 1 | 1 | Go online; approve if unable |
| Lower offline transaction limit exceeded | 3.6 | 0 | 1 | 0 | Go online; decline if unable |
| Transaction selected randomly for online processing | 3.5 | 0 | 1 | 1 | Go online; approve offline if unavailable |
| Merchant forced transaction online | 3.4 | 0 | 1 | 1 | Go online; approve if unable |
| New card | 4.7 | 0 | 1 | 0 | Go online; decline if unable |
| Issuer authentication failed | 4.6 | 0 | 0 | 1 | Approve offline (ARPC verification failed but proceed) |
| Script processing failed before final Generate AC | 5.6 | 0 | 0 | 1 | Approve offline; log for post-processing |
Card Risk Management (CRM) Thresholds
CRM thresholds govern when the chip mandates an online authorisation based on cumulative offline spending. Four parameters work in concert:
- LCOL (Lower Consecutive Offline Limit) — transaction count below which the card may remain offline without a forced online check. Typical value: 3.
- UCOL (Upper Consecutive Offline Limit) — transaction count at which the card must go online or decline offline. Typical value: 6.
- LCOA (Lower Consecutive Offline Amount) — cumulative offline amount in minor currency units below which offline approval is permitted. Typical value: USD 5000 (500000 in cents).
- UCOA (Upper Consecutive Offline Amount) — cumulative offline ceiling; breaching this forces an online transaction or decline. Typical value: USD 10000 (1000000 in cents).
Offline Data Authentication: SDA, DDA and CDA
EMV defines three mechanisms for offline card authentication, each with a different security/performance trade-off:
- SDA (Static Data Authentication) — The issuer signs a static data record with its RSA private key; the terminal verifies with the issuer public key certificate stored on the card. Fast, but vulnerable to pre-play attacks because the signed data never changes. Use only for low-risk, low-value portfolios or markets where terminal capability prevents DDA.
- DDA (Dynamic Data Authentication) — The chip generates a unique dynamic signature per transaction using its own ICC private key. Eliminates pre-play risk. Preferred for mainstream credit/debit products. Requires the terminal to perform a GET CHALLENGE command and one additional RSA operation, adding ~150 ms to contact transaction time.
- CDA (Combined DDA/Application Cryptogram Generation) — Merges DDA and the ARQC/TC/AAC generation into a single RSA operation on the Generate AC command. Provides the highest security — the terminal cannot separate authentication from the transaction cryptogram, preventing attacks where a tampered terminal accepts a valid DDA signature while recording a different transaction. Recommended for all new credit and debit programmes where the card OS supports it.
- fDDA (fast Dynamic Data Authentication) — A contactless-optimised variant of DDA that removes the GET CHALLENGE command, reducing the RF field exposure time required for offline authentication. fDDA is now the dominant contactless ODA method across APAC and GCC deployments running Visa payWave and Mastercard Contactless kernels. Issuers targeting contactless-heavy markets (mada, KNET, BENEFIT, MyDebit) should configure fDDA as the primary contactless ODA method.
Contactless Profile Parameters
Contactless (NFC) transactions use a stripped-down kernel profile (Visa payWave / Mastercard Contactless). Key parameters that must be defined in the chip profile:
- CTL Transaction Limit (Reader Contactless Transaction Limit) — Maximum transaction amount eligible for contactless processing. Above this, the terminal forces a contact chip transaction. Configured both on-card and on-terminal; the lower of the two applies. Typical value: USD 250 / GBP 100 / EUR 50 (market-dependent).
- CVM Required Limit — Transactions below this amount may proceed contactless with no CVM (tap-and-go). Above this, the terminal must obtain CVM (typically online PIN for contactless). Typical value: USD 100 / GBP 45 / EUR 50.
- Floor Limit — Transactions below this value can be approved offline without an ARQC. Must align with the scheme-mandated floor (often zero for contactless, meaning all contactless transactions must be online).
- Zero Amount Tap Enable Flag — Enables contactless transit use-cases (open-loop transport) where the initial tap carries a zero amount and the fare is debited at exit. Must be explicitly enabled in the kernel configuration.
Dual-Interface Harmonisation
Dual-interface cards carry separate EMV personalisation records for contact (ISO 7816) and contactless (ISO 14443) interfaces. A common error is personalising different CVM lists, AIDs or CRM thresholds to each interface, creating inconsistent cardholder experiences and certification failures. FinPay Consultants applies a harmonisation framework that maps every tag value across both interface profiles and flags mismatches before the first personalisation run — avoiding costly reprints and scheme re-test cycles.
Domestic Scheme Coexistence
Many markets mandate that cards issued domestically carry both an international scheme AID and a local domestic scheme AID. Key domestic schemes our consultants have implemented:
- mada (Saudi Arabia) — Operated by SAMA; AID
A0000002281010. Mandatory on all POS-capable debit cards issued in KSA. Specific contactless limits and MasterKey PIN management requirements. - KNET (Kuwait) — Operated by KNET/KIPCO; mandatory on all debit cards issued in Kuwait. Requires parallel Perso file with KNET-specific key sets and CVK derivation.
- BENEFIT (Bahrain) — GCC interbank network; dual AID with BENEFIT-specific CVR/IAC parameters and Bahrain Central Bank contactless thresholds.
- MyDebit (Malaysia) — Operated by PayNet; AID
A0000008780001. Mandatory on Debit Mastercard and Visa Debit cards issued in Malaysia. Full EMV chip and contactless support required from 2023 onwards.