Payment Crypto Network Glossary

A 3DES or AES key shared between two HSMs (e.g. acquirer and network) used solely to encrypt other working keys during key exchange. Never used directly for data. Also called a Zone Control Master Key (ZCMK) or interchange KEK.

A working key shared between two adjacent nodes (acquirer ↔ scheme switch, switch ↔ issuer), exchanged under ZMK protection, used to encrypt PIN blocks in transit. Each hop’s HSM translates the PIN block from the inbound ZPK to the outbound ZPK, so each ZPK is unique per bilateral link.

A working key used to generate or verify MACs on ISO 8583 messages between network participants. Ensures message integrity across zone boundaries.

A working key used for encrypting sensitive data fields (other than PIN) as they travel between network zones. Analogous to ZPK but for general data.

A TDES (or AES) key loaded into a POS terminal or ATM (by key injection, a key ceremony or TR-34 remote key loading) that is used to protect the exchange of working keys between the terminal and its acquirer host.

A working key loaded under TMK protection into a PIN entry device. Used to encrypt the cardholder PIN block (ISO 9564 Format 0, 1 or 3 under TDES; Format 4 needs an AES key) before transmission.

A working key loaded under TMK protection into a terminal and used to compute MACs on ISO 8583 messages sent to the acquirer host. Ensures request/response integrity.

A generic term for any key whose sole purpose is to encrypt (wrap) another key. ZMK and TMK are both KEKs in context. TR-31 uses the Key Block Protection Key (KBPK) as its KEK.

The KEK that protects a TR-31 / ANSI X9.143 key block. In key block versions B and D the Key Block Encryption Key (KBEK) and Key Block Authentication Key (KBAK) are derived from it with a CMAC-based KDF; version A (deprecated) and version C used key variants instead.

A 3DES or AES master key held by the issuer HSM used to derive card-specific Unique Derived Keys (UDK). The IMK never leaves the HSM. Each transaction application (AC, SM, DN) uses a separate IMK.

A per-card key (the ICC Master Key) derived from the Issuer Master Key (IMK) using the PAN and PAN Sequence Number via EMV Option A (PAN up to 16 digits) or Option B (longer PANs). Stored on the chip; the issuer HSM re-derives it from the IMK on demand instead of storing it.

A cryptogram generated by the card chip during a transaction over transaction data (amount, unpredictable number, ATC, etc.), computed with the card’s UDK — directly for Visa CVN 10 (per-card key, no session key), or via a session key derived from the UDK with the ATC for Visa CVN 18/22 and Mastercard M/Chip. The issuer verifies it during online authorization to prove the card is genuine.

A cryptogram generated by the issuer HSM in response to an ARQC. The card verifies ARPC to confirm the issuer is genuine (mutual authentication). Calculated with EMV ARPC Method 1 (e.g. Visa CVN 10) or Method 2 (e.g. Visa CVN 18) depending on card config.

The cryptogram a card returns when it approves: either an offline approval at the first GENERATE AC or after an online approval at the second GENERATE AC. Sent in clearing as evidence of the approved transaction. Uses the same key derivation as ARQC.

Cryptogram generated by the card when it declines: offline at the first GENERATE AC, or at the second GENERATE AC after an online decline or failed issuer contact. Proves the card chip made the decline decision, not a rogue terminal.

A double-length DES key (CVK-A and CVK-B halves) used to generate and verify CVV/CVC values: CVV1 on the magnetic stripe, iCVV in the chip’s Track 2 Equivalent Data, and the printed CVV2. Stored in the issuer HSM.

A 3DES key used to compute and verify the PIN Verification Value (PVV). The issuer stores the PVV on the card or in a database; at authorization the HSM recomputes it from the PVK and PAN to verify the PIN.

The root 3DES or AES key in the DUKPT (ANSI X9.24) scheme. Stored only in the acquirer HSM. Used to derive IPEKs which are injected into terminals — the BDK itself never leaves the HSM.

A terminal-specific key derived from the BDK and the base portion of the KSN. Injected into a PED at manufacture or key injection. The terminal derives all future transaction keys from this IPEK without ever seeing the BDK.

