Decoding EMV Field 55: A Complete Guide to Chip Card Data

6 min read
ISO 8583 Guides

Field 55 is where the magic happens in chip card transactions. This guide takes you deep into the world of EMV dataβ€”how it’s structured, what the critical tags mean, and how to decode it like a pro.

What is Field 55?

Field 55 in ISO 8583 contains Integrated Circuit Card (ICC) data from chip card transactions. When a cardholder inserts or taps their EMV card, the terminal collects cryptographic and transaction data from the chip, encodes it in BER-TLV format, and stuffs it into Field 55.

This data is essential for:

  • Fraud prevention - Cryptograms prove the card was present
  • Issuer authorization - Risk decisions based on card behavior
  • Chargeback protection - Liability shift evidence

Try it yourself: Paste Field 55 data into our EMV Tag Inspector to see it decoded in real-time.

BER-TLV: The Encoding Format

EMV data uses BER-TLV (Basic Encoding Rules - Tag Length Value) encoding. Each data element consists of three parts:

[TAG][LENGTH][VALUE]
ComponentDescriptionExample
Tag1-3 bytes identifying the data element9F26
LengthNumber of bytes in the value08 (8 bytes)
ValueThe actual dataDEADBEEF12345678

Tag Byte Rules

  • Single-byte tags: If bits 1-5 are NOT all 1s (e.g., 5A, 95, 82)
  • Two-byte tags: If bits 1-5 ARE all 1s β†’ xF pattern (e.g., 9F26, 5F34)
  • Three-byte tags: Continuation indicated by bit 8 (e.g., DF8101)

Length Encoding

Length ValueMeaning
00-7FDirect length (0-127 bytes)
81 xxNext byte is length (128-255 bytes)
82 xx xxNext 2 bytes are length (256-65535 bytes)

Real Example

9F2608DEADBEEF12345678
β”‚ β”‚ └─────── Value: DEADBEEF12345678 (8 bytes)
β”‚ └───────── Length: 08 (8 bytes)
└─────────── Tag: 9F26 (Application Cryptogram)

Critical EMV Tags

These are the tags you’ll encounter most often in authorization messages:

9F26 - Application Cryptogram

The most important tag in Field 55. This 8-byte cryptographic value proves the card chip generated this transaction.

Cryptogram TypeMeaning
ARQCAuthorization Request Cryptogram - go online
TCTransaction Certificate - approved offline
AACApplication Authentication Cryptogram - declined offline
9F2608A1B2C3D4E5F60708

The cryptogram is verified by the issuer’s Host Security Module (HSM).

9F27 - Cryptogram Information Data (CID)

A single byte that indicates which type of cryptogram was generated:

ValueMeaning
00AAC (Declined offline)
40TC (Approved offline)
80ARQC (Online authorization requested)

9F10 - Issuer Application Data

Proprietary data from the card for the issuer. This varies by card brand and may contain:

  • Card Verification Results (CVR)
  • Counters for risk management
  • Key derivation information

9F34 - CVM Results

Shows how the cardholder was verified (3 bytes):

ByteMeaning
1CVM Performed (e.g., 02 = Online PIN)
2CVM Condition (e.g., 00 = Always)
3CVM Result (e.g., 02 = Successful)

Common CVM codes:

  • 010000 - Plaintext PIN verified
  • 020000 - Enciphered PIN verified online
  • 1E0000 - Signature required
  • 1F0000 - No CVM performed
  • 3F0002 - Cardholder Device CVM (mobile wallets)

95 - Terminal Verification Results (TVR)

5 bytes indicating what checks passed or failed at the terminal:

Bit (Byte 1)Meaning
Bit 8Offline data authentication not performed
Bit 7SDA failed
Bit 6ICC data missing
Bit 5Card on terminal exception file
Bit 4DDA failed
Bit 3CDA failed
Bit (Byte 2)Meaning
Bit 8ICC and terminal versions different
Bit 7Expired application
Bit 6Application not yet effective
Bit 5Service not allowed
Bit 4New card

9F36 - Application Transaction Counter (ATC)

A 2-byte counter that increments with each transaction. Used for:

  • Detecting cloned cards
  • Transaction sequence tracking
  • Risk velocity checks
9F36020123  β†’ ATC value: 0123 (291 transactions)

9F37 - Unpredictable Number

4 random bytes generated by the terminal to prevent replay attacks. This value is included in the cryptogram calculation.

Transaction Data Tags

