These three digits set the security tier of the transaction — which drives both the interchange rate and who eats the fraud.
| Code | Meaning |
|---|---|
00 | Unknown |
01 | Manual key entry |
02 | Magnetic stripe read |
03 | Bar code |
04 | OCR |
05 | Chip (ICC), CVV reliable |
07 | Contactless chip (EMV) |
10 | Credential on file |
80 | Fallback from chip to magnetic stripe |
81 | E-commerce |
90 | Magnetic stripe, full track read |
91 | Contactless magnetic stripe |
95 | Chip, CVV/iCVV unreliable |
| Code | Meaning |
|---|---|
0 | Unspecified |
1 | PIN entry capable |
2 | Not PIN entry capable |
8 | Reserved |
9 | Capable but PIN not used this time |
The first two digits of DE22 say how the card number got in: swiped, dipped, keyed, tapped, or entered online with no card present. The third says whether the terminal can take a PIN.
Those digits map directly onto two things that cost real money: the interchange tier (more secure entry modes generally price lower) and fraud liability. For the same disputed transaction, a chip read and a keyed entry can land liability on opposite parties.
80 (fallback from chip to magstripe) means the card has a chip but reading it failed, so the terminal fell back to the stripe. This is a classic fraud technique — a counterfeit card carries a deliberately dead chip to force the fallback. Risk engines usually tighten rules on fallback transactions, and many issuers decline cross-border fallbacks outright.
95 (chip present but CVV unreliable) deserves the same attention: the data came from a chip, but the verification value cannot be trusted, so treat the risk as closer to a magstripe transaction than a chip one.
80, the terminal failed to read the chip and fell back. The problem is at the terminal or the card, not the issuer.
DE22 is n-3 in the 1987 edition of ISO 8583 — two digits of PAN entry mode plus one
of PIN entry capability, which is what the decoder above expects. From the 1993 edition the field
is an-12 and is called the point of service data code: twelve characters carrying
twelve separate subfields, of which the card-reading method is only one.
Both are in use at once. Authorization messages are 1987-format, so a three-character DE22 is what you see on the authorization leg. Clearing records are 1993-format, so the same transaction carries the twelve-character version there. A value that looks malformed is often the other edition read with the wrong expectation rather than bad data.
The consequence for triage: you cannot compare a DE22 from an authorization log with a DE22 from a clearing file position by position. The reading method is in the first two characters of the short form and at a different offset in the long one. Every value in both forms, and which reading shifts fraud liability, is in POS entry mode codes.