Decoding EMV Field 55: A Complete Guide to Chip Card Data
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]
| Component | Description | Example |
|---|---|---|
| Tag | 1-3 bytes identifying the data element | 9F26 |
| Length | Number of bytes in the value | 08 (8 bytes) |
| Value | The actual data | DEADBEEF12345678 |
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 β
xFpattern (e.g.,9F26,5F34) - Three-byte tags: Continuation indicated by bit 8 (e.g.,
DF8101)
Length Encoding
| Length Value | Meaning |
|---|---|
00-7F | Direct length (0-127 bytes) |
81 xx | Next byte is length (128-255 bytes) |
82 xx xx | Next 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 Type | Meaning |
|---|---|
| ARQC | Authorization Request Cryptogram - go online |
| TC | Transaction Certificate - approved offline |
| AAC | Application 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:
| Value | Meaning |
|---|---|
00 | AAC (Declined offline) |
40 | TC (Approved offline) |
80 | ARQC (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):
| Byte | Meaning |
|---|---|
| 1 | CVM Performed (e.g., 02 = Online PIN) |
| 2 | CVM Condition (e.g., 00 = Always) |
| 3 | CVM Result (e.g., 02 = Successful) |
Common CVM codes:
010000- Plaintext PIN verified020000- Enciphered PIN verified online1E0000- Signature required1F0000- No CVM performed3F0002- 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 8 | Offline data authentication not performed |
| Bit 7 | SDA failed |
| Bit 6 | ICC data missing |
| Bit 5 | Card on terminal exception file |
| Bit 4 | DDA failed |
| Bit 3 | CDA failed |
| Bit (Byte 2) | Meaning |
|---|---|
| Bit 8 | ICC and terminal versions different |
| Bit 7 | Expired application |
| Bit 6 | Application not yet effective |
| Bit 5 | Service not allowed |
| Bit 4 | New 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
| Tag | Name | Description |
|---|---|---|
| 9F02 | Amount, Authorised | Transaction amount (12 digits, implicit decimals) |
| 9F03 | Amount, Other | Cashback amount |
| 5F2A | Transaction Currency | ISO 4217 currency code |
| 9A | Transaction Date | YYMMDD format |
| 9C | Transaction Type | 00=Purchase, 01=Cash, 20=Refund |
Card Brand-Specific Tags
Different card networks add their own proprietary tags:
Visa payWave / qVSDC
| Tag | Name |
|---|---|
| 9F66 | Terminal Transaction Qualifiers (TTQ) |
| 9F6C | Card Transaction Qualifiers (CTQ) |
| 9F6E | Form Factor Indicator |
Mastercard M/Chip
| Tag | Name |
|---|---|
| 9F6C | Mag Stripe Application Version Number |
| 9F68 | Card Additional Processes |
| DF8102 | Application Capabilities Information |
Discover D-PAS
| Tag | Name |
|---|---|
| 9F7C | Customer Exclusive Data (CED) |
| DF8117 | Card Data Input Capability |
American Express Expresspay
| Tag | Name |
|---|---|
| 9F6E | Expresspay Terminal Capabilities |
| DF8108 | Minimum Cardholder Verification Threshold |
Parsing Field 55: Complete Example
Here’s a real-world Field 55 value:
9F2608A8E0B1C2D3E4F5069F27018095050000000000
9F100706010A03A4000082021980940804010100
Let’s decode it:
| Tag | Length | Value | Meaning |
|---|---|---|---|
| 9F26 | 08 | A8E0B1C2D3E4F506 | Application Cryptogram |
| 9F27 | 01 | 80 | ARQC requested |
| 95 | 05 | 0000000000 | TVR - all checks passed |
| 9F10 | 07 | 06010A03A40000 | Issuer Application Data |
| 82 | 02 | 1980 | Application Interchange Profile |
| 94 | 08 | 04010100 | Application 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:
9F10IAD for correct key derivation9F36ATC for sequence gaps9F37UN 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,9F379F02,9F03,5F2A,9A,9C9F1A(Terminal Country Code)
Quick Reference Table
| Tag | Bytes | Name | Critical? |
|---|---|---|---|
| 9F26 | 8 | Application Cryptogram | β |
| 9F27 | 1 | Cryptogram Information Data | β |
| 9F10 | var | Issuer Application Data | β |
| 95 | 5 | Terminal Verification Results | β |
| 9F34 | 3 | CVM Results | β |
| 9F36 | 2 | Application Transaction Counter | β |
| 9F37 | 4 | Unpredictable Number | β |
| 9F02 | 6 | Amount, Authorised | β οΈ |
| 9F03 | 6 | Amount, Other | β οΈ |
| 5F2A | 2 | Transaction Currency Code | β οΈ |
| 9A | 3 | Transaction Date | β οΈ |
| 9C | 1 | Transaction Type | β οΈ |
Next Steps
Now that you understand Field 55:
- Decode your data with the EMV Tag Inspector
- Look up any tag in our Reference Database
- Parse full messages with the ISO 8583 Studio
- Review the basics in our ISO 8583 Message Structure Guide
- Understand HSM verification in our HSM Basics Guide β how HSMs verify the ARQC cryptogram from Field 55
- Learn POS entry modes in our POS Entry Mode Guide β entry modes 05 and 07 trigger chip data in Field 55
- Understand offline authentication in our SDA vs DDA vs CDA Guide β how the TVR bits in Field 55 report SDA/DDA/CDA results
- 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
π¬ Discussion
Have a question or feedback? Leave a comment below β powered by GitHub Discussions.
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.