TagNameDescription
9F02Amount, AuthorisedTransaction amount (12 digits, implicit decimals)
9F03Amount, OtherCashback amount
5F2ATransaction CurrencyISO 4217 currency code
9ATransaction DateYYMMDD format
9CTransaction Type00=Purchase, 01=Cash, 20=Refund

Card Brand-Specific Tags

Different card networks add their own proprietary tags:

Visa payWave / qVSDC

TagName
9F66Terminal Transaction Qualifiers (TTQ)
9F6CCard Transaction Qualifiers (CTQ)
9F6EForm Factor Indicator

Mastercard M/Chip

TagName
9F6CMag Stripe Application Version Number
9F68Card Additional Processes
DF8102Application Capabilities Information

Discover D-PAS

TagName
9F7CCustomer Exclusive Data (CED)
DF8117Card Data Input Capability

American Express Expresspay

TagName
9F6EExpresspay Terminal Capabilities
DF8108Minimum Cardholder Verification Threshold

Parsing Field 55: Complete Example

Here’s a real-world Field 55 value:

9F2608A8E0B1C2D3E4F5069F27018095050000000000
9F100706010A03A4000082021980940804010100

Let’s decode it:

TagLengthValueMeaning
9F2608A8E0B1C2D3E4F506Application Cryptogram
9F270180ARQC requested
95050000000000TVR - all checks passed
9F100706010A03A40000Issuer Application Data
82021980Application Interchange Profile
940804010100Application File Locator

Decode your own: Use our EMV Tag Inspector for instant parsing.

Common Issues & Troubleshooting

“Cryptographic Failure” (Response 81)

The ARQC didn’t verify at the issuer. Check:

  • 9F10 IAD for correct key derivation
  • 9F36 ATC for sequence gaps
  • 9F37 UN for uniqueness

“Invalid Card” Responses

Look at TVR (95) for:

  • Expired application (byte 2, bit 7)
  • DDA/CDA failures (byte 1, bits 4-3)

Missing Required Tags

Some issuers require specific tags. Common requirements:

  • 9F26, 9F27, 9F10, 95, 9F36, 9F37
  • 9F02, 9F03, 5F2A, 9A, 9C
  • 9F1A (Terminal Country Code)

Quick Reference Table

TagBytesNameCritical?
9F268Application Cryptogramβœ…
9F271Cryptogram Information Dataβœ…
9F10varIssuer Application Dataβœ…
955Terminal Verification Resultsβœ…
9F343CVM Resultsβœ…
9F362Application Transaction Counterβœ…
9F374Unpredictable Numberβœ…
9F026Amount, Authorised⚠️
9F036Amount, Other⚠️
5F2A2Transaction Currency Code⚠️
9A3Transaction Date⚠️
9C1Transaction Type⚠️

Next Steps

Now that you understand Field 55:

  1. Decode your data with the EMV Tag Inspector
  2. Look up any tag in our Reference Database
  3. Parse full messages with the ISO 8583 Studio
  4. Review the basics in our ISO 8583 Message Structure Guide
  5. Understand HSM verification in our HSM Basics Guide β€” how HSMs verify the ARQC cryptogram from Field 55
  6. Learn POS entry modes in our POS Entry Mode Guide β€” entry modes 05 and 07 trigger chip data in Field 55
  7. Understand offline authentication in our SDA vs DDA vs CDA Guide β€” how the TVR bits in Field 55 report SDA/DDA/CDA results
  8. Learn about the quantum threat in our Post-Quantum Cryptography in Payments Guide β€” understand why ML-DSA signatures will break Field 55 constraints.

This post is part of the ISO 8583 Mastery series. Follow along as we explore payment messaging in depth.

Related Posts

Understanding ISO 8583 Message Structure
Jan 30, 2026 4 min

πŸ’¬ Discussion

Have a question or feedback? Leave a comment below β€” powered by GitHub Discussions.

❓ Frequently Asked Questions

What is ISO 8583 Field 55?

Field 55 contains Integrated Circuit Card (ICC) System Related Dataβ€”the critical cryptographic payload generated by the EMV chip and the terminal during a transaction.

How is data formatted inside Field 55?

Field 55 is formatted using BER-TLV (Basic Encoding Rules - Tag Length Value). It consists of dozens of nested, variable-length tags like the Application Cryptogram (Tag 9F26) and Terminal Verification Results (Tag 95).

Why is Field 55 required to be passed unaltered?

The data in Field 55 is cryptographically signed by the EMV chip. If a payment gateway alters, pads, or truncates any part of Field 55, the issuer’s verification of the Application Cryptogram (ARQC) will fail, resulting in a declined transaction.

\n