ISO 8583 Data Elements: The Complete List of All 128 Fields

Which data elements do you see in almost every message?

How do you make sense of all 128 data elements?

The table above covers the dozen or so you hit constantly. The rest are not worth memorising one by one — group them by purpose instead. Fields in the same group almost always travel together, so seeing one is a cue to check the others. No need to memorise the formats either — paste the whole message into the online parser and read each decoded field against the groups below.

What is the difference between DE4, DE5 and DE6?

One transaction carries three amounts, three currencies and two conversion rates. DE4 is what the terminal captured, DE5 is what the network and banks settle, DE6 is what finally lands on the cardholder statement — different currencies, different moments, different rates. DE9 and DE10 are the rates used for those two conversions.

One cross-family behaviour worth remembering: DE9 and DE10 are usually empty in an authorization message — at authorization time no conversion has happened yet and nothing has settled between the network and the issuer. They only carry values in clearing messages. So reaching for the conversion rate while reconciling on the authorization side will usually get you nothing.

For a cross-border transaction, compare DE49 with DE51 first: different means the issuer did the conversion; identical while the acquiring country is not the cardholder's country usually means the acceptance side already converted it. This group is the foundation for understanding dynamic currency conversion.

Why do DE7, DE12 and DE15 show different dates?

Each timestamp belongs to a different party on the chain, and across time zones they will not agree. DE7 is transmission time in GMT; DE12/13 are the acquirer's local time; DE15 is the settlement date; DE16 the conversion date; DE17 the capture date.

When reconciliation drifts, start here: bucketing by DE7 breaks around midnight because it is GMT, while settlement follows DE15.

The table above is the 1987 dictionary. In the 1993 dictionary — the one clearing formats such as Mastercard IPM are built on — DE12 is not a time. It is Date and Time, Local Transaction: twelve digits, YYMMDDhhmmss, carrying the year, month, day and time in one field. The local transaction date no longer has a field of its own, and DE13 does not carry it.

The consequence is the same one you get with DE22 and with DE18/DE26: a decoder written for one message family mis-reads the other without raising an error. Hand a clearing record to an authorization-side DE12 decoder and it takes the two year digits as the hour — 260315143022 (15 March 2026, 14:30:22) is read as 26:03:15. That is not a valid time, but every character is still a digit, so a length-and-type check passes and the value flows on.

What is the difference between DE32 and DE33?

Use this group when the question is which route a transaction actually took. DE32 is the acquiring institution, DE33 the forwarding institution — if they differ, there is a switch in between. DE93/94 identify destination and originator in clearing messages. Read them together with the country codes (DE19/20/21/68/69) to reconstruct a cross-border path.

Which fields carry track data, and what is DE23 for?

DE35/45 carry track data, which includes the full PAN and expiry — the most sensitive fields in the message, and they must be masked in logs. DE23, the card sequence number, distinguishes reissued cards on the same account; if transactions stop matching after a reissue, look here first.

How does a reversal find the original transaction?

DE90 is the 42-digit original data elements block, carrying the original MTI, STAN, transmission time and institution IDs — this is how a reversal finds the transaction it is undoing. DE95 carries the replacement amounts after a partial reversal. Worked through in Reversals, timeouts and repeats.

Why do DE74–DE97 never appear in an authorization message?

You will never see this group in an authorization message — these are the counts and totals of clearing and reconciliation messages: credits, debits, their reversals, and DE97 the net settlement amount.

If the bitmap lights these up in a message you are decoding (the bitmap calculator maps bits to DE numbers), what you have is not an authorization, and the authorization dictionary will not apply.

What do DE24, DE54 and DE70 carry?

DE24 (function code / NII) means quite different things across systems — one to check against your channel's specification. DE54 additional amounts is a repeating structure: each 20-character group is account type 2 + amount type 2 + currency 3 + sign 1 + amount 12, commonly used to return a balance. DE70 appears only in network management messages such as 0800/0810 (sign-on, echo, key exchange).

What are all 128 data elements and their definitions?

Name, format and length below are exactly the dictionary this site's online parser uses, so what you read here is what it decodes. Format notation: n 6 = fixed length, 6 numeric digits; n LL(19) = variable length up to 19 digits with a 2-digit length prefix; LLL = 3-digit prefix; an / ans allow letters and symbols, b is binary and its length is counted in hex characters (b 16 = 16 hex characters = 8 bytes = 64 bits), z is track data, x+n is an amount with a leading C/D sign. The notation is unpacked in field format notation.

Two rows marked * are not ordinary data fields — DE1 and DE65 belong to the bitmap mechanism itself. Everything else is described at the ISO 8583:1987 level; where the standard leaves a field reserved, the table says so rather than inventing a meaning.

Why do reserved fields like DE63 differ from network to network?

Not every data element has a fixed meaning. The standard deliberately leaves whole ranges blank:

ISO 8583 only defines the skeleton. Card networks, national payment schemes and individual processors each fill the blanks with whatever their business needs. That produces three consequences worth internalising.

1. The same DE number carries different things on different networks. A field guide you found online is only ever true for the one network — often the one specific channel — it was written against.

2. Even on the same network, the meaning changes with message type. This is the one that bites hardest. Authorisation messages and clearing/settlement files are separate specifications with separate dictionaries. A reserved DE in a 0100 authorisation and the same DE number in a batch clearing record can be completely unrelated. Always establish which message family you are looking at before reaching for any field table — the MTI decoder tells you from the first four digits. The Mastercard case is mapped pair by pair in Authorization vs Clearing: Same Fact, Different Fields.

3. Reserved fields usually have another layer of structure inside. Subfields, TLV, or fixed-width segments concatenated together. Beyond the length prefix there is no self-describing information in the message, so without the specification you cannot split the payload apart — you can only see how long it is. To inspect the raw bytes, the hex viewer shows ASCII and EBCDIC side by side, and the hex / BCD converter handles the manual arithmetic.

What does Mastercard put in DE105?

DE105 is a good illustration of all three points at once. In ISO 8583:1987 it is simply reserved for ISO use — there is no universal definition to look up. Mastercard fills that slot with Multi-Use Transaction Identification Data, a composite field built from repeated subelement ID (3) + length (3) + value segments. Two of those subelements are worth knowing because they change how transactions are linked together:

Two practical consequences. First, subelement 001 and 002 answer different questions — 001 is "which transaction is this message part of", 002 is "which earlier transaction is this one economically related to". Reading 002 as if it were this transaction's own identifier will link a refund to itself.

Second, treat DE105 and every subelement inside it as optional. A message may omit DE105 entirely, or carry one subelement without the other — a plain purchase has no economically related transaction to point at. A parser that assumes the field is present, or that a particular subelement is always there, will fail on ordinary traffic.

The same DE number, three contexts:

To see what DE105 actually carries in a Mastercard clearing file, open the file in the Mastercard IPM file parser. And if what you have is an authorization message, paste the raw hex or ASCII into the ISO 8583 message parser — the MTI, bitmap and every data element unfold into the fields on this page.