In TDES DUKPT a 10-byte (80-bit) value: the Key Set Identifier (KSI, linking to a BDK), the device ID and a 21-bit transaction counter. AES DUKPT (ANSI X9.24-3) uses a 12-byte KSN: 4-byte BDK ID, 4-byte derivation ID and 4-byte counter. Sent in the clear with each transaction so the HSM can rederive the correct future key.

A key management scheme (ANSI X9.24) where each transaction uses a unique encryption key derived from IPEK + KSN. Eliminates the risk of reusing a single terminal key; compromise of the current key does not expose past transaction keys.

A symmetric cipher applying DES three times (encrypt-decrypt-encrypt) with 2 or 3 independent 56-bit keys. NIST SP 800-57 rates 3-key TDES at 112-bit and 2-key TDES at 80-bit security, and SP 800-131A disallowed TDES encryption after 2023 — but it remains common in legacy payment HSMs, which are migrating to AES.

A symmetric block cipher operating on 128-bit blocks with 128, 192, or 256-bit keys. Successor to 3DES in modern HSMs and EMV. Used in DUKPT AES (ANSI X9.24 Part 3) and AES-CMAC for MACs.

An asymmetric cipher used in payment systems for key transport (TR-34), certificate signing (EMV CA keys), and secure communication. TR-34 uses RSA-2048 or larger; EMV CA keys are at most 1984 bits because they must fit EMV’s certificate formats; 1024-bit keys are retired.

An asymmetric signature algorithm based on elliptic curve cryptography. Classic EMV offline authentication (SDA, DDA, CDA) is RSA-only; EMVCo’s newer elliptic-curve options are Extended Data Authentication (XDA) and ECC offline PIN encipherment. Also used in 3DS 2.x (ES256 JWS) and HSM-to-HSM authentication as a compact alternative to RSA.

A short tag appended to a message proving both integrity (not tampered) and authenticity (from the keyed party). Payment MACs use ISO/IEC 9797-1 MAC Algorithm 1 (CBC-MAC) or 3 (the ‘Retail MAC’) with DES/TDES, or CMAC (MAC Algorithm 5) with AES.

A block-cipher MAC (NIST SP 800-38B) usable with AES or TDES; ISO/IEC 9797-1 MAC Algorithm 5. TR-31 / X9.143 key block versions B and D use it both to derive the KBEK/KBAK and to MAC the block, and AES message MACs use it. Provides stronger security properties than the legacy Retail MAC.

A MAC built on a hash function (SHA-256, SHA-512). Used in API authentication, webhook signatures, and the EMV 3DS SDK–ACS secure channel (JWE A128CBC-HS256). Not typically used for PIN or key protection (that domain uses cipher-based MACs).

A family of one-way hash functions. SHA-1 (deprecated for new signatures, yet still used in EMV certificates and offline data authentication), SHA-256, and SHA-512 are used in payment: HMAC computation, certificate fingerprinting, and key derivation functions within EMV and TR-31.

An ASC X9 technical report (TR-31), standardised in 2022 as ANSI X9.143, for exchanging symmetric keys between devices that share a KEK. A key block wraps the key value with a clear-text header (algorithm, usage, mode, exportability) and a MAC over header and key — so the usage attributes cannot be altered without detection.

An ASC X9 technical report (TR-34, current edition 2019) for distributing symmetric keys between a Key Distribution Host (KDH) and a Key Receiving Device (KRD) using RSA. Replaces manual key ceremonies. Uses CMS (PKCS#7) as the token format.

The standard format for public key certificates used to bind an identity to an RSA or ECC public key. Used in TR-34 (to authenticate KDH/KRD) and 3DS 2.x (Directory Server and ACS signing certificates). EMV chip certificates (Issuer and ICC Public Key Certificates) are not X.509: they use EMV’s own compact format (EMV Book 2).

The ecosystem of certificate authorities, registration authorities, certificate revocation lists, and policies governing issuance and trust of X.509 certificates. Visa, Mastercard, and Amex each run scheme-level CAs for EMV.

A tamper-resistant hardware device, typically validated to FIPS 140-3 Level 3 and/or PCI PTS HSM, that generates, stores, and processes cryptographic keys in a physically secure boundary (FIPS 140-2 certificates moved to NIST’s historical list in September 2026). No key ever exits the HSM in the clear.

For DES/TDES keys, the leftmost 3 bytes (6 hex digits) of encrypting an all-zero block with the key (ANSI X9.24-1). For AES keys the common method is the leftmost bytes of an AES-CMAC over an all-zero block; some HSMs still encrypt zeros instead, so confirm which convention both sides use. Used to verify a key was loaded correctly without revealing the key value. Two parties compare KCVs after a key exchange.

A formatted binary block encoding the cardholder PIN and (for Formats 0, 3 and 4) the PAN, before encryption. ISO 9564-1 defines Formats 0–4 (Format 2 is for offline PIN to the chip). Format 0 (ANSI X9.8) is most common; Format 4 is the 16-byte AES format.

A tamper-resistant, PCI PTS-certified hardware device accepting PIN input. PED hardware zeroizes keys on tamper detection. Holds the TPK, or the DUKPT future keys derived from its initial key (the IPEK itself is erased once they are derived).

A monotonically increasing counter stored on the EMV chip, incremented with every transaction attempt. Included in ARQC computation — prevents replay attacks by making each cryptogram unique.

A 4-byte random number generated by the terminal and included in ARQC computation to provide freshness/liveness guarantee. Prevents pre-computed cryptogram attacks.

The root RSA public key for a payment scheme (Visa, Mastercard, Amex). Distributed to terminals via the scheme and used to verify the Issuer Public Key Certificate on each card. Identified by the scheme’s 5-byte RID plus a 1-byte CA Public Key Index (tag 8F).

The simplest EMV authentication method. The card stores static data signed by the issuer (Signed Static Application Data, tag 93); the terminal recovers the Issuer Public Key from its CA-signed certificate and verifies the signature. Vulnerable to cloning (card data can be copied unchanged).

EMV authentication where the card uses its own ICC Private Key to sign dynamic transaction data (including the terminal’s Unpredictable Number). Each signature is unique; prevents card cloning used against SDA.

Combines DDA signature and ARQC generation into a single command (GENERATE AC). The signed data includes the cryptogram itself, proving both card authenticity and transaction binding in one step.

The umbrella term for SDA, DDA and CDA. Lets the terminal cryptographically verify the card without going online to the issuer.

How the cardholder is verified during a transaction: offline PIN, online PIN, signature, on-device (CDCVM), or no CVM. The card’s CVM List (tag 8E) ranks the methods to try.

The chip embedded in an EMV card. "ICC" is used throughout the EMV specs to mean the chip together with its data and keys.

Tag 82 — a 2-byte bitmap returned in the GPO response stating which functions the card supports: SDA, DDA, CDA, cardholder verification, terminal risk management and issuer authentication.

Tag 95 — a 5-byte bitfield in which the terminal records the outcome of every risk and verification check performed during the transaction.

Tag 9B — a 2-byte bitfield indicating which functions the terminal actually performed (offline data authentication, cardholder verification, risk management, issuer authentication, script processing).

Tag 9F10 — issuer- and application-specific data the card returns with the cryptogram. Its layout depends on the CVN (e.g. Visa CVN10/18, Mastercard M/Chip).

The EMV command that begins transaction processing. The card returns the AIP and the AFL (the list of records the terminal must read).

Tag 97 — a card-supplied list naming the data the terminal must concatenate and hash to build the TC Hash used in the Transaction Certificate.

Tag 9F49 — a card-supplied list naming the data the terminal must pass to the card (typically the Unpredictable Number) for Dynamic Data Authentication.

A legacy contactless mode that reproduces magnetic-stripe track data over the contactless interface instead of performing full EMV chip processing. Being phased out.

Visa’s full EMV chip application, used for contact transactions and full-EMV-mode contactless.

Visa’s streamlined contactless profile (Tap to Pay). The card returns everything needed to authorise in a single tap, using fDDA for authentication.

The contactless form of DDA used by Visa qVSDC. The card signs dynamic data (including the terminal’s Unpredictable Number) in one step during the tap.

Tag 9F66 — a 4-byte bitmap the Visa contactless reader places in the PDOL to tell the card what it supports and requires (MSD/qVSDC, online PIN, CVM, and more).

Tag 9F6C — a 2-byte bitmap the card returns to instruct the terminal on its requirements, e.g. online PIN, signature, or the conditions under which to go online.

Cardholder verification performed on the consumer’s own device (phone/watch biometrics or passcode) rather than at the terminal. Used by mobile wallets such as Apple Pay and Google Pay.