The Fields That Matter

26.0 What this chapter gives you#

1. You will be able to say, for each of the fifteen fields that carry a card authorisation, what it holds, who writes it and what specifically breaks when it is wrong.
2. You will be able to read a field definition such as n..19, ans 8 or ans...999 and know the character set, the length rule, and the justification and padding that go with it.
3. You will be able to explain why data element 4 carries 000000004250 with no decimal point, and why the position of that point is determined by data element 49 rather than by the amount.
4. You will be able to decompose a processing code such as 010300 into transaction type and two account types, and say why an account-type pair of 00 does not mean “current account”.
5. You will be able to say which clock a scheme rule is talking about when it names DE7, DE12, DE13 or DE15, and why a purchase at 23:58 on 31 December can be reconstructed 364 days wrong.
6. You will be able to explain why sending 01 in DE22 for a card that was physically present is a commercial event rather than a technical one.
7. You will be able to distinguish the identifiers by lifetime — the STAN that lasts one request-and-response pair, the RRN that lasts into a chargeback weeks later — and say which one an acquirer will ask a merchant for.
8. You will be able to state exactly which parts of an authorisation are cryptographically protected and which are unauthenticated assertions made by whoever is sending.
9. You will be able to name which tags inside DE55 come from the card and which from the terminal, and say why the amount, currency and country have to appear twice in one message.
10. You will be able to explain why DE39 00 does not mean the transaction completed, and what else a response can carry that changes the outcome.

The previous two chapters gave you the envelope and the index. The message type indicator says what kind of message this is; the bitmap says which numbered boxes are inside. Neither says anything about the contents, and the contents are where integrations actually fail.

This is worth stating plainly. A message that will not parse is an easy problem: it fails immediately, it fails identically every time, and the fix is usually one line. The expensive failures are the ones where every field parses perfectly, the bitmap is correct, the lengths are right, and the value in one box is simply wrong — a refund flagged as a purchase, an amount off by a factor of a hundred, a terminal identifier reused across two shops, a reference number regenerated on a retry. Those do not surface at the parser. They surface three days later in a reconciliation report, or six weeks later in a chargeback, and by then the message that caused them has been through four systems belonging to three companies.

So this chapter walks the fields one at a time. For each one: what it holds, who writes it, and what specifically goes wrong when it is wrong. There are 128 numbered elements in ISO 8583 and 192 if you count the tertiary bitmap, but a working card authorisation is built from perhaps twenty, and about fifteen of those carry the weight. Those fifteen are the subject here.

The plain version#

Imagine a form that travels along a row of desks.

The form has numbered boxes and no labels — that trick you already know. What you do not yet know is the rule that governs the desks. Every desk along the row is allowed to write in some of the boxes, and only those. Every other box on the form it must copy across to the next desk exactly as it received it: same characters, same spaces, same everything. Copy it wrong and nobody notices at your desk. They notice at the far end, or on the way back, when the form no longer matches the one that was sent.

There are four desks. The till in the shop. The shop’s bank. The card company in the middle. Your bank. The form goes left to right, your bank writes the answer into two boxes, and the form comes back right to left.

Who writes what#

The till fills in almost everything factual about the sale. It knows the card number, because the card just told it. It knows the amount, because the shopkeeper just typed it. It knows what kind of sale this is — a purchase, not a refund. It knows what time its own clock says. It knows how the card was presented: tapped, inserted, swiped or typed in by hand. It knows which till it is and which shop it belongs to. And it knows what the chip said, because the chip signed a little package of data and handed it over.

The shop’s bank fills in the boxes about the journey rather than the sale. What time it is sending this message. A serial number of its own so it can match the answer to the question. Its own identifying number. And a reference number that it invents now and that will follow this transaction for the rest of its life — into the shop’s bank statement, into the settlement file, and into any argument that happens later.

The card company in the middle mostly reads. It looks at the first six or eight digits of the card number, works out which bank issued it, and forwards the form.

Your bank writes exactly two boxes. Box 38 gets a six-character approval code that your bank makes up on the spot — the thing printed on the receipt as “AUTH CODE”. Box 39 gets two characters that mean yes or no. Everything else on the returning form is a copy.

The worked example#

The same purchase as two chapters ago. A book, £42.50, at a bookshop in London, on 17 March 2026, at 32 minutes and 5 seconds past two in the afternoon. Here is the form when it leaves your bank on the way back, with the author of each box named.

