Type a field number or a keyword and you have the entry: name, length type, length, data type, what the field is for, and — where the site has one — a value from a worked message. This is the same dictionary the parser on the home page uses.
126 entries, DE 2 to DE 128. A bare number goes straight to that field; anything else searches names and explanations in both languages.
Showing 126 of 126
Blocked at work? The parser and 13 lookups — DE 39, DE 3, DE 22, MTI, TVR, EMV tags, AIDs, MCC, currency, bitmap, hex viewer, number converter — also come as self-contained HTML files that run from your disk, with no network at all. Offline edition, US$39 one-time. This dictionary page is not one of them.
Cardholder's card number (primary account number).
Variable length up to 19 digits, so the two leading digits are the length and not part of the number. The first six to eight digits are the BIN/IIN the network uses to route the message to the right issuer, and the last digit is a Luhn check digit. This is the field most often masked in logs — under PCI DSS 4.0 the most you may display is the BIN plus the last four digits, and since 2017 a BIN can be eight digits rather than six. Masking for display (4.0 requirement 3.4.1) and rendering unreadable in storage (3.5.1) are two separate requirements.
example4000001234567899Test-range card number (LLVAR, prefix 16), Luhn-valid
Nature of the transaction; first 2 digits = transaction type (00 purchase / 01 cash …).
Six digits read as three pairs: what the transaction is, which account it draws from, which account it credits. Common types are 00 purchase, 01 cash withdrawal, 09 purchase with cashback, 20 refund and 30 balance inquiry; the account pairs use 00 unspecified, 10 savings, 20 cheque and 30 credit. So 003000 is a purchase from a credit account and 011000 a withdrawal from savings. Networks add their own type codes on top of the ISO list, so check your scheme spec before treating an unfamiliar pair as invalid.
example000000Purchase, from the default account — decode any value in the DE3 decoder
Transaction amount, in the currency's minor units (e.g. cents), right-justified with leading zeros, no decimal point.
Twelve digits, zero-padded, in the currency's minor unit with no decimal point — 000000001000 is 10.00 in a two-decimal currency. DE49 is what tells you how many decimals to apply, and ignoring it is a classic factor-of-100 error: the same 1000 is 1,000 yen in JPY, whose minor-unit exponent is 0 — DE4 carries whole yen there, while USD, EUR and SGD carry cents. Take the exponent from DE49 every time rather than assuming two decimals.
example0000000050005000 minor units; with DE49 = 840 (USD, 2 dp) → 50.00 USD
Ten digits MMDDhhmmss, with no year — a message crossing 1 January needs the year inferred from context. The time zone is set by the scheme rather than by ISO 8583: Mastercard requires UTC, Visa permits GMT. It records when the sender transmitted, not when the cardholder transacted, so comparing it against a local timestamp without converting produces date mismatches that look like data errors but are not. In the 1987 layout DE12 and DE13 carry the acquirer's local time and date; from 1993 DE12 becomes twelve digits YYMMDDhhmmss and DE13 is redefined entirely, so check which edition your link runs.
example0810093021MMDDhhmmss, GMT: Aug 10, 09:30:21
System Trace Audit Number: uniquely identifies a transaction within a day; used for reconciliation, lookup, reversal matching.
Six digits assigned by the message originator, unique only within a single day — Mastercard's rule is one UTC day. Six digits is 999,999 values, so they do get reused; treat uniqueness as per-originator-per-day, never as global. Matching a reversal or a repeat therefore needs DE11 together with DE7 and DE32, never DE11 on its own. DE37 is the field designed to stay unique across systems and over time.
example000123Trace number — the key used to match this request to its 0110
In the 1987 layout, six digits hhmmss in the acquirer's local time, which is what decides the transaction's business date for the merchant and for velocity rules. It can differ from DE7 by hours, so a report built on DE7 and a report built on DE12 will legitimately disagree about which day a late-night transaction belongs to. Fix which one your reconciliation uses and state it. From ISO 8583:1993 this field becomes twelve digits YYMMDDhhmmss and is renamed, so a parser built for one edition misreads the other from here on.
Four digits YYMM — year first, the reverse of the MM/YY printed on the card, which is the most common way to get this field wrong. The issuer checks it and answers DE39 = 54 when the card has expired. It is frequently absent on tokenised and stored-credential transactions, where the network holds the real expiry and the token carries its own, so a missing DE14 is not automatically a defect.
example2812YYMM: December 2028 — matches the expiry inside Track 2
Four digits saying what the merchant sells, not what was bought. The acquirer assigns it when the merchant is boarded and it rarely changes afterwards. It drives the interchange rate and most card-product restrictions, so a miscoded merchant shows up as unexpected declines or the wrong fee rather than as any kind of error. Get the cash categories right: 6010 is a manual cash disbursement and 6011 an ATM withdrawal — those are cash, not cash-like. Quasi-cash is 6050 and 6051. 7995 is gambling, which the schemes push toward quasi-cash treatment by other means (Mastercard via DE48 TCC = U). Note also that in 1993-based specifications such as Mastercard's IPM clearing the MCC travels in DE26, not DE18.
POS entry mode: how card data was read — magstripe / chip / contactless / manual.
Three digits in the 1987 layout: the first two say how the card data was read, the third whether the terminal can accept a PIN. 01 is manual key entry, 02 magstripe, 05 chip, 07 contactless chip, 90 magstripe with the full unaltered track and 91 contactless magstripe. It carries liability as much as technique — a chip card read as magstripe is exactly what fraud rules and chargeback reason codes look for. From ISO 8583:1993 the field becomes twelve characters (an-12) split into twelve subfields, with the read method moved to subfield 7; 2003 keeps that definition. So confirm which edition your link runs before parsing — this site's IPM tooling treats DE22 as twelve because IPM clearing is 1993-based.
example90290 = full magstripe read; 2 = no PIN entry capability — see the DE22 decoder
Identifies the acquirer that sent the request: the institution that signed up the merchant, not the merchant (DE42) and not the terminal (DE41). Up to 11 digits, variable length, assigned by the network and usually the acquirer's own BIN. It is the counterparty settlement is calculated against, so it drives routing and interchange. When a third party relays the message, that intermediary appears in DE33 instead.
example424242The ATM owner's institution (LLVAR, prefix 06) — reappears inside DE90 of the reversal
The institution that put this message into the network — which can be the acquirer itself, or a gateway, processor or national switch sitting in front of it. It is not conditional on an intermediary existing: Mastercard makes it mandatory on 0800/0810 network-management messages, where it simply identifies the sender. What it never means is "the institution that signed up the merchant" — that is DE32.
DE 37Retrieval Reference Number (RRN)FIX · 12 · an
Retrieval Reference Number: tracks the same transaction across systems; used for refunds/queries.
Twelve characters assigned by the acquirer and required to stay stable for the whole life of the transaction: the authorisation, the clearing record, the reversal and any chargeback all carry the same value. On Visa it is the documented key for matching messages inside one transaction set and must not be reused for 48 hours, which makes it the practical join key when reconciling an authorisation file against a settlement file. Mastercard's lifecycle key is somewhere else — DE63 subfield 2, the Banknet reference plus date — so do not assume DE37 alone joins Mastercard traffic.
example622209000123Retrieval reference number. A common (not mandated) recipe: Julian date 6222 (2026, day 222) + hour 09 + STAN
Authorization code returned by the issuer on approval.
Six characters returned by the issuer only when the transaction is approved — its absence alongside DE39 = 00 is itself a defect worth alerting on. Treat the value as opaque: it has no internal structure and is not guaranteed unique across issuers. On its own it is a weak key for matching a later refund to its original; pairing card number with terminal ID matches far more of them than pairing authorisation code with merchant ID.
Transaction result: 00 = approved, others are decline reasons.
Two characters. 00 means approved and everything else is a reason, but only a handful are genuinely standard — 05 do not honour, 51 insufficient funds, 54 expired card, 55 invalid PIN, 61 exceeds withdrawal amount limit (65 is the count limit), 91 issuer unavailable. Many values are scheme- or issuer-specific, and 05 in particular is the catch-all an issuer sends when it will not say why. Separate a decline from a failure before deciding what to do: a 91 is worth retrying, a 54 never is.
example00Approved — every other value is a decline reason; see the DE39 lookup
Eight characters identifying the physical terminal or lane, unique within the merchant rather than globally — two different merchants can both use 00000001. Pair it with DE42 when you need a terminal identity that is unique on its own. It is also one of the two fields that matches a refund back to its original purchase far more reliably than the authorisation code does.
Fifteen characters identifying the merchant outlet, assigned by the acquirer and stable across that merchant's terminals. Combined with DE41 it pins down exactly where a transaction happened, and it is the value a cardholder disputes against — so a stale or shared merchant ID is a frequent cause of unrecognised-charge complaints.
Forty characters of positional text. ISO 8583 only fixes the total width — the split inside is defined by each scheme and they differ: Visa authorisation is name 1–25, city 26–38, country code 39–40 (the state lives in a separate field, DE59); Mastercard authorisation is name 22, a mandated single space, city 13, another mandated space, country code 3. Mastercard's IPM clearing layout is different again and does carry street, postcode and state subfields. This is what prints on the cardholder's statement, which makes truncation or misalignment here the single biggest driver of “I don't recognise this charge” disputes. Split it by the offsets in your scheme's spec — never by splitting on spaces, which breaks on the first merchant name that contains one.
Currency of the transaction amount (ISO 4217 numeric; sets the decimal places).
Three digits, ISO 4217 numeric — 840 USD, 978 EUR, 392 JPY, 702 SGD. ISO 8583:1987 actually types this field as alphabetic *or* numeric, and UnionPay's online spec still types it alphanumeric; but every major scheme requires the three-digit numeric code, so that is what you will see. Its real job is to fix how many decimals DE4 has, so it has to be read before the amount means anything. It describes DE4 only: DE50 carries the settlement currency and DE51 the cardholder billing currency, and on a cross-border transaction all three can differ.
example840USD — this is what gives DE4 its decimal point
Sixty-four bits, exactly eight bytes, holding the encrypted PIN block — never the PIN. The bytes mean nothing without both the key and the block format. The formats that fit eight bytes are ISO 9564-1 format 0 (the account number XORed in), 1 (random fill, no PAN), 2 (offline verification on the card) and 3 (format 0 plus random fill). Format 4 is AES and sixteen bytes, so it does not fit DE52 at all — Mastercard carries it in DE110 and omits DE52 entirely, and the two are mutually exclusive. The same PIN under two formats yields different blocks, and a mismatch surfaces as a PIN-verification failure (55, sometimes 86) rather than as a parse error. This field must never be logged, printed or stored.
example9A8B7C6D5E4F32108-byte encrypted PIN block, shown as 16 hex chars — synthetic, decrypts to nothing
Chip-card (EMV) data in TLV format: ARQC, TVR, issuer data, etc.
Chip data as BER-TLV, so the field is a container and each tag inside needs decoding in turn: 9F26 the application cryptogram, which in an authorisation request is the ARQC the issuer verifies, 95 the terminal verification results, 9F27 what the card itself decided, 9F10 issuer application data, 9F36 the counter that exposes cloning. Tag order is not fixed, and although the three-digit LLLVAR prefix would allow 999 bytes every scheme spec we have checked caps the field at 255 — so a fixed-offset parser works right up until a terminal reorders the tags. When a chip transaction declines for no visible reason, 95 and 9F10 are where the answer is.
example82023C00950500000480009A032608109C01005F2A0208409F02060000000025009F100706010A03A000009F1A0208409F2608A1B2C3D4E5F607189F2701809F3303E0F8C89F34030200009F3602003C9F37041A2B3C4DBER-TLV, decoded below. LLLVAR prefix here is 174 — hex characters, not bytes (see encoding note)
Every entry carries the same three-part line: length type · length · data type. So
LL · 19 · n on DE 2 reads "two-digit length prefix, at most 19 characters, digits only".
Token
What it means
FIX
Fixed length. The number is exactly how many characters the field occupies.
LL
Variable length behind a two-digit length prefix. The number is the maximum.
LLL
Variable length behind a three-digit length prefix. The number is the maximum.
n
Digits only.
an
Letters and digits.
ans
Letters, digits and special characters.
ns
Digits and special characters.
b
Binary, written here as hexadecimal characters.
z
Track 2 / track 3 as encoded on the magnetic stripe.
x+n
A leading C or D (credit or debit) followed by digits.
One thing worth knowing about the length: it counts characters in the message as the parser
reads it, not bits. DE 52 shows FIX · 16 · b because the PIN block arrives as 16
hexadecimal characters; the ISO specification writes the same field as b 64, counting
bits. Same field, two ways of counting. The notation
in full covers the n..19 style you will meet in scheme specifications.
Why DE 1 and DE 65 are not entries
Bit 1 and bit 65 are not data elements. Bit 1 set means a secondary bitmap follows; bit 65 set
means a tertiary bitmap follows. Nothing is read out of the message for either, so there is no
name, length or format to give. That is why the list holds 126 entries — DE 2 through DE 128,
minus DE 65. If you want to see which bits are on in a bitmap you have in front of you, the
bitmap calculator does that.
The fields your counterparty defines, not ISO
DE 48, DE 60 to DE 63, and DE 120 to DE 127 are reserved for private use, and DE 56 to DE 59
and DE 112 to DE 119 are reserved for ISO or national use. The names in this dictionary are the
ISO 8583:1987 baseline. Visa, Mastercard, UnionPay, Amex, JCB and Discover all put their own
content in those positions — pick a scheme on the parser and it renames them
accordingly. For anything you are actually building against, your counterparty's current
specification is what decides.
Where the examples come from
Every example value here is lifted from the messages taken apart field by field in
ISO 8583 message examples: an authorization
pair, a financial pair, a reversal with DE 90, an echo test, and a chip transaction with DE 55.
The data is synthetic — reserved test card ranges, placeholder terminal and merchant IDs.
Fields that do not appear in those messages have no example. That is deliberate: a plausible
invented value is worse than a blank one when the person reading is holding a production message
next to the screen.