How a Card Network Detects a Replay Attack

Every card transaction produces a packet of data — account numbers, amounts, timestamps, and authentication values — that travels from a terminal through a card network to an issuing bank. A man-in-the-middle (MITM) replay attack intercepts that packet in transit and retransmits it, either immediately or after a delay, in an attempt to authorize a duplicate charge without possessing the physical card or its PIN.

The machinery that defeats this attack operates at several layers simultaneously: the EMV chip's cryptographic counter, the network's duplicate-detection engine, and the tokenization infrastructure that replaces the real account number with a surrogate value. This piece describes how those layers interact during a live authorization and where each one contributes to identifying a replayed transaction.

How the Cryptographic Counter and Network Auth Check Operate in Order

When an EMV chip card is inserted into a terminal, the chip and the terminal engage in a mutual authentication exchange. The chip generates an Application Cryptogram (AC) — a value computed from the transaction amount, the terminal's unpredictable number, and an internal counter called the Application Transaction Counter (ATC). The ATC increments by exactly one for every transaction the chip processes. The resulting cryptogram is unique to that specific transaction and cannot be reproduced without the chip's private key.

The authorization request that leaves the terminal includes the cryptogram and the current ATC value. When the request reaches the issuing bank (routed through the card network), the bank's host system performs offline data authentication: it decrypts the cryptogram using the card's public key certificate, recomputes the expected value from the transaction data, and compares the two. If they match, the ATC is then compared against the last ATC value stored for that card. A replayed message would carry a stale ATC — one the bank has already seen or one that falls below the expected sequence — and the mismatch causes an immediate decline.

The card network's own authorization infrastructure adds a second layer. The network maintains a transaction log indexed by a combination of the card's primary account number (or its token equivalent), the terminal ID, the transaction amount, and the retrieval reference number (RRN) — a unique identifier assigned at the point of sale. Before forwarding any authorization request to the issuer, the network queries this log for a matching record within a defined time window, typically 24 to 72 hours. A packet that arrives with an RRN already present in the log is flagged as a potential duplicate and either declined outright or routed for manual review. This mechanism is the same engine described in how card networks detect duplicate transaction fraud more broadly, though MITM replay introduces the additional complexity of a cryptographically valid-looking packet.

A third check occurs at the network's BIN (Bank Identification Number) validation stage. The network confirms that the BIN embedded in the account number maps to an active issuer and that the card's status has not changed since the intercepted packet was captured. BIN verification before authorization is a routine step, but it becomes a meaningful barrier in replay scenarios where the card has since been reported lost or the account closed.

Parties and Components Involved in Replay Detection

The EMV chip and its cryptographic engine. The chip holds a private key that never leaves the card. It uses that key to sign each transaction's Application Cryptogram. Because the private key is hardware-bound, an attacker who captures a transmitted cryptogram cannot generate a new, valid one for a different transaction — they can only replay the exact packet they intercepted.

The terminal's unpredictable number (UN). Each terminal generates a fresh random value for every transaction and includes it in the data the chip signs. This means the cryptogram is bound not only to the transaction amount and ATC but also to a value the attacker cannot predict for a future transaction. Even if an attacker captures the full authorization packet, replaying it against a different terminal session will produce a cryptogram mismatch at the issuer.

Tokenization infrastructure. Many modern card transactions — particularly those processed through digital wallets or in-app payments — replace the card's real account number with a payment token: a surrogate number that is valid only for a specific merchant, device, or channel. Tokenization means that even a successfully intercepted packet carries a token rather than the underlying account number. The token vault at the network or issuer maps tokens to real accounts, but a token captured from one merchant context will be rejected if replayed in a different context, because the token's domain restrictions are checked at authorization time.

The issuing bank's authorization host. The issuer performs the final cryptogram verification and ATC sequence check. It holds the card's public key certificate (delivered via the card's chip data) and the last-seen ATC. The issuer's decision — approve, decline, or refer — is the terminal point of the detection chain.

The card network's routing and logging layer. The network sits between the terminal and the issuer, operating the RRN-based duplicate log and the BIN status checks. It can reject a replayed packet before the issuer ever sees it, reducing load on the issuer's fraud systems and shortening response time.

Where Replay Detection Breaks Down or Produces Unexpected Results

Magnetic stripe fallback creates a gap. When an EMV terminal cannot read a chip — due to a damaged chip or a terminal malfunction — the transaction may fall back to the magnetic stripe. The magnetic stripe carries static data: the same account number, expiration date, and service code every time, with no ATC and no cryptogram. A packet captured from a magnetic stripe transaction is fully replayable because there is no per-transaction cryptographic value to go stale. The network's duplicate-detection log is the only automated barrier in this scenario, and it operates on a time window, not a cryptographic proof. The structural weakness of this fallback path is examined in detail in the context of how EMV fallback transactions weaken card security.

Time-window gaps in the duplicate log. The network's RRN-based log has a finite retention window. An attacker who waits long enough — past the window's expiration — may find that the original transaction record has aged out. The cryptographic ATC check at the issuer remains active regardless of time, but if the issuer's ATC record is somehow corrupted or reset (for example, after a card reissuance that preserves the account number), the time-window gap becomes a real exposure.

Token domain restrictions are not always enforced uniformly. Tokenization restricts a token to a specific merchant, device, or channel, but the granularity of those restrictions varies across implementations. A token issued for a broad merchant category rather than a specific merchant ID provides weaker domain binding and is more susceptible to replay within that category.

Network latency and clock skew. Authorization systems compare timestamps as part of duplicate detection. If a terminal's clock is significantly skewed, the timestamp on a legitimate transaction may fall outside the expected window and trigger a false-positive duplicate flag, causing a valid transaction to be declined. Conversely, an attacker who can manipulate the timestamp on a replayed packet to appear fresh may partially evade time-based checks — though the ATC mismatch at the issuer remains an independent barrier.

Card-not-present (CNP) transactions lack chip-level protection. Online and phone transactions do not involve a chip interaction. There is no ATC, no Application Cryptogram, and no terminal unpredictable number. Replay detection in CNP environments relies entirely on network-layer duplicate detection, velocity rules, and supplementary authentication mechanisms such as one-time passcodes or 3-D Secure protocols — none of which provide the cryptographic certainty of an EMV chip exchange.

What Transaction Records and Disclosures Show — and What They Omit

A cardholder's monthly statement shows approved transactions: the merchant name, date, and amount. It does not show declined authorization attempts. A replayed transaction that was successfully blocked at the network or issuer level will not appear on the statement at all, leaving no visible record for the cardholder that an interception attempt occurred.

The issuer's internal authorization log records every authorization request — approved and declined — along with the decline reason code. Reason codes distinguish between a cryptogram failure, an ATC sequence error, a duplicate RRN match, and a BIN status rejection. These codes are accessible to the issuer's fraud operations team but are not surfaced in standard cardholder disclosures. A cardholder who calls to inquire about a declined transaction will typically receive a generic explanation rather than the specific technical reason.

Network-level dispute and chargeback records, which issuers and merchants access through the network's reporting systems, may reference a duplicate transaction flag in the case data. However, these records describe the outcome of the detection process — the flag and the decline — not the underlying interception event itself. There is no standardized consumer-facing disclosure that describes when a replay attempt was detected.

The CFPB's rules under the Truth in Lending Act (Regulation Z) require issuers to provide periodic statements listing transactions and to investigate billing errors reported by cardholders. Those rules govern what appears on a statement and how disputes are resolved, but they do not require issuers to notify cardholders of blocked fraudulent authorization attempts. The regulatory record of a replay attack, if one exists, lives in the issuer's internal fraud logs and any subsequent law enforcement referral — not in any document the cardholder receives automatically.

The replay-detection system is a layered structure in which each component — the chip's ATC, the terminal's unpredictable number, the network's duplicate log, and the token domain restriction — addresses a different vector of the same attack. No single layer is sufficient on its own, and the strength of the overall system at any given transaction depends on which layers are actually present: a chip transaction in a tokenized environment activates all of them, while a magnetic stripe card-not-present transaction activates very few.

Note: This explains how credit cards work as financial systems. It is not financial advice, it is not a recommendation of any card or provider, and it is not a substitute for the CFPB's own guidance. Check the cited sources for current regulatory detail.