Fifteen boxes. Two of them written by the bank that decided; thirteen of them written before the message ever left the shop.

Three ways this goes wrong#

The amount with no decimal point. Box 4 is 000000004250. There is no decimal point in it and there never will be, because box 49 says 826 and everybody has agreed that pounds have two digits after the point. Now suppose the till was set up by someone who thought box 4 held whole pounds. It sends 000000000042. The customer is charged 42 pence, the shop is short by £42.08, and nothing anywhere reports an error, because 000000000042 is a perfectly valid amount. Or suppose the mistake runs the other way and the till sends 000000425000. The customer is charged £4,250 for a book, and the first anyone hears about it is a telephone call.

Two tills with the same serial number. Box 11 is a serial number the shop’s bank uses to match answers to questions. Suppose the shop opens a second till and the engineer copies the configuration from the first, including the counter it starts from. Now two purchases, seconds apart, both go out as number 004417. Two answers come back. Each till takes the first answer that arrives. There is a fifty-fifty chance that till one prints the approval that belonged to till two, and the customer whose card was actually declined walks out with a book.

The box that says how the card was read. Box 22 says 071: the card was tapped, on a terminal that has a PIN pad. Suppose the till is configured to send 011 instead, which means the number was typed in by hand. Nothing fails. The purchase is approved and the receipt prints. But “typed in by hand” is what a telephone order looks like, and the rules that decide who pays when a purchase turns out to be fraud treat a typed-in number very differently from a tapped card. The shop has just given away its protection, at a slightly higher fee, by sending one digit it did not mean.

None of those three is a software crash. All three are one box holding a value that is the wrong kind of true.

Where the plain version stops being true#

The desks do not merely copy. The rule that every desk copies other people’s boxes unchanged is the single most useful lie in the plain version, and it is a lie. Acquirers routinely rewrite fields on the way through. They renumber the serial number in DE11, because the number the terminal used is unique only within that terminal and the acquirer needs one unique within itself. They may replace the card number in DE2 with a network token, so the number the issuer sees is not the number embossed on the card. They translate processing codes between their own terminal interface and the scheme’s dialect. They convert amounts when the settlement currency differs from the transaction currency, adding DE5 and DE50 that the terminal never sent. The practical consequence is that the message the issuer receives is not the message the terminal sent, and when you are debugging across an acquirer boundary you are looking at two different messages that describe one purchase. Field values are not conserved along the chain. Only a handful are, and knowing exactly which is most of the skill.

One field does not have one meaning. ISO 8583 fixes the number, the name and the format of each data element. It does not fix the vocabulary inside most of them. DE3’s account-type pairs, DE22’s entry-mode codes, DE39’s response values and DE55’s tag requirements are all set by the scheme, and the schemes disagree with each other in small, specific, expensive ways. The same six digits in DE3 can mean a cash advance from a credit account on one network and something the next network does not implement at all. Worse, the field’s own shape changes between editions of the standard: DE22 is three digits in the 1987 edition and a twelve-position code in 1993; DE39 is two characters in 1987 and three in 1993; DE12 is a local time in 1987 and a local date-and-time in 1993. “Which field” is never a complete question. The complete question is which field, on which scheme, in which edition, in which direction.

The reply is not two boxes. The plain version says the issuer writes DE38 and DE39 and copies the rest. In practice the response can also carry a different amount from the one requested, when the issuer approves a partial amount and the terminal must handle the shortfall. It can carry balances in DE54. It can carry issuer authentication data and issuer scripts in DE55, which the terminal must hand back to the chip, and which can cause a card to refuse a transaction that DE39 just approved. It can carry additional response data in DE44 and private data in DE48 that changes what the terminal is required to display. Treating DE39 as the whole answer is how terminals end up printing “APPROVED” for transactions that did not complete.

Almost nothing in the message is proof. The last correction is the one that reframes everything else. Of the fifteen fields in the table above, exactly one is cryptographically protected against a lying sender: DE55, which contains a cryptogram the chip computed with a key only the chip and the issuer hold. DE52 protects the PIN. DE64 protects the message as a whole between two adjacent parties. Everything else — the entry mode, the terminal identifier, the merchant identifier, the amount, the currency — is an unauthenticated assertion made by whoever is sending. The issuer cannot verify that DE22 is honest. It can only decide how much to trust the party that sent it. This is why card payments are governed by liability rules and scheme membership rather than by proof, and it is why an incorrect DE22 is a commercial event rather than a technical one.

