ASCII, Packed BCD and EBCDIC: How the Same Value Becomes Bytes

One value, three encodings

Three values that appear in almost every authorization message, each written out the three ways it can travel. Watch the byte counts, not just the byte values.

MTI 0200 — 4 digits:

DE4 amount 000000005000 — n 12, $50.00 in minor units:

DE2 PAN 5413330089010001 — 16 digits:

The length difference is the whole story. A parser that expects ASCII and receives BCD consumes twice as many characters as exist; one that expects BCD and receives ASCII stops halfway through the field. Either way every boundary after the first mismatched field is wrong — which is why encoding sits at step two of the parse-failure check order, right after framing. To see any of these byte strings decoded live, paste them into the hex viewer: it renders the same bytes as ASCII and EBCDIC in parallel columns.

One thing the three tables quietly demonstrate: a field format like n 12 tells you the field holds twelve digits — it does not tell you whether those digits occupy 12 bytes or 6. Format notation and encoding are two independent agreements, and the notation guide covers the first one only. The second is settled per link, in the interface specification.

Packed BCD: two digits per byte

Packed BCD (binary-coded decimal) stores one decimal digit in each 4-bit nibble, so a byte carries two digits — high nibble first. 0200 becomes 02 00; the hex dump of a BCD field reads exactly like the number itself, which is both its charm and the easiest way to recognise it.

That halving is the reason BCD exists on payment links at all: an n 12 amount drops from 12 bytes to 6, a 16-digit PAN from 16 to 8. Across millions of messages and batch records the savings were worth caring about when these interfaces were designed, and the convention outlived the constraint. The hex / decimal / BCD converter does the packing and unpacking interactively, including the byte counts.

Two properties follow from the nibble layout:

• BCD is not a character encoding. A nibble holds 0–9; there is no way to pack a letter, a space or a slash. Only all-numeric fields can be BCD — which is why a single message can mix encodings, numeric fields packed and alphanumeric fields as ASCII or EBCDIC, field by field.
• Odd digit counts don't fill whole bytes. A 19-digit PAN is nine and a half bytes, so something must fill the spare nibble — and there are two live conventions. Some interfaces pad with a leading zero (123 → 01 23); others fill with a trailing F (123 → 12 3F). Both are common, they are not interchangeable, and nothing in the bytes announces which one is in force: that is set by your endpoint's specification.

EBCDIC (CP500) to ASCII conversion table

EBCDIC is a family of code pages, not one encoding. CP037, CP500, CP1047 and dozens of national variants agree on digits, letters and most punctuation but disagree at a handful of positions — square brackets, the exclamation mark, the vertical bar and a few other symbols sit at different code points depending on the page. The tables below are CP500 (International), the same code page the hex viewer decodes with. If your counterparty declares a different page, the rows marked "varies" are exactly the ones to re-check against their specification.

Digits 0–9

The rows you will use most. An EBCDIC digit is F plus the digit in the low nibble — which is why a numeric field dumped from an EBCDIC file is a wall of F0–F9, and why stripping the high nibble of each byte recovers the packed-BCD form of the same number.

Uppercase A–Z

Unlike ASCII, the EBCDIC alphabet is not contiguous: it runs in three blocks, C1–C9 (A–I), D1–D9 (J–R) and E2–E9 (S–Z), with unrelated code points in the gaps. Any code that range-checks "between A and Z" byte-wise breaks on EBCDIC data.

Lowercase a–z

The same three-block pattern, one bit lower: 81–89, 91–99, A2–A9. Note that every lowercase letter has the high bit set — bytes that would be outside printable ASCII entirely.

Punctuation and symbols

Sorted by EBCDIC code point. The "varies" rows are the classic cross-code-page traps: those characters sit at different positions in CP037 and CP1047, so a file decoded with the wrong page comes out with brackets and bars swapped for other symbols while everything else looks fine.

Control characters and the unassigned positions are deliberately not listed — they never appear in message text on purpose. For any byte outside these tables, paste the hex into the hex viewer and read it off the dump: it decodes all 256 positions, byte by byte.

Telling which encoding a dump is in

Start at byte zero. The MTI is the first field of every message, its value is one of a short list, and each encoding gives it away differently:

Past the first bytes, the statistics of the dump usually settle it on sight:

• Dense F0–F9 is EBCDIC, almost without exception. In ASCII, everything above 7E is unprintable, so no text produces those bytes; in EBCDIC they are simply the digits, and payment data is mostly digits. Runs of 40 between them are EBCDIC spaces.
• Dense 30–39 with 20 in between is ASCII — digits and spaces again, one encoding over. ASCII text also never sets the high bit, so a dump full of bytes above 80 is either EBCDIC or not text at all.
• Every nibble 9 or less, and the hex reads like the number you expect: packed BCD. The character columns come out as dots and stray letters that never form words — BCD has no character form, so the readable layer is the hex itself. 54 13 33 00 89 01 00 01 renders as T.3..... in ASCII, but read as hex it is simply the PAN.

When the statistics are ambiguous — short dump, mixed per-field encodings — decode it all three ways and keep the reading that yields a plausible MTI and a bitmap whose bits match the fields you can see. Three attempts in the hex viewer (ASCII and EBCDIC in one paste) plus the BCD converter take about two minutes, which is reliably faster than locating the encoding clause in an interface document. That try-all-three step is exactly where the parse-failure check order puts encoding: after framing, before anything field-level.

Where you actually meet each one

Batch clearing leans EBCDIC. Mastercard IPM (T112) clearing files are the canonical case: mainframe-era platforms, mainframe-native character set, unchanged since. If a "corrupted" file turns readable in the EBCDIC column of a hex dump, that is what you are holding — and the IPM file parser decodes those records field by field.

Online authorization links are most often ASCII, with packed BCD common on links that care about message size — frequently per field, numeric fields packed and text fields not. Which combination your link uses is a property of that link's interface specification, not of the card network in general, so take it from the spec — or determine it empirically as above, which is usually faster.

The annotated sample messages are written in the friendliest form of all — plain ASCII text — precisely so you can paste them straight into the parser and watch a full decode without fighting byte-level encoding first. That page's encoding notes cover how the same samples change shape on a packed link.

👉 Holding a real dump right now? Paste it into the hex viewer to see ASCII and EBCDIC side by side, then hand the winner to the parser for the field-by-field breakdown.

Read next

• ISO 8583 Parse Failures: The Two Root Causes and the Order to Check Them
• Reading ISO 8583 Field Formats
• ISO 8583 Message Examples: 8 Annotated Sample Messages
• Reading ISO 8583: MTI, Bitmaps and Fields