PIN Blocks Explained: ISO 9564 Formats 0 to 4

💡 TL;DR (Too Long; Didn't Read)

PIN blocks in 90 seconds:

• A PIN is never sent as bare digits. It is packed into a 64-bit (or 128-bit) PIN block, then encrypted. The packing rules are ISO 9564, and there are five formats.
• Format 0 builds a PIN field and a PAN field and XORs them — binding the encrypted PIN to the account so the same PIN under two PANs produces different ciphertext.
• Format 1 carries no PAN (uses a transaction/random fill) for when the PAN is unavailable; Format 2 is for offline smartcard verification; Format 3 hardens Format 0's padding with random fill.
• Format 4 is the modern one: a 128-bit, AES-based block with a random fill and a separate PAN block, designed for AES key hierarchies.
• As always in this series: PIN-block crypto runs where the key lives — the PIN pad, the HSM — never with a production key on someone else's server.

When you type a PIN, four digits, the last thing that should happen is those four digits travelling anywhere as themselves. Instead they are packed into a fixed-size PIN block, bound to the account, padded, and encrypted under a key that lives in tamper-resistant hardware. The packing — how the digits, the padding, and the account number are arranged into a block before encryption — is standardized by ISO 9564, and the format you use determines the block's security properties. This article walks the formats, spends real time on Format 0 because it teaches the whole idea, and explains why Format 4 had to exist. It follows ISO 9564-1/-3; I cite the structure, not the spec text. And the discipline from the ARQC article holds here too: I show the construction, not a fabricated ciphertext, and every key-bearing step runs where the key already is.

Why not just encrypt the PIN?

Start with the naive design and watch it fail. If you simply encrypted the four PIN digits under a fixed key, two problems appear immediately. First, the block is tiny and low-entropy — four digits is ten thousand possibilities — so patterns leak and dictionary attacks are cheap. Second, and worse, the same PIN always produces the same ciphertext under the same key, so an attacker who sees many encrypted PINs can cluster them, and a PIN captured for one card can be replayed for another with the same PIN. The PIN block format exists to kill both problems: pad the PIN to a full block for size and structure, and bind it to the PAN so the same PIN on different accounts encrypts differently.

Format 0, byte by byte

Format 0 (also called ISO-0, historically ANSI X9.8) is the one to learn cold, because every other format is a variation on its ideas. It builds two 8-byte fields and XORs them.

The PIN field. Sixteen nibbles (8 bytes):

[ 0 ][ L ][ P P P P (P..) ][ F F F ... ]
  │    │     │                │
  │    │     │                └─ 'F' padding to fill 16 nibbles
  │    │     └─ the PIN digits (4-12 of them)
  │    └─ L = PIN length (one nibble, e.g. 4 for a 4-digit PIN)
  └─ control field = 0 (indicates Format 0)

So a 4-digit PIN 1234 becomes the nibbles 0 4 1 2 3 4 F F F F F F F F F F — control 0, length 4, the digits, then F padding.

The PAN field. Also 16 nibbles: four 0 nibbles followed by the rightmost 12 digits of the PAN excluding the check digit:

[ 0 0 0 0 ][ 12 rightmost PAN digits (minus check digit) ]

The block. XOR the PIN field with the PAN field, byte for byte. The result is the clear PIN block; it is then encrypted (historically 3DES) under the PIN encryption key. The XOR is the whole trick: because the PAN is mixed in before encryption, the same PIN on two different accounts yields two different clear blocks and therefore two different ciphertexts, and an attacker cannot lift a PIN block from one card and use it on another. Decryption reverses it: decrypt, XOR the PAN field back out, read the length nibble, extract that many PIN digits.

Notice what the PAN field does not include: the leftmost digits and the check digit. Using the rightmost twelve (minus check) is a deliberate ISO choice so that the account binding is stable and unambiguous. Get that selection wrong — include the check digit, or take the leftmost digits — and your PIN block will be structurally valid and verify nowhere, the same silent-failure signature we keep meeting in payment crypto.

What Formats 1, 2, and 3 change

The other classic formats are Format 0 with one design decision altered.

Format 1 removes the PAN. Some contexts do not have the PAN available at PIN-encryption time, so Format 1 fills the non-PIN nibbles with a transaction number or random data instead of XORing a PAN field. It gets uniqueness from the random/transaction fill rather than from account binding — weaker in that it does not tie the PIN to the account, so it is used only where the PAN genuinely is not available.

Format 2 is for offline verification inside a smartcard — when the PIN is checked by the chip itself rather than sent online. It uses F padding and no PAN XOR, because the block never leaves the card-and-reader boundary and the account binding is implicit. This is the format behind offline PIN in the CVM flow.

Format 3 is Format 0 with random padding. Where Format 0 pads the PIN field with fixed F nibbles, Format 3 pads with random nibbles in the A–F range, adding entropy to the block so that identical PINs under identical PANs still vary. It is a hardening of Format 0's most predictable region.

Format 4: the AES era

Formats 0 through 3 are built around 8-byte (64-bit) blocks and the 3DES world. As the industry migrates to AES, the block size changed, and Format 4 is the answer: a 128-bit PIN block designed for AES.

Format 4 keeps the good idea — bind to the PAN, add entropy — but scales it up. The PIN block is 16 bytes: a control nibble marking Format 4, the PIN length, the PIN digits, and a random fill for the remaining space, giving every block strong entropy. The PAN is handled in a separate 16-byte PAN block, and the construction combines them through AES operations rather than a single XOR-then-3DES. The result is a PIN block sized and structured for modern key hierarchies, without the 64-bit block-size ceiling. If you are building new PIN handling, you are building Format 4; the earlier formats are what you interoperate with, not what you choose.

The rule that governs all of this

Everything above describes construction, and construction is safe to learn and to run in a browser with test keys. What is never safe is doing it with a real key on infrastructure you do not control. A production PIN encryption key lives in a PIN pad's secure processor or an HSM, and the clear PIN block exists only for microseconds inside that boundary before it is encrypted; it is never assembled in application memory on a general-purpose server, and it is never sent to a third party for "processing." When gsstk builds a PIN-block tool, it runs client-side with test keys that never leave your browser — because a payments tool that asks for a real PIN key is not a tool, it is a liability. The deterministic construction, checked against known test vectors, is the source of truth; an AI explanation sits on top of it, never underneath.

Battle scars

The PAN field is the rightmost 12 digits minus the check digit. Not the whole PAN, not including the check digit, not the leftmost digits. This is the most common Format 0 implementation bug and it produces PIN blocks that are perfectly well-formed and verify nowhere.

Format mismatch is a silent decline. If the terminal builds a Format 0 block and the issuer's HSM expects Format 4 (or vice versa), the decryption yields garbage and the PIN "fails" with no useful diagnostic. During an AES migration, format negotiation is exactly where things break; pin down (so to speak) which format each hop expects.

Clear PIN blocks must not live in logs or memory dumps. The whole point of the format is that the PIN is only ever clear inside secure hardware. A debug build that assembles the block in application memory, or a log line that dumps it "just to see," reintroduces precisely the exposure the design eliminates. Treat the clear PIN block like the PIN itself.

Where this fits

PIN blocks are the cardholder-verification path the CVM List selects when it chooses online or offline PIN, and they travel in the ISO 8583 message as DE 52. They share their key-management world with DUKPT, which is how the PIN encryption key gets uniquely derived per transaction in the first place.

Related Reading on gsstk

• DUKPT from Scratch: Derived Unique Keys per Transaction — how the key that encrypts this block is derived.
• The CVM List (8E): How a Card Chooses PIN vs Signature vs Nothing — when a PIN is demanded at all.
• ARQC from Scratch: Application Cryptograms Without the Black Box — the same client-side-key discipline, applied to cryptograms.

Tools: the EMV Tag Dictionary covers the transport tags; PIN blocks ride as DE 52 in the ISO 8583 Parser. (A client-side PIN Block Formatter is on the roadmap.)

Filed under: Payment Crypto · Payments · EMV · Acquiring · Card Issuing

This article was human-architected and synthesized with AI assistance under the Athena (AI) persona.