The technical version#

Reading a field definition#

Every scheme specification describes a data element with the same shorthand, and it is worth being precise about it before using it fifteen times.

The letters give the character set. n is numeric, digits only, and is conventionally carried as packed binary-coded decimal, two digits to the byte. a is alphabetic, an alphanumeric, ans alphanumeric plus the special characters, b binary, and z the track-2 character set of ISO/IEC 7813, which includes the field separator. x+n denotes an amount preceded by a debit or credit indicator.

The number gives the length, and the notation for the length is the part people get wrong. n 6 is fixed: exactly six digits, always present in full. n..19 is variable with a two-digit length prefix, conventionally written LLVAR: the field begins with two digits saying how many follow, so a sixteen-digit card number is transmitted as 16 then the sixteen digits. ans...999 is variable with a three-digit length prefix, LLLVAR. Some specifications write n..19 as n-19 or LLVAR n 19; they mean the same thing.

Fixed numeric fields are right-justified and zero-filled. Fixed alphanumeric fields are left-justified and space-filled. That asymmetry causes real defects: a terminal identifier of TERM42 in an eight-character field is TERM42 plus two spaces, not 00TERM42, and a system that trims trailing spaces before comparing will match records that a system which does not trim will treat as different.

DE2, primary account number#

Format n..19, LLVAR, up to nineteen digits.

DE2 carries the account number as defined by ISO/IEC 7812-1: an issuer identification number, an individual account identifier, and a Luhn check digit in the final position. Real lengths run from twelve to nineteen, with sixteen dominant and fifteen normal for American Express.

It is populated by the terminal, from track 2 of the magnetic stripe, from EMV tag 5A on a chip card, or by hand from the embossing. It is frequently repopulated afterwards. Under network tokenisation the value the issuer sees is a device token or a merchant token rather than the funding account number, and the mapping back to the real number happens inside the scheme. Under point-to-point encryption the acquirer’s decryption endpoint puts the clear PAN into DE2 for the first time at the edge of its own secure zone.

DE2 is also, quite often, absent. When the terminal sends full track 2 data in DE35, the account number is already inside that field, and many acquirer interfaces treat DE2 and DE35 as mutually exclusive rather than duplicating the number. A parser that assumes DE2 is always present will fail on perfectly valid magnetic-stripe traffic.

What goes wrong. Odd-length PANs in packed BCD need a padding nibble, and implementations differ on whether it goes at the front or the back; get it wrong and a nineteen-digit number arrives with a stray zero. Truncation at eighteen digits is a recurring defect in systems written when sixteen was universal. Storing DE2 anywhere it does not need to be is the single most common PCI DSS finding in card systems, and the field’s presence in logs is the usual culprit. Finally, a mismatch between DE2 and the account number embedded in DE35 or in EMV tag 5A is a hard decline at most issuers, because it is exactly what a tampered message looks like.

DE3, processing code#

Format n 6, fixed, six digits in three pairs.

Positions 1 and 2 are the transaction type. Positions 3 and 4 are the account the money comes from. Positions 5 and 6 are the account it goes to. It is populated by the terminal and frequently translated by the acquirer.

The transaction types that matter in practice, as documented for Mastercard and Visa authorisation traffic:

The account-type pairs are a much shorter list: 00 default, 09 other, 10 savings, 20 checking, 30 credit.

So 000000 is a purchase from the default account, 010100 a cash withdrawal from savings, 010300 a cash advance against credit, 200000 a refund, 300000 a balance enquiry.

The divergence between networks is public and it is not subtle. Not every network implements every transaction type, and several codes carry network-specific meaning: 17 marks the over-the-counter cash disbursement flag on Mastercard, while the equivalent condition on Visa is 01 combined with merchant category code 6010. A processing code is meaningful only against a named specification.

What goes wrong. Sending 000000 for what is commercially a refund produces a second debit rather than a credit, and the fix involves a manual adjustment and an unhappy customer. Sending a balance enquiry with a non-zero DE4 is rejected by some issuers and silently treated as a purchase attempt by others. Specifying an account type the cardholder does not have produces DE39 52 or 53 — “no checking account”, “no savings account” — which support teams reliably misdiagnose as an issuer outage, because the card works fine everywhere else. And an account-type pair of 00 does not mean “current account”. It means “not specified, issuer decides”, which is a different thing and behaves differently at an ATM.

DE4, amount, transaction#

Format n 12, fixed, twelve digits, unsigned, no decimal separator.

