Dissecting DE 55: BER-TLV Parsing & ARQC Validation in MTIP Environments

What DE 55 actually contains

Data Element 55 in an ISO 8583 authorisation request carries the EMV chip data — specifically, the BER-TLV (Basic Encoding Rules Tag-Length-Value) data objects that the ICC assembled during the terminal's offline data authentication and transaction processing steps. In a contact EMV transaction, DE 55 is populated by the terminal after the GENERATE AC command returns the first Application Cryptogram (AC).

The field itself is variable-length, binary, and in MTIP environments it is mandatory in 0100 and 0200 financial messages whenever the transaction was processed by an EMV-capable card and terminal. The maximum length is 255 bytes in ISO 8583:1993 (a single byte length subfield) — many acquirer host developers make the mistake of coding only for this limit and then failing on ARQC responses that include the full Issuer Application Data (IAD) and Issuer Script results, which in Mastercard implementations can push DE 55 towards the ISO 8583:2003 extended length range.

Mandatory vs conditional tags

Not every tag in the EMVCo tag registry is required in DE 55. MTIP specifies which tags are mandatory, conditional, and optional for each transaction type. A common certification failure is omitting a tag the scheme considers mandatory for the test case — for example, tag 9F34 (CVM Results) is conditional on whether a CVM was performed, but MTIP test cases that include an offline PIN verification step will reject a DE 55 without it.

Common ARQC failure modes

The ARQC (Authorisation Request Cryptogram) is generated by the ICC's Application Cryptography Module using the GENERATE AC command. The issuer re-derives the session key and independently computes the expected cryptogram. If the values do not match, the issuer should decline and may set the ARQC validation bit in the Issuer Application Data returned in the response DE 55. The most common failure modes in MTIP environments are:

• Session key derivation mismatch — the issuer uses a different derivation method (Common Session Key, Unique DEA Key, or Mastercard method) than the card was personalised with.
• ATC not checked against the issuer's ATC counter — an ATC lower than the last seen value indicates a replay attack; an ATC gap exceeding the host's tolerance window triggers decline even when the cryptogram is valid.
• IAD length miscalculation — the issuer parsing the IAD at a fixed offset instead of reading the format indicator byte, which specifies which IAD format the card uses (CCD, M/Chip, Visa Chip).
• Wrong LMK encryption in HSM — the application cryptographic key is encrypted under the wrong LMK header, causing the HSM to derive a different diversified key.

Before your MTIP certification day

Run every planned test case through a simulator environment with DE 55 logging enabled. Parse the BER-TLV output and verify each mandatory tag is present, correctly encoded (primitive vs constructed), and within the defined value range. Pay particular attention to the AIP (tag 82) — if the card has SDA set in byte 1, bit 8, but the terminal does not support SDA, the TVR bit 3 of byte 1 will be set and some scheme test cases will specifically check that the issuer correctly handles this scenario.

ARQC validation should be tested with a known-good HSM environment producing matching cryptograms before you submit a single test case to the scheme. A failed ARQC on submission day cannot be retested within the same certification window.