Papa Carder
Professional
- Messages
- 356
- Reaction score
- 277
- Points
- 63
AAC (Application Authentication Cryptogram) and ARQC (Authorization Request Cryptogram) are both types of Application Cryptograms (ACs) in EMV systems, serving as Message Authentication Codes (MACs) to ensure transaction integrity and authenticity. They are generated by the chip card using similar cryptographic processes (e.g., 3DES or AES with a session key SK_AC derived from the master key MK_AC and ATC), but differ significantly in purpose, timing, and usage. ARQC is proactive for seeking approval, while AAC is reactive for indicating rejection. Below is a detailed comparison:
For full technical details, refer to EMVCo specifications (Books 2 and 3).
| Aspect | ARQC (Authorization Request Cryptogram) | AAC (Application Authentication Cryptogram) |
|---|---|---|
| Purpose | Requests online authorization from the issuer; authenticates the card and transaction data for real-time approval. | Indicates offline or final decline of the transaction; confirms the card's rejection decision without further processing. |
| When Generated | When the card/terminal decides online processing is needed (e.g., high-value transaction, exceeded offline limits); typically in the first GENERATE AC command. | When the transaction is declined (e.g., risk flags in TVR, failed ARPC verification, insufficient funds offline); can be in first (offline) or second GENERATE AC (after online failure). |
| Scenario | Online authorization required; card requests issuer validation via ARQC sent to the terminal/issuer. | Offline decline or online rejection (e.g., invalid ARPC); no further authorization attempt; transaction ends. |
| Data Used | Based on CDOL1 (e.g., amount, currency, UN, TVR); focuses on request elements for issuer review. | Based on CDOL1/CDOL2 (may include ARPC/ARC for online declines); includes decline reasons in risk data. |
| Cryptogram Type Indicator (9F27) | 0x80 (indicates online request). | 0x00 (indicates decline). |
| Next Steps | Sent to issuer for validation; if approved, leads to ARPC and potential TC. | Transaction declined; logged for reporting, no settlement; may trigger card updates (e.g., counters). |
| Security Role | Authenticates card to issuer; enables real-time fraud checks. | Authenticates decline to terminal/issuer; prevents forced approvals. |
| Common Triggers | High-value transactions, random selection, or exceeded offline counters. | Failed CVM (e.g., PIN), risk flags (TVR), invalid ARPC, or issuer decline. |
Additional Notes on Similarities
- Generation Method: Both are 8-byte MACs computed using SK_AC over padded CDOL data (3DES CBC mode), ensuring uniqueness via ATC.
- Verification: Issuer can recompute AAC/ARQC post-transaction for fraud detection, but ARQC is verified real-time, while AAC is more for logging.
- Contactless Context: Identical differences apply in NFC (ISO 14443) modes, with ARQC more common in online-heavy regions like the U.S.
For full technical details, refer to EMVCo specifications (Books 2 and 3).