
In payment systems, especially in EMV-based debit card transactions, the PIN verification step is decisive for both security and the liability chain.
But what if the card is closed to offline PIN and works only with online PIN, yet the POS device still sends the transaction to the issuer without a PIN?
And more importantly: if the issuer approves this transaction, who is liable?
Definition of the Situation
The scenario unfolds as follows:
- The card is an online PIN-enabled debit card.
- Offline PIN counter = 0 (meaning there are no offline PIN attempts left on the card).
- The POS device reads this information from the card.
- The kernel misinterprets it and, assuming "PIN try limit exceeded", starts a no-PIN transaction flow.
- The transaction goes online to the issuer without PIN data (DE52 empty).
- The issuer then approves this transaction (Response Code 00).
Result: A card that requires online PIN, a transaction approved without a PIN.
The Flow from the EMV Perspective
CVM (Cardholder Verification Method) selection follows the "CVM Decision Tree" in EMV Book 3.
The card's CVM list usually has the following priority:
- Online PIN
- Offline PIN (if available)
- No CVM
The card tells the POS to "use online PIN", but when the terminal sees offline PIN counter = 0, it skips the CVM step and selects the "no CVM" flow.
In this case, the POS sends a message to the issuer with the following fields:
| EMV Tag | Field | Value | Description |
|---|---|---|---|
| 9F34 | CVM Results | 0x1E | No CVM performed |
| 9F33 | Terminal Capabilities | Online PIN supported | |
| 9F35 | Terminal Type | Online-Only Terminal |
In other words, the terminal says "I support PIN" but reports the result "I did not perform PIN".
This is exactly the point where liability is determined.
ISO 8583 Message Flow
| Field (DE) | Description | Value Sent | Note |
|---|---|---|---|
| DE 3 | Processing Code | 000000 | Sale |
| DE 22 | POS Entry Mode | 051 | Chip + Online |
| DE 52 | PIN Data | None | Critical omission |
| DE 55 | EMV Data | CVM=No CVM | 9F34: 0x1E |
| DE 39 | Response Code | 00 | Issuer approved |
Normally, when the DE52 (PIN Data) field is missing, the issuer should return RSP=55 (Incorrect PIN) or 57 (Not permitted). However, if the issuer system approves the transaction without a PIN, this means a CVM bypass approval.
Liability Analysis
| Party | Situation | Liability |
|---|---|---|
| Acquirer / POS | The terminal evaluates the CVM list incorrectly. When Offline PIN counter = 0, it sends the transaction without a PIN. | There is a terminal configuration error, but the responsibility for approving the transaction rests with the issuer. |
| Issuer (Card-Issuing Bank) | A transaction for a card that requires online PIN arrives without a PIN. It is approved nonetheless. | The moment it approves the transaction, liability shifts to the issuer. In case of fraud or chargeback, the issuer is liable. |
| Network (Visa / Mastercard) | If a CVM result mismatch is detected, liability remains with the issuer. | In scheme dispute processes, the decision goes against the issuer. |
In short, the rule is:
"Who approves, owns the risk."
That is, whoever approves a transaction without a PIN is responsible for any loss that follows.
Visual Flow: EMV & Authorization Process
Card (Online PIN Required)
│
▼
POS → Offline PIN Counter = 0
│
▼
CVM Decision → No CVM selected (incorrect)
│
▼
0100 → Issuer (DE52 empty, DE55 CVM=No CVM)
│
▼
Issuer → Approved (RSP=00)
│
▼
Transaction approved without PIN → Liability = Issuer
Recommended Solutions
- POS kernel update: Even when the Offline PIN counter = 0, if the "Online PIN required" flag is present, the PIN screen must be shown.
- Issuer validation: Transactions arriving with an empty DE52 (PIN Data) must be declined or put through risk-based analysis.
- Network monitoring: CVM mismatch events should be checked regularly in scheme reports.
- Transaction log analysis: Terminal behavior should be monitored using the 9F34, 9F33 and 9F35 fields inside DE55.
Conclusion
When the offline PIN counter value is zero, the behavior of the terminal is critically important.
However, once the transaction reaches the online authorization process, final liability lies with the approving party, that is, the issuer.
The POS may have behaved incorrectly, but if the issuer approved the transaction without a PIN, the risk of fraud, chargeback or financial loss has passed to the issuer with that decision.



