EMV PIN Block Format Guide

When you enter a PIN at a payment terminal, the PIN doesn't travel over the network in plain text. Instead, it's encoded into a PIN block, encrypted with a symmetric key (DES, 3DES, or AES), and sent to the issuing bank for online verification. This guide explains every PIN block format used in EMV and payment systems.

Why PIN blocks matter: The PIN block format determines how the PIN is combined with other data (account number, random padding) before encryption. The format must be agreed upon by the PIN pad (terminal), the acquiring HSM, and the issuing HSM — any mismatch causes online PIN verification to fail.

1. Overview of PIN Block Formats

FormatStandardPIN PositionFillKey TypeUsage
Format 0ISO 9564 / ANSI X9.8LeftPAN-derived3DES / AESMost common worldwide
Format 1ISO 9564LeftRandom3DES / AESATMs, some terminals
Format 3ISO 9564 / DUKPTLeftDUKPT-derivedDES/3DES (DUKPT)US retail, DUKPT terminals
IBM 3624IBM proprietaryRightLeft-filled zeros3DESLegacy IBM HSMs

2. ISO Format 0 (ANSI X9.8) — The Standard

Format 0 is the most widely used PIN block format globally. It XORs the PIN field with a PAN-derived field to prevent identical PINs on different cards from producing the same ciphertext.

Step 1: Construct the PIN Field (16 hex digits = 8 bytes)

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|02|PL|P1|P2|P3|P4|F1|F2|F3|F4|F5|F6|F7|F8|F9|FA|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

Example: PIN = 123404 04 01 02 03 04 FF FF FF FF FF FF FF FF FF FF
Wait, let me correct — the fill for Format 0 is 0F repeated, not FF. Actually, the standard fill is each nibble = F.

So PIN 1234 (4 digits): 04 04 01 02 03 04 0F 0F 0F 0F 0F 0F 0F 0F 0F 0F

Step 2: Construct the PAN Field (16 hex digits = 8 bytes)

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|00|00|00|00|A1|A2|A3|A4|A5|A6|A7|A8|A9|AA|AB|AC|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

Example: PAN = 4111111111111111 → rightmost 12 of 411111111111111 (excluding last check digit) = 111111111111 → PAN field: 00 00 00 00 01 11 11 11 11 11 11 00 00 00 00 00

Actually the correct derivation: take the 12 rightmost digits of the PAN excluding the check digit. So for 4111111111111111 (16 digits, last is check), take digits 4–15: 11111111111100 00 00 00 11 11 11 11 11 11 → as hex nibbles: 0000 0000 1111 1111 1111 — no, let me be precise.

PAN derivation rule (Format 0): Remove the check digit (rightmost digit) from the PAN. Take the 12 rightmost digits of the result. Left-pad with zeros to 16 hex nibbles (8 bytes). Each digit becomes one nibble.

Step 3: XOR the Two Fields

PIN block = PIN_field ⊕ PAN_field

Example:

PIN field: 04 04 01 02 03 04 0F 0F 0F 0F 0F 0F 0F 0F 0F 0F
PAN field: 00 00 00 00 11 11 11 11 11 11 00 00 00 00 00 00
PIN block: 04 04 01 02 12 15 1E 1E 1E 1E 0F 0F 0F 0F 0F 0F

Step 4: Encrypt

The 8-byte PIN block is encrypted with the PIN Encryption Key (PEK):

3. ISO Format 1 — Random Fill

Format 1 uses random fill instead of PAN-derived data. It's simpler but requires the recipient to know the format indicator to extract the PIN correctly.

Structure

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|01|PL|P1|P2|P3|P4|R1|R2|R3|R4|R5|R6|R7|R8|R9|RA|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

No PAN field is used. The receiver extracts the PIN based on the length field.

Security consideration: Format 1 doesn't bind the PIN to the card number. If the same PIN and key are used for two different cards, the ciphertext will be identical (since the random fill doesn't incorporate the PAN). This is why Format 0 is preferred for most deployments.

4. ISO Format 3 — DUKPT Variant

Format 3 is used with DUKPT (Derived Unique Key Per Transaction) key management, common in US retail environments. It's structurally similar to Format 1 but the fill is derived from the DUKPT process.

Structure

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|03|PL|P1|P2|P3|P4|D1|D2|D3|D4|D5|D6|D7|D8|D9|DA|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
DUKPT advantage: Each transaction uses a unique derived key, so even if one key is compromised, past and future transactions remain secure. This is required for PCI PTS-certified PIN pads in the US.

5. IBM 3624 Format

The IBM 3624 format is a legacy format still found in some banking HSMs. Unlike ISO formats, the PIN starts from the right side of the block.

Structure

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|00|00|00|00|00|00|00|00|00|00|00|P1|P2|P3|P4|PL|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