The value is expressed in the minor units of the currency named in DE49. The decimal position is implied by the ISO 4217 exponent for that currency and is never transmitted. Two decimal digits for sterling (826) and US dollars (840); none for Japanese yen (392); three for Kuwaiti dinar (414). The maximum representable value is 999,999,999,999 minor units.

It is populated by the terminal. It is also, on occasion, populated by the issuer: a partial approval returns an amount lower than the amount requested, and the terminal must then either collect the difference by another means or reverse the whole thing.

DE4 does not travel alone. DE5 is the settlement amount, in the currency the acquirer settles in, added by the acquirer or the scheme. DE6 is the cardholder billing amount, in the currency of the cardholder’s account, added by the issuer side. DE54 carries additional amounts, each with its own account type, amount type, currency code and sign, which is how ATM balances and cashback components travel. Four fields, four currencies, four opportunities for a conversion to be applied twice.

What goes wrong. Floating-point arithmetic anywhere near this field is a defect waiting for a specific input; amounts belong in integers of minor units or in decimal types with explicit scale. Hard-coding two decimal places breaks the moment the system sees yen or dinar. Estimated amounts create their own class of problem: a fuel pump authorises a nominal amount and clears the real one, a hotel authorises a nightly estimate and increments it, and every one of those flows depends on the clearing amount being allowed to differ from the authorised amount within scheme-defined tolerances. And an account verification is DE3 transaction type 18 with DE4 set to zero, not a one-pound purchase followed by a reversal, although the industry spent a decade doing the latter.

DE7, DE12 and DE13, the three clocks#

DE7 is transmission date and time, n 10, MMDDhhmmss, in Coordinated Universal Time, set by the sender of the individual message. It changes at every hop. It is not the time of the purchase; it is the time this particular leg was transmitted.

DE12 is local transaction time, n 6, hhmmss, in the local time of the point of sale, set by the terminal. DE13 is local transaction date, n 4, MMDD, likewise.

Together they are the reason chapter after chapter of scheme documentation insists on which clock a rule refers to. A cut-off expressed in DE7 is a different instant from one expressed in DE12 and DE13.

The edition trap is severe here. In the 1987 edition, DE12 is a time and DE13 is a date, and neither carries a year. In the 1993 edition DE12 becomes a combined local transaction date and time, twelve digits, and DE13 is redefined. A system that has to reconstruct a full timestamp from 1987-edition fields must supply the century and year from context, and the last days of December are where that inference fails: a transaction at 23:58 local on 31 December, transmitted at 00:02 UTC on 1 January, produces a DE7 whose date is in the following year and a DE13 that is not, and a naive reconstruction dates the purchase 364 days wrong.

What goes wrong, beyond the year. Terminal clocks drift, and nothing in the protocol corrects them; a terminal an hour out because nobody handled British Summer Time will put transactions in the wrong reconciliation window even though DE7 is perfect. Systems that use DE7 for duplicate detection and DE12 for reporting will produce two internally consistent reports that disagree with each other. And DE15, the settlement date, is a third date again, owned by the acquirer, and is the one that actually determines when money moves.

DE11, system trace audit number#

Format n 6, fixed, six digits.

The STAN is assigned by the institution that originates the message. It is unique within that originator, within a processing day, and it wraps at 999999 back to

1. It is not globally unique, it was never intended to be, and treating it as a transaction identifier is a design error that surfaces at scale.

Its purpose is narrow and important: it is part of the key that lets two adjacent systems match a response to a request. The full matching key is set by each scheme rather than by ISO, but it conventionally combines DE11 with DE7, DE32 (the acquiring institution identification code) and DE37.

The rules around it are strict in three places. A repeat message — origin digit changed from 0 to 1, producing 0101 from 0100 — must carry the same STAN as the original, because the whole point is for the receiver to recognise it as the same transaction rather than a new one. A reversal quotes the original STAN inside DE90. And an advice must not reuse a STAN that is still in the matching window for a different transaction.

What goes wrong. Two terminals sharing a STAN sequence, described in the plain version, is the classic. So is a STAN counter that resets on reboot rather than persisting, which produces collisions in a burst after every power cut. So is generating a fresh STAN on a retransmission, which converts a timeout into a genuine double charge, because the issuer now sees two unrelated authorisation requests instead of one request and its repeat.

DE22, point of service entry mode#

In the 1987 edition, n 3: two digits of PAN entry mode followed by one digit of PIN entry capability. It is set by the terminal, and it is the field that decides a large part of the commercial outcome of the transaction.

The PAN entry mode values, as documented against the Mastercard Customer Interface Specification and VisaNet authorisation messages:

The third digit, PIN entry capability, is a much shorter list: 0 unspecified, 1 the terminal has PIN entry capability, 2 it does not, 3 software-based PIN entry on mobile, 8 the terminal has a PIN pad but it is not currently operative.

Note the pairs that are easy to confuse and expensive to confuse. 05 and 07 are chip transactions, contact and contactless, and both carry a cryptogram in DE55. 02, 90 and 91 are magnetic-stripe transactions, and 91 is a contactless tap that produced stripe-equivalent data rather than a chip cryptogram — a different security posture entirely from 07 despite looking identical to the customer. 80 is chip fallback, and many issuers decline it by standing policy because it is the signature of a cloned card being presented at a terminal whose chip reader has been deliberately damaged.

The 1993 edition replaces all of this. DE22 becomes the point of service data code, twelve positions rather than three, each describing one property of the acceptance environment. American Express’s Global Credit Authorization Guide, which is written to ISO 8583:1993, lays them out as: card data input capability, cardholder authentication capability, card capture capability, operating environment, cardholder present, card present, card data input mode, cardmember authentication method, cardmember authentication entity, card data output capability, terminal output capability and PIN capture capability. Mastercard carries substantially the same information in DE61 in its 1987-format authorisation messages. Same facts, three different homes, depending on which specification you are implementing.

What goes wrong. Everything downstream of DE22 is a rule about liability and price. Sending 01 for a card that was physically present forfeits card-present interchange and card-present chargeback protection. Sending 07 when the terminal actually performed a magnetic-stripe read causes the issuer to look for a cryptogram in DE55 that is not there, producing a decline that looks like a network fault. Sending 05 while omitting DE55 entirely is the same failure in the other direction and is one of the most common findings in scheme certification testing. And the PIN entry capability digit must match reality: a terminal that claims capability 1 and then never sends a PIN block in DE52 will have its cardholder verification method results in DE55 questioned by the issuer.

DE37, retrieval reference number#

Format an 12, fixed, twelve alphanumeric characters.

The RRN is assigned by the acquirer and is echoed unchanged by everyone downstream. It is the identifier with the longest life in the whole message: it persists from authorisation into the clearing record, into the settlement report, and into the retrieval requests and chargebacks that may follow weeks later. When a merchant telephones an acquirer about a specific transaction, the RRN is what the acquirer wants.

Its internal construction is not fixed by ISO 8583, which defines it only as a reference supplied by the system retaining the original source information. The schemes impose their own conventions. A Julian date prefix in the form YDDD — one digit of year, three digits of day of year — is widespread; Mastercard’s IPM clearing format defines the first four positions of DE37 as the Julian processing date the acquirer assigned to the transaction. A common full convention extends that with a two-digit hour and a six-digit sequence, which is how the example 607614430041 decomposes: year 6, day 076 which is 17 March 2026, hour 14, sequence 430041.

What goes wrong. Regenerating the RRN on a retransmission destroys the receiver’s ability to recognise the retransmission, with the same consequence as a regenerated STAN. Failing to echo it exactly — trimming trailing spaces, upper-casing, treating it as a number and dropping leading zeros — breaks reversal matching, because the reversal will not join to the original. Reusing RRNs within the retention window creates records that cannot be told apart in a dispute, and the party that cannot produce a unique reference is the party that loses the dispute.

DE38, authorisation identification response#

Format an 6, fixed, six alphanumeric characters.

Generated by the issuer, returned in the response, printed on the receipt as the authorisation code, and required in the subsequent clearing record. It is the issuer’s own handle on the approval it granted.

What goes wrong. Acquirers and gateways occasionally invent a value for DE38 when the issuer did not return one — for offline approvals, for stand-in processing, or simply as a placeholder. That value will not match anything at the issuer, and the clearing record carrying it is a candidate for a chargeback on the grounds of no valid authorisation. The reverse also happens: an approval in DE39 with DE38 blank or space-filled, which some acquirer platforms accept and then cannot present. And the field is alphanumeric, so a system that stores it in a numeric column will corrupt any code containing a letter, which is most of them.

DE39, response code#

Format an 2 in the 1987 edition, an 3 in 1993 and later. Set by the issuer, or by the scheme when the scheme answers on the issuer’s behalf.

The 1987 vocabulary is a flat two-character list. The values that carry real operational weight are these:

Codes 04, 07, 41 and 43 carry card-retention semantics: the terminal is being instructed to capture the card, which unattended terminals implement literally and countertop terminals implement as a message to the operator.

The 1993 edition replaces the flat list with a three-digit structure in which the leading digit identifies the class of outcome, so 000 is approved, 100 is a plain decline, 200 is a decline with card capture, 9xx is could-not-process. The two systems coexist. A single transaction can pass through an interface using the 1987 codes and another using the 1993 codes, and the mapping between them is lossy in both directions. Response codes get a chapter of their own later in this volume, because the interesting question about them is not what they are but why so many of them are deliberately uninformative.

What goes wrong here is chiefly interpretation. DE39 00 does not mean the transaction completed; it means the issuer approved it. The terminal can still fail, the chip can still decline in the second generate-AC after examining the issuer’s response in DE55, and the customer can still walk away. A system that treats 00 as terminal state rather than as one input to terminal state will under-report reversals and over-report revenue.

DE41 and DE42, terminal and merchant identity#

DE41, card acceptor terminal identification, is ans 8, fixed, left-justified and space-filled. DE42, card acceptor identification code, is ans 15, fixed, left-justified and space-filled. DE43, card acceptor name and location, is ans 40 in the 1987 edition.

DE41 is assigned by the acquirer and configured into the terminal. It must identify one physical acceptance point uniquely within the card acceptor. DE42 is the acquirer’s identifier for the merchant, and it is the field on which the acquirer’s settlement, its interchange qualification and its risk monitoring all hang. DE43 is the human-readable name and town, and it is the raw material from which the descriptor on the cardholder’s statement is built.

What goes wrong. Duplicate DE41 values across sites — the same terminal identifier deployed to two shops after a hardware swap — make it impossible to attribute a transaction to a location, which matters both for the merchant’s own reporting and for fraud investigation. A mismatch between the DE42 in the authorisation and the DE42 in the clearing record breaks the acquirer’s matching and produces unmatched clearing, which is expensive to resolve manually. And DE43 is quietly one of the highest-leverage fields in the entire message: a merchant whose descriptor reads as an unrecognisable holding-company name generates “I do not recognise this transaction” disputes at a multiple of the rate of one whose descriptor reads as the shop’s trading name and town. That is a chargeback cost caused entirely by forty characters of free text.

DE49, currency code, transaction#

Format n 3 in general use, defined in the 1987 edition as three characters which may be alphabetic or numeric. In practice every major scheme requires the ISO 4217 numeric code: 826 sterling, 840 US dollar, 978 euro, 392 yen, 356 Indian rupee.

It is set by the terminal, from its own configuration rather than from the card. It says what currency DE4 is denominated in, and by implication where the decimal point sits, because the ISO 4217 minor-unit exponent is not carried in the message.

Its companions are DE50, the settlement currency, and DE51, the cardholder billing currency. A cross-border purchase can legitimately involve three different currency codes in one message chain, and dynamic currency conversion adds a fourth relationship, because the cardholder is offered a rate at the terminal and the transaction is then presented in the cardholder’s own currency with the conversion already applied.

What goes wrong. Sending the alphabetic code GBP where the interface expects 826 is a format error, and it is a common first-day defect because the alphabetic form is what humans write. Defaulting to 840 in a terminal configuration template is worse, because it does not fail: it produces a valid message denominated in a currency the shop does not trade in. Assuming two decimal places universally corrupts every yen and every dinar amount by two orders of magnitude in one direction or three in the other. And a currency code that differs between the authorisation and the clearing record will not match, which the acquirer will see as an unmatched presentment.

DE55, integrated circuit card data#

Format ans...999 in the 2023 edition of the standard; schemes cap it far lower, commonly at 255 bytes with a three-digit length prefix. It is a format inside a format, and it is parsed by entirely different rules from the message carrying it.

The 2023 standard is explicit that its own composite-dataset structure does not apply to the ICC-related data element, because the linking of related sub-elements there follows ISO/IEC 7816-6. DE55 is therefore a sequence of EMV tag-length-value objects, with tags of one or two bytes, lengths in BER-TLV form, and values whose interpretation is defined in EMV Book 3 rather than in ISO 8583 at all.

The tags that carry the transaction, on the way to the issuer:

And on the way back, from the issuer:

The division of labour is the point. The card supplies what only the card knows and signs it; the terminal supplies the context the card was asked to sign over; the issuer recomputes the cryptogram from the same inputs using the same key and either gets the same answer or does not. The reason 9F02, 5F2A, 9F1A and 9F37 must appear in DE55 even though the amount, the currency and the country are already elsewhere in the message is that these are the values the card signed. If DE4 says one amount and tag 9F02 says another, the cryptogram will validate against 9F02 and the issuer now knows that something between the chip and it altered the amount.

What goes wrong. Truncation at a scheme’s byte limit silently removes trailing tags, and if 9F10 is one of them the issuer cannot derive the session key and cannot validate the cryptogram, producing a decline with no informative code. Sending the field as ASCII hexadecimal where the interface expects binary, or the reverse, doubles or halves every length and yields a parse failure at the first tag. Re-ordering tags is permitted by BER-TLV and is nonetheless a frequent cause of failure in implementations that parse by position rather than by tag. Constructed tags — templates whose value is itself a sequence of TLVs — need recursive parsing, and a flat parser that meets tag 71 will read an issuer script as a single opaque blob. And omitting DE55 entirely on a transaction whose DE22 claims 05 or 07 is the certification failure named earlier: the message says a chip was used and contains no evidence that one was.

The fields in one table#

What this table leaves out#

Fifteen fields is enough to move money and nowhere near enough to run an acquiring business. DE35 and DE45 carry track 2 and track 1 data. DE25 carries the point of service condition code, which says whether this is a normal sale, a recurring payment, a mail order or a repeat. DE32 and DE33 identify the acquiring and forwarding institutions and are part of the matching key. DE48 is additional data, private, and is where every scheme has quietly parked the things ISO 8583 has no room for. DE52 carries the enciphered PIN block, formatted per ISO 9564-1. DE54 carries additional amounts. DE61 and DE62 are private fields where Mastercard puts point of service data and transaction-life-cycle identifiers. DE64 and DE128 carry message authentication codes. DE90 carries the original data elements that let a reversal find what it is reversing.

Each has the same three questions attached to it: what it holds, who writes it, and what breaks when it is wrong. The habit is worth more than the list, because the list changes between schemes and the habit does not.

The next chapter takes a single authorisation and walks it end to end, byte by byte, with every field in this chapter populated and every hop accounted for. It is the same purchase, the same bookshop and the same £42.50, and by the end of it there will be nothing left in the message you cannot name.

26.98 Common wrong ideas#

Wrong: every desk copies the boxes it did not write, so the message the issuer receives is the message the terminal sent. Right: acquirers renumber DE11, may replace DE2 with a network token, translate processing codes and add DE5 and DE50, so debugging across an acquirer boundary means comparing two different messages that describe one purchase.

Wrong: the field number determines the meaning. Right: ISO 8583 fixes the number, the name and the format but not the vocabulary inside; the complete question is which field, on which scheme, in which edition, in which direction.

Wrong: the issuer writes DE38 and DE39 and copies the rest. Right: the response can also carry a reduced amount for a partial approval, balances in DE54, issuer authentication data and scripts in DE55, and private data in DE48 that changes what the terminal must display.

Wrong: DE11 identifies a transaction. Right: the STAN is unique only within one originator within a processing day and wraps at 999999; it is one part of a matching key that conventionally also uses DE7, DE32 and DE37.

Wrong: a retransmission should carry a fresh STAN and a fresh retrieval reference number. Right: a repeat carries the same values with the MTI’s origin digit changed from 0 to 1; regenerating them converts a timeout into a genuine double charge.

Wrong: amounts have two decimal places. Right: the exponent comes from the ISO 4217 entry for the currency in DE49 — none for the yen, three for the Kuwaiti dinar — and hard-coding two corrupts those amounts by orders of magnitude.

Wrong: 07 and 91 in DE22 are much the same, because the customer tapped the card either way. Right: 07 is a contactless chip transaction carrying a cryptogram in DE55 and 91 is a contactless read that produced stripe-equivalent data, which is a different security posture entirely.

Wrong: DE38 can be filled in locally when the issuer did not return one. Right: an invented authorisation code matches nothing at the issuer, and the clearing record carrying it is a candidate for a chargeback on the grounds of no valid authorisation.

Wrong: DE43 is cosmetic free text. Right: it is the raw material for the statement descriptor, and a descriptor reading as an unrecognisable holding company generates disputes at a multiple of the rate of one reading as the shop’s trading name and town.

Wrong: DE55 can be parsed by position like the rest of the message. Right: it is BER-TLV under ISO/IEC 7816-6, where tags may legitimately be re-ordered and templates nest, so a flat positional parser will read an issuer script as a single opaque blob.

26.99 Chapter summary in 20 lines#

1. A message that will not parse is a cheap problem; the expensive failures are the ones where every field parses perfectly and one value is simply the wrong kind of true.
2. There are 128 numbered data elements, a working card authorisation is built from about twenty of them, and about fifteen carry the weight.
3. The plain rule is that each desk along the chain writes its own boxes and copies the rest, with the till writing the facts of the sale, the acquirer the facts of the journey, and the issuer exactly two boxes.
4. That rule is the most useful lie in the chapter, because acquirers renumber the STAN, tokenise the account number, translate processing codes and add currency fields the terminal never sent.
5. A field definition is a character set and a length rule, where a bare number means fixed, two dots mean a two-digit length prefix and three dots mean a three-digit one.
6. Fixed numeric fields are right-justified and zero-filled while fixed alphanumeric fields are left-justified and space-filled, and that asymmetry causes real matching defects.
7. DE2 carries the account number, is frequently repopulated by tokenisation or point-to-point decryption, and is quite often absent altogether when full track 2 data travels in DE35 instead.
8. DE3 is three pairs — transaction type, account from, account to — and the transaction types diverge between networks publicly and expensively.
9. DE4 is twelve unsigned digits of minor units with no decimal separator, and the decimal position is implied by the ISO 4217 exponent of the currency named in DE49.
10. DE7, DE12 and DE13 are three different clocks — the sender’s transmission time, the terminal’s local time and the terminal’s local date — and DE15, the settlement date, is a fourth date that determines when money moves.
11. The 1987-edition date fields carry no year, so a purchase at 23:58 local on 31 December transmitted at 00:02 UTC can be reconstructed 364 days wrong.
12. DE11 is a correlation key unique only within one originator for one processing day, and treating it as a transaction identifier is a design error that surfaces at scale.
13. DE22 states how the card was read, and because liability rules and interchange hang on it, one wrong digit is a commercial event rather than a technical one.
14. DE37 has the longest life in the message, running from authorisation into clearing, settlement and any dispute, and it must be echoed exactly, leading zeros and trailing spaces intact.
15. DE38 is the issuer’s own handle on the approval it granted, it is alphanumeric so a numeric column will corrupt it, and it must never be invented downstream.
16. DE39 is two characters in the 1987 edition and three in 1993, the two vocabularies coexist, and the mapping between them is lossy in both directions.
17. DE41, DE42 and DE43 identify the terminal, the merchant and the statement descriptor, and forty characters of free text in DE43 drive a measurable share of disputes.
18. DE49 fixes the currency and by implication the decimal position, and a configuration template defaulting to 840 produces a valid message denominated in a currency the shop does not trade in.
19. DE55 is a format inside a format, a sequence of EMV tag-length-value objects whose amount, currency and country are the values the card actually signed, so a disagreement with DE4, DE49 or the country code tells the issuer that something altered the transaction.
20. Everything else in an authorisation is an unauthenticated assertion by whoever sent it, which is why card payments are governed by liability rules and scheme membership rather than by proof.

Chapter sources: ISO 8583:1987 and ISO 8583:1993 data element and response code tables as consolidated in the Wikipedia ISO 8583 article and cross-checked against ISO catalogue entries for ISO 8583:1993 and ISO 8583-1:2003, including clause 6.4.9 and Annex A.16 on the point of service data code; ISO 8583:2023 on the ICC data element and ISO/IEC 7816-6; SoFi Tech Solutions (Galileo) DE003 and DE022 code references, stated to be derived from the Mastercard Customer Interface Specification of 6 February 2024 and VisaNet Authorization-Only Online Messages of 15 October 2023; Mastercard IPM Clearing Formats on the Julian processing date in DE37; American Express Global Credit Authorization Guide, ISO 8583:1993 Version 1, October 2019, for the twelve positions of the point of service data code; Worldpay ISO 8583 Reference Guide v2.50 for acquirer-interface field attributes; EMV Integrated Circuit Card Specifications Book 3 tag definitions as tabulated by EMV Lab and EFTlab; ISO/IEC 7812-1, ISO/IEC 7813, ISO 4217 and ISO 9564-1.