Authorization traffic uses 0xxx MTIs from the ISO 8583:1987 series — 0100 Authorization Request, 0110 response, 0400 reversal. Clearing runs through Mastercard's IPM format with 1xxx MTIs from the 1993 series — 1240 First Presentment, 1442 Chargeback, 1740 Fee Collection. These are separate specifications with separate field dictionaries, and Mastercard's rules routinely state a requirement twice, once per dictionary: one value "in DE x of Authorization Request/0100 messages" and another "in PDS xxxx of First Presentment/1240 messages".
So when you move from parsing authorization messages to reading clearing files (or reconciling one against the other), the field table you memorised stops applying. The rest of this page is the crosswalk for the pairs that are publicly documented.
The most disorienting cases are DE numbers that exist in both families but change definition.
In authorization, DE22 is POS Entry Mode and subfield 1 is the PAN entry mode. In clearing, DE22 is Point of Service Data Code, subfield 1 becomes a terminal capability, and the actual input mode moves to subfield 7. Even the values for the same fact differ. For a contactless transaction, Mastercard's identification tables require:
| Fact | Authorization 0100/0200 | First Presentment/1240 |
|---|---|---|
| Contactless M/Chip (EMV) read | DE22, subfield 1 (POS Terminal PAN Entry Mode) = 07 | DE22, subfield 1 (Terminal Data: Card Data Capability) = M and subfield 7 (Card Data: Input Mode) = M |
| Contactless magnetic-stripe read | DE22, subfield 1 = 91 | DE22, subfield 1 = A and subfield 7 = A |
Same transaction, same DE number, different subfield layout, numeric codes on one side and letters on the other. A parser (or a reconciliation job) needs two DE22 decoders keyed by message family — the DE22 decoder on this site covers the authorization-side values.
The merchant category code lives in DE18 (Merchant Type) in authorization messages and in DE26 (Acceptor Business Code) in clearing messages. In the 1987 dictionary DE26 is something else entirely (a POS PIN-capture code), so looking up "DE26" in an authorization field table while holding a clearing record sends you in exactly the wrong direction. Look the value itself up with the MCC lookup.
In authorization messages, Mastercard packs private data into DE48 subelements. In clearing messages the equivalent facts travel as PDS (Private Data Subelement) tags. The public rules name several pairs explicitly:
| Business fact | Authorization 0100/0200 | First Presentment/1240 |
|---|---|---|
| Transaction Type Identifier (TTI), e.g. for payment and funding transactions | DE48, subelement 77 | PDS 0043 |
| Transit program data (Transit Transaction Type Indicator in subfield 1) | DE48, subelement 64 | PDS 0210 |
| Merchant country of origin (Home Country ID) | DE48, subelement 37, subfield 4 | PDS 0213 |
| MPOS acceptance device type | DE48, subelement 21 (Acceptance Data), subfield 1 | PDS 0018 (Acceptance Data), subfield 1 |
Two things worth noticing. First, the numbering is unrelated — subelement 77 becomes PDS 0043; nothing about a DE48 subelement number predicts its PDS tag. Second, some DE48 residents have no clearing counterpart in the public rules at all: the Transaction Category Code (TCC), a single letter in DE48 subfield 1 with values like P for payment transactions, X for airlines and transport, U for gambling, is referenced by the rules only on the authorization side.
Some facts don't just get renamed — they move to a structurally different place. The publicly documented examples:
| Fact | Authorization 0100/0200 | First Presentment/1240 |
|---|---|---|
| Transaction occurred at an MPOS terminal | DE61 (Point-of-Service Data), subfield 10 (Cardholder-Activated Terminal Level) = 9 | PDS 0023 (Terminal Type) = CT9 |
| Chip-only MPOS terminal | DE61, subfield 11 (POS Card Data Terminal Input Capability Indicator) = 9 | DE22, subfield 1 = E |
| Trace ID linking a message back to the original authorization | DE48, subelement 63 (Trace ID) | DE63 (Transaction Life Cycle ID), subfield 2 (Trace ID) |
On the authorization side the fact sits inside DE61's fixed subfield grid or a DE48 subelement; on the clearing side it is a PDS tag or a different DE altogether. If you filter MPOS traffic by DE61 in an authorization feed and by the same DE61 logic in a clearing feed, the clearing filter silently matches nothing.
A few transaction types never generate the authorization leg at all, so their identification exists only in the clearing dictionary. The public example is the transit First Ride Risk (FRR) claim: when an issuer declines a contactless transit tap, the transit operator can, under set conditions, claim the first fare directly in clearing. The rules state that an FRR claim does not require authorization and is identified in the First Presentment/1240 by 08 (First Ride Risk Claim) in PDS 0210, subfield 1 — there is no authorization-side twin to look for. (Its sibling, transit debt recovery, does have both sides: 07 in DE48 SE64 subfield 1 and in PDS 0210 subfield 1.)
The reverse direction exists too: identifiers born in authorization that must be echoed into clearing. The Transaction Link Identifier (TLID) that Mastercard assigns in the 0110/0210 response must be carried into the First Presentment/1240 in DE105 — covered in detail in the DE105 worked example.