Example: PIN 123400 00 00 00 00 00 00 00 00 00 00 01 02 03 04 04

IBM 3624 PAN treatment: When used with IBM 3624, the PAN may or may not be XORed depending on the HSM command variant (e.g., Thales HSM EE command). Always check the HSM documentation.

6. PIN Block Encryption Keys

Key TypeAlgorithmUsageKey Management
PEK (PIN Encryption Key)3DES EDE / AESEncrypts the PIN block for transmissionShared between terminal acquirer and issuer HSM
BDK (Base Derivation Key)3DES / AESMaster key for DUKPT key derivationStored in HSM; injected into PIN pads
KSI (Key Serial ID)Identifies the DUKPT device and counterEmbedded in the encrypted PIN block header
TPK/ZPK3DESZone PIN Key — used between acquirer and issuerExchanged via key management messages (0800/0810)

7. Online PIN Verification Flow

1. Cardholder enters PIN at terminal
2. Terminal constructs PIN block (Format 0/1/3)
3. Terminal encrypts PIN block with PEK (or DUKPT-derived key)
4. Terminal sends encrypted PIN block in EMV ARQC/ARPC or ISO 8583 field 52
5. Acquirer HSM decrypts PIN block
6. Acquirer re-encrypts PIN with ZPK (Zone PIN Key) for issuer
7. Issuer HSM decrypts, extracts PIN, compares with stored PIN offset (IBM 3624) or PVV (PIN Verification Value)
8. Issuer returns approval/decline (ISO 8583 field 39)
EMV offline PIN vs online PIN: EMV supports offline PIN (verified by the card's ICC chip, no PIN block transmitted) and online PIN (PIN block encrypted and sent to the issuer). The terminal decides based on the card's PIN Try Counter, CVM list, and issuer script results.

8. Code Examples

8.1 Format 0 PIN Block Construction (Python)

def construct_format0_pin_block(pin: str, pan: str) -> bytes:
    """Construct ISO Format 0 PIN block."""
    # Step 1: PIN field
    pin_len = len(pin)
    pin_field = bytes([(0x00 | pin_len)])  # format=0, length
    pin_field += bytes([int(d) for d in pin])  # PIN digits
    pin_field += b'\x0f' * (16 - 2 - pin_len)  # pad with 0F
    # pad to 8 bytes (16 nibbles)
    pin_hex = (0x00 | pin_len).to_bytes(1, 'big')
    for d in pin:
        pin_hex += int(d).to_bytes(1, 'big')
    # Better approach: construct as hex string
    pin_str = f"0{pin_len}" + pin + "F" * (16 - 1 - 1 - pin_len)
    # Actually let's be precise:
    pin_field_hex = "04" + pin + "F" * (16 - 2 - len(pin))
    # Step 2: PAN field
    pan_digits = pan[:-1]  # exclude check digit
    pan_right12 = pan_digits[-12:].zfill(12)
    pan_field_hex = "0000" + pan_right12
    # Step 3: XOR
    pin_int = int(pin_field_hex, 16)
    pan_int = int(pan_field_hex, 16)
    block_int = pin_int ^ pan_int
    return block_int.to_bytes(8, 'big')

# Example
block = construct_format0_pin_block("1234", "4111111111111111")
print(block.hex())  # prints the 16-hex-digit PIN block

8.2 Format 1 PIN Block (Python)

import os

def construct_format1_pin_block(pin: str) -> bytes:
    """Construct ISO Format 1 PIN block (random fill)."""
    pin_len = len(pin)
    hex_str = "01" + f"{pin_len:01X}" + pin
    # Fill remaining with random hex digits
    remaining = 16 - len(hex_str)
    for _ in range(remaining):
        hex_str += format(os.urandom(1)[0] % 16, 'X')
    block_int = int(hex_str, 16)
    return block_int.to_bytes(8, 'big')

block = construct_format1_pin_block("1234")
print(block.hex())

9. Common Issues & Debugging

ProblemLikely CauseFix
"PIN block format error" from HSMFormat mismatch between terminal and HSMVerify terminal sends the format the HSM expects
Online PIN always declinedPAN derivation wrong (wrong 12 digits)Check if check digit is excluded, rightmost 12
Same ciphertext for different cards with same PINUsing Format 1 instead of Format 0Switch to Format 0 which XORs with PAN
DUKPT key exhaustionCounter reached end of key range (~1M)Re-key the terminal with new BDK
3DES decrypt failsKey parity wrong or key variant incorrectCheck key check value (KCV) with HSM
PCI compliance: Never log, store, or transmit unencrypted PIN blocks. Even in test environments, use designated test PINs and test keys. Production keys must be managed exclusively inside PCI HSM-certified hardware.

10. Summary

Quick reference: