Buried in every DE55 is a two-byte number most parsers print and nobody reads: the Application Transaction Counter. The card adds one to it on every transaction attempt. That trivial habit is what makes every cryptogram single-use โ and it hands issuers the cheapest clone detector they own.
The ATC is a 16-bit unsigned counter that lives inside the chip, one per card application. The card increments it at every GENERATE AC โ approved or declined, online or offline. It never decrements and cannot be reset from outside; the only direction is up, until it runs out at 65535. A value of 004B simply means this application's 75th transaction attempt.
Two details in that sentence do a lot of work later. Per application: a card with two AIDs has two independent counters, so comparing an ATC from one against history from the other produces garbage. Attempt: declined and abandoned transactions consume numbers too, which is why the sequence an issuer sees has perfectly legitimate holes in it.
Every chip transaction carries an application cryptogram (tag 9F26 โ see the EMV tag lookup), a keyed MAC the card computes over the transaction data. Amount, date and the terminal's unpredictable number all feed it, but the ATC has a special role: in the usual derivation schemes it is the input that makes the session key itself different on every transaction. The cryptogram for attempt 75 is built from material that only attempt 75 will ever have.
That corners an attacker who captured a valid authorization message. Replay it unchanged, and the issuer receives ATC 75 twice โ instantly suspicious. Bump the ATC to 76, and the cryptogram no longer verifies, because recomputing it needs the secret key that never leaves the chip. Either way the replay dies at the issuer host, with no network-level defense involved. A counter plus a keyed MAC turns every authorization into a one-time message.
The card keeps a second register: the ATC of the last transaction that was authorized online, exposed as tag 9F13, the Last Online ATC Register. The terminal can read it during risk management and do one subtraction:
9F36 โ 9F13 = consecutive offline transactions since the issuer last saw this card
EMV gives each card a lower and an upper consecutive offline limit. When the delta crosses the lower limit the terminal should send the transaction online; past the upper limit the card is expected to decline offline outright. Those checks surface as the "consecutive offline limit exceeded" bits in TVR byte 4.
Concretely: 9F36 = 004B and 9F13 = 0047 is 75 โ 71 = 4 offline transactions since the last online authorization. Paste both values into the ATC decoder and it does the hex-to-decimal conversion and the subtraction for you.
Note the division of labour: the terminal uses 9F13 because it has no memory of the card. The issuer never needs 9F13 โ it has something better, its own authorization history.
Every online authorization delivers a fresh 9F36. The issuer looks up the highest ATC it has recorded for that application and asks one question: where does the new value land relative to that record? One number line covers every case:
Reading the three anomalies off the axis:
| Pattern | What it usually means |
|---|---|
| Duplicate (75 again) | The same counter value twice. In the real-time authorization stream that is a replayed cryptogram or a clone personalised from a snapshot of the card. In clearing it can also be an honest double submission โ check the rest of the record before escalating. |
| Big jump (97) | Twenty-two attempts the issuer never saw. Mostly benign โ a long offline run on a transit-style profile, offline declines, terminals that never submitted. But paired with an odd location or amount, it can be the first online sighting of a card that has been spending somewhere else. |
| Backwards (72) | A chip cannot count down. A live authorization carrying an ATC below the recorded high means the message came from a different piece of silicon sharing this PAN and keys โ the classic cloned-card signature, and the pattern behind "ATC mismatch / ATC out of range" decline reasons in issuer host logs. The only benign version lives in clearing, where offline transactions surface days late and out of order. |
Issuer velocity rules often decline when the incoming ATC lands outside the window โ the declines analysts see logged as ATC mismatch. Worth being precise about what that does and does not prove. A non-consecutive ATC has plenty of innocent causes:
So a gap, by itself, is noise. The strong signals are the ones a genuine card cannot produce in the authorization stream: the same value twice, and a value that moves backwards. Hosts that decline on any non-consecutive ATC mostly harvest false positives from transit commuters; hosts that ignore duplicates and reversals miss the one field where a clone is structurally forced to give itself away.