Back when I was integrating a POS system for a merchant in the Philippines, one of our biggest headaches was interpreting EMV data, especially when certification time came. At first, all these TLVs looked like encrypted gibberish. But over time, they started to make sense and actually became helpful for debugging issues in the field.
In this post, I’ll share the 25 most important EMV tags that helped me during development, testing and even production support. If you’re doing EMV certification, payment gateway integration, or even just building TLV parsers, this post is for you.
What’s an EMV Tag, Again?
Before we go deep, just a quick recap, EMV uses TLV format:
Tag Length Value
---- ------ ------
9F02 06 000000010000- Tag – tells you what kind of data it is
- Length – how many bytes the value contains
- Value – the actual content (usually hex)
Let’s Break Down the 25 Tags
Cardholder & Transaction Info
1. 9F02 – Amount, Authorized (Transaction)
The actual amount the cardholder is being charged. It’s always 6 bytes, encoded as a numeric string. This is mandatory in DE55, and if this amount mismatches what’s shown on the POS or passed to the acquirer, the transaction can be declined.
Value: 000000010000 => 100.002. 9F03 – Amount, Other (e.g. Cashback, Tip)
Used when a transaction includes a second amount like cashback or service fee. Not all schemes require this, but Mastercard can be strict about it during testing.
Value: 000000001500 => 15.003. 9F1A – Terminal Country Code
2-byte numeric ISO 3166-1 country code. Philippines is 0608. If this mismatches your merchant profile on the acquirer side, transactions might fail KYC checks or regulatory validation.
4. 5F2A – Transaction Currency Code
Currency of the transaction, also in ISO 4217 numeric format.
Value: 0608 => Philippine PesoPlease be careful with this. I had an issue last time where one terminal had the wrong configuration and was sending 0840 (USD) for PHP merchants. It caused massive confusion with the settlement amounts.
5. 9A – Transaction Date
Format is YYMMDD. The card needs this to validate freshness of cryptogram or risk logic.
Value: 240726 => July 26, 2024The terminal and host must have synchronized clocks. Skewed time can cause ARQC rejection.
6. 9F21 – Transaction Time
Format is HHMMSS.
Value: 142201 => 2:22:01 PMUsed by host systems for logs, fraud checks, and velocity checks (e.g., how often user is swiping).
7. 9C – Transaction Type
Identifies what the customer is trying to do.
00 => Purchase
01 => Cash Withdrawal
20 => RefundSome schemes have specific rules for pre-auth (03) and refund (20) which require additional tags.
Terminal & Interface Info
8. 9F1E – Interface Device Serial Number
This tag contains the unique serial number assigned to the terminal hardware, usually 8 alphanumeric characters.
This helps acquirers and payment processors track exactly which device performed the transaction. During troubleshooting, especially in large retail environments where thousands of terminals are deployed, this is your fingerprint. If one terminal consistently causes issues maybe generating bad cryptograms or failing certain scripts, the acquirer will look at this value to pinpoint which device is misbehaving.
We had a rollout with 300 terminals across multiple locations. One location kept failing PIN verification. The acquirer asked for the 9F1E value from the failed logs. That’s how we discovered one faulty batch of devices with bad keypads, this tag saved us hours of manual checking.
9. 9F35 – Terminal Type
A 1-byte value that classifies the terminal into a general category like attended POS, ATM, mobile device, or unattended kiosk.
Common Values:
- 14 = Unattended, offline-only
- 21 = Mobile, contactless capable
- 22 = Attended POS, offline-capable
This tag plays a role in determining how the card behaves, especially during application selection and risk management. A card might allow offline approvals if it’s at an attended terminal but refuse them if the terminal is unattended. So if this value is wrong, the card may decline unexpectedly.
During one test, our terminal sent 22, which means attended POS, but the tester was simulating an unattended vending machine. The card rejected the transaction, thinking it was being used fraudulently in the wrong context. We had to fix the kernel configuration to report the right terminal type.
10. 9F33 – Terminal Capabilities
This is a 3-byte bitmap that tells what the terminal is technically capable of things like offline PIN, signature support, magnetic stripe fallback, or EMV SDA/DDA support. This tag helps the card decide how much trust it can place in the terminal. For example, if the terminal doesn’t support offline PIN, but the card prefers it, the flow may change to online or fail altogether.
Don’t hardcode this unless you fully understand each bit’s meaning. We once accidentally set this to indicate support for SDA and offline PIN, but the terminal didn’t have a secure keypad. It caused the card to attempt offline PIN, which of course failed. Always double-check your 9F33 value against the EMV Book 4 specs and your actual hardware features.
11. 9F40 – Additional Terminal Capabilities
A 5-byte bitmap that adds more detail to 9F33. It covers features like contactless support, CVM methods (PIN, signature), and whether the terminal supports issuer referrals or transaction log maintenance.
Think of this as an extension of the terminal’s CV (capability resume). Issuers look at this tag when deciding what kind of authentication or risk management to enforce. If the card thinks the terminal can do something like ask for offline PIN but the terminal actually can’t, the whole flow may break down.
We had a certification test with Visa where our 9F40 indicated support for offline PIN. But the device we submitted had no physical keypad only a touchscreen with no secure entry. We got a hard fail from the lab. We had to regenerate the kernel configuration and re-submit the test with corrected capabilities. That one mistake cost us 3 days of retesting.
Security & Cryptography
12. 9F26 – Application Cryptogram
This is the cryptographic signature generated by the card for the current transaction. It serves as the card’s “proof” that it’s genuine and that the transaction data hasn’t been tampered with.
The cryptogram is usually sent to the issuer for validation (in online mode). It’s like a cryptographic seal that says, “Yes, this is a real card and I approve this transaction.” Depending on the terminal/card behavior, this could be an ARQC (Authorization Request Cryptogram) or TC (Transaction Certificate).
9F26 08 A1B2C3D4E5F6A7B8During one EMV integration, our host wasn’t properly validating the ARQC. Even though the cryptogram was present, it was being ignored, which created a gap in our risk checks. It’s not enough to collect this your issuer or gateway needs to verify it using issuer keys.
13. 9F27 – Cryptogram Information Data
A 1-byte value that tells what type of cryptogram was generated by the card.
Common Values:
- 40 => ARQC (Authorization Request Cryptogram)
- 80 => TC (Transaction Certificate)
- 00 => AAC (Application Authentication Cryptogram — decline)
This tells the terminal or host how to process the cryptogram. If you were expecting an ARQC but received a TC, it may indicate the transaction was completed offline. If you get an AAC, that’s a straight decline from the card, no point trying to send it online.
Sample:
9F27 01 40Always log this. It saved us during a dispute where the merchant claimed a transaction was online-approved, but the tag showed 80 meaning it was completed offline by the card itself.
14. 9F10 – Issuer Application Data (IAD)
Contains issuer-defined cryptographic information, usually including CVR (Card Verification Results), key version numbers, and sometimes risk counters. Format is not standardized, it varies by scheme (Visa, Mastercard, etc.).
The IAD helps the issuer decide whether to approve the transaction. It may include hints about PIN verification status, offline data authentication results, or CVM outcomes.
Sample:
9F10 07 0610A000000000Don’t assume a fixed structure. In one project, we were parsing the first 2 bytes as CVR for all schemes but Visa and Mastercard had different layouts. It broke some risk checks silently. If you’re working with issuer systems, ask for the CVR/IAD decode guide for the scheme you’re integrating with.
15. 9F37 – Unpredictable Number
A 4-byte random number generated by the terminal. It’s used by the card during cryptogram generation to ensure each transaction is unique and cannot be replayed.
If this number is predictable (like just a timestamp or incrementing counter), it compromises the entire cryptographic process. That’s why most certifications require a secure RNG.
Sample:
9F37 04 4F3C28B1We had a QA build where this was hardcoded to 00000000 (just for testing). Someone accidentally deployed it to production, issuer rejected every transaction due to duplicate cryptogram challenges. Lesson: Never skip the RNG even in early tests.
16. 9F36 – Application Transaction Counter (ATC)
A 2-byte counter maintained by the card that increments with every transaction. This helps detect cloning. If two terminals report the same card with the same ATC, it might be a copied card. Some issuer systems track this and raise fraud flags.
9F36 02 01AF → Transaction #431During reconciliation, we found two different merchant IDs reporting the same PAN and ATC value. It led to an investigation where a cloned chip was confirmed.
17. 95 – Terminal Verification Results (TVR)
A 5-byte bitmap that tells which checks the terminal performed and which ones passed or failed.
Examples of bits:
- Byte 1, Bit 8 => Offline data authentication was not performed
- Byte 2, Bit 6 => Expired application
- Byte 3, Bit 1 => Cardholder verification failed
TVR gives context to the cryptogram what the terminal tried, what failed, and what risk factors were present. Issuers and acquirers rely on this to approve or reject the transaction.
Sample:
95 05 8000008000A transaction was declined, and we didn’t know why until we decoded the TVR. One bit indicated “Application expired.” The merchant had not updated their terminal date config for weeks. Use EMVCo Book 3 or Visa/Mastercard specs to decode each bit.
18. 9B – Transaction Status Information (TSI)
Another bitmap (2 bytes) that tells which functions were actually performed during the transaction (unlike TVR which shows what failed).
Example:
- Offline data authentication performed
- Cardholder verification performed
- Script processing done
This is like a transaction summary from the card’s point of view. It confirms what steps were actually completed not just attempted.
Sample:
9B 02 E800We used this tag to verify that offline PIN was processed correctly. In a test case, TVR showed that CVM failed, but TSI didn’t show offline PIN as performed which meant the terminal didn’t even try it.
Application Info & Selection
19. 4F – Application Identifier (AID)
This tag holds the AID, or Application Identifier a globally unique identifier that tells the terminal which application it’s dealing with on the card.
An AID is made up of two parts:
- RID (first 5 bytes) – identifies the card scheme (like Visa, Mastercard)
- PIX (rest of the bytes) – identifies the product or application version (credit, debit, etc.)
When the terminal sends a SELECT command, it uses this tag to choose which application on the card to activate. Some cards support multiple applications (e.g., Visa debit and credit), and the terminal picks based on priority, AID list, or cardholder choice.
Sample Values:
4F 07 A0000000031010 → Visa Credit
4F 07 A0000000041010 → Mastercard Credit
4F 07 A0000000032010 → Visa Debit We were working on a multi-AID environment with a dual-interface card. The kernel selected the wrong AID because of misconfigured terminal AID priority list. The result? Wrong CVM method and cardholder confusion. Always align terminal-supported AIDs with scheme rules and merchant expectations.
20. 50 – Application Label
This tag contains the human-readable name of the application selected from the card. It’s what usually gets displayed on the POS terminal screen when you insert your card.
It improves user experience. Imagine inserting your card and seeing “VISA CREDIT” or “MC DEBIT” that visual confirmation helps the cardholder feel safe and ensures they’re using the correct app.
Sample Values:
50 0A 5649534120435245444954 => "VISA CREDIT"
50 09 4D43204445424954 => "MC DEBIT"We had a terminal that skipped this tag and just printed “Application selected” on screen. Users were confused especially in countries where debit and credit are on the same card. After adding support for tag 50, support calls dropped.
Note: This tag is optional in some kernels. If missing, fallback to tag 9F12 (see next).
21. 9F12 – Application Preferred Name
A more descriptive, or even localized, version of the application name. It’s also displayed to the cardholder during selection, and may override tag 50 depending on terminal logic
In multilingual regions, this tag allows the card issuer to present the application name in the cardholder’s language. It also allows issuers to brand the card’s application (e.g., “VISA PLATINUM” instead of just “VISA CREDIT”).
Sample Values:
9F12 0C 5649534120504C4154494E554D => "VISA PLATINUM"
9F12 07 4D4320504F4E => "MC PON" For a project in LATAM, some cards used 9F12 to display “VISA DEBITO” instead of “VISA DEBIT” which was very important for local language support. If your POS ignores this tag, it might fail UX or scheme branding requirements.
Note: Some schemes require the terminal to display this over tag 50, especially if it’s present.
22. 5F34 – Application PAN Sequence Number
This is a 1-byte value used to distinguish between multiple applications or profiles on the same physical card particularly when the same PAN is shared across them.
Let’s say a customer’s card has two different AIDs (Visa Credit and Visa Debit) and both use the same PAN. This value helps the terminal or backend know which specific app version was used.
Sample Values:
5F34 01 => First application
5F34 02 => Second applicationDuring one reconciliation audit, we had two transactions with the same masked PAN but different 5F34 values. This allowed the issuer to trace which specific application was used and clarified why one was processed as credit and one as debit.
Note: Not all cards implement this, but when they do, your host or backend system should capture it especially if you rely on AID or CVM-based business rules.
Issuer & PAN Related
23. 5A – Application PAN (Primary Account Number)
This tag contains the cardholder’s PAN (card number), pulled directly from the chip application. It’s encoded in Binary Coded Decimal (BCD), and typically includes the full card number though often masked or truncated by the terminal for PCI compliance.
This is one of the most sensitive and crucial fields in an EMV transaction. The card’s PAN is used for routing, identifying the issuer, and generating the authorization request. It’s also tied to the CVV/CVC and other backend fraud controls.
Sample Values:
5A 08 5412123456789012Never log or display this full value not even in test environments. Masking is mandatory under PCI DSS. If you really need to log it, only keep the first 6 and last 4 digits. In a settlement mismatch case, we were comparing masked PANs and missed a duplicate because the 5A tag on one terminal was incorrectly truncated to 6 digits. Make sure your TLV parser and mask logic are aligned.
This tag is usually included with 5F34 (PAN Sequence Number) to uniquely identify the application.
24. 82 – Application Interchange Profile (AIP)
A 2-byte bitmap that tells the terminal which functions the card supports like offline data authentication (SDA/DDA), cardholder verification methods (CVM), and transaction certificates.
Some key bits in AIP:
- Byte 1, bit 8 => Supports SDA
- Byte 1, bit 7 => Supports DDA
- Byte 2, bit 8 => Cardholder verification is supported
- Byte 2, bit 4 => CDA (Combined DDA + AC generation) supported
When the terminal sends the GPO (Get Processing Options) command, the card responds with the AIP. This tells the terminal how the card expects to be handled in terms of risk management and CVM flow.
Sample Values:
82 02 7C00This value (binary) means:
- SDA and DDA are supported
- Offline PIN is supported
- No CDA (Combined Data Authentication)
A terminal we tested ignored the CDA bit in the AIP, and sent Generate AC requests incorrectly. This led to transaction rejections for some cards, especially newer ones that required CDA. AIP must be properly parsed and respected.
Always match AIP against TVR and TSI to see if the terminal respected the card’s advertised capabilities.
25. 84 – Dedicated File Name (DF Name)
This is the name of the application on the card in the file system. In practice, it’s almost always the same as the AID (tag 4F), but 84 comes from the SELECT command response, while 4F is from the card’s FCI template.
During the SELECT process (which is how terminal chooses which app on the card to talk to), the card responds with its DF Name. This helps confirm that the correct application has been selected.
Sample Values:
84 07 A0000000031010 → Visa Credit Application DFWe had a debugging session where SELECT was failing, and it turned out we were sending a partial AID instead of the full one. Once we checked the DF Name in the response, we were able to align the SELECT command properly with the full AID string.
Some cards respond only with tag 84, while others include both 4F and 84 in the FCI. Your terminal logic should account for both — especially when parsing SELECT responses.
Helpful Tools and References
I know this post was a bit long, but honestly, that’s what I wish I had back when I started dealing with EMV data. If someone just gave me a list like this, with plain explanations, real use cases, and notes from actual project issues, I would have saved so much time.
Whether you’re working on certification, building a TLV parser, decoding DE55 for a payment switch, or troubleshooting a card transaction in production, these 25 tags come up all the time. They’re like the “common words” in the EMV language.
And hey don’t worry if you can’t memorize all of them. Even now, I still keep a quick reference list open when debugging APDU responses or checking if an ARQC failed because of a missing tag.
