n 6, n ..19 or ans ...999. The notation packs two separate facts into one string: what characters the field may contain, and how the message says how long it is. The second half is where parsers break, because the number of dots is not decoration — it is the number of digits in the length prefix that sits on the wire ahead of the data.
ans..999 cannot exist ·
FIX, LLVAR, LLLVAR
The leading letters are the character set the field is allowed to carry. They combine, so ans means alphabetic, numeric and special characters are all permitted.
| Letter | Permitted content |
|---|---|
a | Alphabetic characters |
n | Numeric digits |
s | Special characters |
b | Binary data, counted in bits |
z | Track 2 / track 3 data as encoded on the magnetic stripe |
x | A leading sign, C for credit or D for debit — always written as x+n |
So n 6 is six digits, an 12 is twelve alphanumeric characters, b 64 is sixty-four bits, and x+n 8 is a sign character followed by eight digits.
Dots mark the field as variable length, and the count of dots is the number of digits in the length prefix. The number after the dots is the maximum the field may reach.
| Notation | Length prefix | Largest length it can express |
|---|---|---|
n 6 | none — fixed | always exactly 6 |
n ..19 | 2 digits | 99 (this field caps at 19) |
ans ...999 | 3 digits | 999 |
This is the part that is easy to skim past. A fixed field is just its data; a variable field is length digits followed by data, and you have to consume both.
Two real examples. The length prefix is shown separated for clarity — in the message it is simply the next bytes.
| Field | Bytes |
|---|---|
DE2 PANn ..19 |
16 5413330089010001two length digits say the PAN is 16 long, then 16 digits |
DE55 ICC dataans ...999 |
028 <28 bytes of EMV TLV>three length digits say 28 bytes follow |
Note the second one: the length is 028, not 28. A 3-digit prefix is always three characters, zero-padded.
ans..999 cannot existYou will find field tables that write ans..999 — two dots with a maximum of 999. That combination is self-contradictory: two digits can only count up to 99, so a 2-digit prefix has no way to say "426 bytes follow". A field with a 999 maximum must be written ans ...999.
The consequence is not cosmetic. Suppose a message really carries a 3-digit prefix and your parser reads two:
02 and believes the field is 2 bytes long.8 that was the third length digit gets consumed as the first byte of data.The message does not fail at the field that was misread. It fails somewhere later, when a length reads as garbage or the record runs past its end — far from the actual cause. Off-by-one in a length prefix and a stray trim() that removes trailing padding produce the same symptom for the same reason: after the boundary moves, nothing downstream lines up.
Implementations often label length handling with names rather than dots. They map one to one:
| Name | Dot notation | Meaning |
|---|---|---|
FIX | n 6 | Fixed length, no prefix |
LLVAR | n ..19 | 2-digit length prefix (LL) |
LLLVAR | ans ...999 | 3-digit length prefix (LLL) |
The Ls are literally the length digits. There is no semantic difference between the two styles — dot notation additionally tells you the character set, which the LLVAR names do not.
One caveat worth carrying: how those length digits are encoded is a separate question. The same LLLVAR field can carry its prefix as three ASCII characters, as packed BCD in fewer bytes, or in EBCDIC. The notation describes the count of digits, not their byte representation — check your channel's encoding before assuming. The hex viewer shows the same bytes as ASCII and EBCDIC side by side if you need to tell which one you are looking at.