The Short Life of a Stolen Card

Executive Summary

Four out of five stolen payment cards are tested on a single day and never touched again. For most cards, the first sighting is the only warning anyone will ever get.

Card testing sits between a card being stolen and a card being spent. Before anyone buys anything with compromised card data, they need to know it works, so they push it through a payment endpoint and read the response. Every one of those attempts is observable, and across millions of them a consistent operating pattern emerges.

We examined 18.8 million payment cards seen in card testing traffic between June 2023 and September 2026, along with 46.2 million individual test attempts recorded against them since January 2024. Every figure in this paper covers only cards that pass a Luhn check, so the population is structurally valid card numbers rather than malformed or partial captures. Most cards are validated once and discarded. A small minority are worked repeatedly over many months. Very little sits between those two behaviours, and the gap between them is where fraud teams can get leverage.

81.9 percent of the cards we observed appear in testing on exactly one day and are never seen again. For four cards in five there is no second sighting, so any process that waits for corroboration before acting never acts on those cards at all.

Issuers routinely leave cards live for weeks or months after a known compromise, which makes that single observation more valuable rather than less. The card stays exploitable long after the testing stops. What disappears is the warning, not the exposure.

At the other end, the 7 percent of cards tested on three or more separate days absorb 33 percent of all testing activity. That group is small enough to route differently and concentrated enough to make building the routing worthwhile.

How a Stolen Card Actually Gets Used

Validation is a separate job from monetization, and it leaves a different kind of trace.

Card data arrives from a breach, a skimmer, malware or a phishing kit as a list of numbers with no indication of which ones still work. Cards get cancelled, expiry dates pass, and some of the data was never valid. Ordering goods using a dead card burns anonymization infrastructure and attracts attention, so the list gets validated before it gets spent.

Validation means submitting the card somewhere that will attempt a charge and return an answer. A small authorization, a donation, a subscription signup, anything producing a yes or a no. The attempts run automated and at volume, and the operator cares only about the response.

Card testing therefore runs ahead of losses rather than alongside them. By the time a fraudulent purchase posts, the validation that made it possible already happened, often days earlier and sometimes hours earlier. That interval is the only window a fraud program has, and the rest of this paper is about how wide it actually is.

How Long a Stolen Card Stays in Circulation

Measured from the first time we see a card tested to the last, the distribution is severely front-loaded.

Four in five cards have a testing lifespan of zero days. They appear, get validated, and vanish. The obvious explanation is that those cards visibly failed, so nobody bothered again. The data does not support it. Among Luhn valid cards, the share of attempts our parser flags as declined is essentially flat across every level of testing intensity, and cards flagged on their very first attempt are slightly more likely to be worked again later, not less. Abandonment is an operating habit rather than a response to failure.

The tail is thin but genuine. Roughly one card in ten is still being tested more than 30 days after it first appeared, and 2.0 percent are still in circulation over a year later. Those cards behave differently enough to be worth separating out.

Repeat Testing and the Long Tail

Counting the distinct days a card is active, rather than the calendar span between first and last sighting, separates the disposable majority from the cards operators hold onto.

Cards tested on exactly two days average 66 days between those days. A returning card is not a retry a few minutes after a decline. Someone kept the list, came back two months later, and ran it again. Lists are stored, curated and re-run, which is worth knowing before writing any rule that assumes an old sighting is a dead one.

At the bottom of the table sit 2,675 cards, a rounding error against a population of 14.5 million, each absorbing an average of 204 attempts across eleven months. Whatever kept those cards in rotation kept them there long after the rest of the list had been dropped. It may be that these cards are an artifact of testing scripts gone astray and not a signal about those specific cards.

Repeat testing is rare and highly concentrated, which gives fraud teams a usable prioritization signal. A card seen on three or more distinct testing days sits in the 7 percent of the population that absorbs 33 percent of all testing activity.

Incomplete Card Records Drive Part of the Tail

Some repeat testing happens because the operator does not have the whole card record. Around 465,000 cards in this population are submitted with more than one expiry and CVV combination, which means somebody holds a number and is working through possibilities for the rest of it.

The clearest case is cards arriving with no expiry date at all. Over nine in ten of those are submitted with multiple combinations, against roughly 5 percent of single-day cards that arrive with a complete record. For anyone monitoring their own payment surfaces, repeated attempts on one card number with varying expiry and CVV values is a distinct pattern from a list being validated, and it justifies a different response.

Our collection captures testing attempts and not the card’s status at the issuer. We do not rely on an approval, a decline, or a block in our visibility. A card that keeps getting tested is a card somebody believes is worth retesting, which describes operator behaviour rather than whether the card is live.

Where Testing Happens

Card testing has always run through both legitimate and purpose-built infrastructure. The breadth of the legitimate side is what tends to surprise people.

Across the endpoints we observe receiving card testing traffic, six categories account for effectively all of it.

• Payment gateway and processor APIs, the endpoints most fraud teams already picture when they hear card testing
• Form and survey builders, including organization-branded subdomains on those platforms
• Nonprofit, charity and faith-based donation pages, heavily represented
• Small merchant checkouts, often a single site that runs hot for a few weeks and then goes quiet
• Large consumer brands and subscription services, spanning retail, streaming and VPN providers
• Purpose-built card checker services, which exist for no reason other than validating stolen cards in bulk

Why Form Builders Are Attractive

A form builder is a hosted service that lets an organization publish a web form without writing code, such as a donation form, an event registration or a membership renewal. The service can connect that form to a payment processor, so when someone submits it, the platform charges the card. The form is public by design, because the whole point is that anyone can fill it in.

That makes it a payment endpoint accepting card details from any visitor and returning a clear answer about whether the charge worked, which is what a checkout page does, without the fraud controls a merchant would put around a checkout. The organization running the form usually has no idea, because from their side it looks like a run of failed transactions.

Donation pages and small merchant checkouts are attractive for the same reasons. They take card data from strangers, they return a clear answer, and few of them are instrumented to notice that the answer was the only thing the visitor came for.

Purpose-Built Checkers

At the other extreme is infrastructure built for this and nothing else. These services take a list and return validity results in bulk. Their traffic has a recognizable shape: roughly one attempt per card per session, very large card counts, almost no path structure, and activity arriving in short intense bursts rather than steady flow. They appear, run hard for a few weeks, and disappear.

What This Means for Detection

Several common practices in card intelligence handling work against the grain of this distribution.

Ingestion Timing

When 81.9 percent of cards are tested on a single day, a card testing feed has to be worked on the day it arrives. A daily batch reviewed the following morning has already missed most of what it reported, and no later batch will report those cards again. Feeds that arrive on a business-hours cadence and get worked in a queue will produce good monthly reporting and very little prevention. Streaming ingestion with automated action on first sighting is the only handling that matches how fast this population turns over.

The argument here is about the signal rather than the card. Cards often stay live at the issuer well past the point where testing stops, so late action still has value. What a slow process gives up is the chance to learn about the card at all.

Aging Rules

Plenty of fraud programs age card intelligence out after 30 or 60 days on the assumption that an old sighting is stale. Cards tested on two days average 66 days between them, and 2.0 percent are still being tested more than a year after first appearing. A card quiet for two months is behaving exactly like a card that will be tested again.

Prioritization

Alert volume is the perennial complaint, and this data supports a defensible way to rank. Distinct testing days is the signal worth tracking, not raw attempt count. One automated run can generate hundreds of attempts inside an hour and still tells you about a single session, while three separate days tells you somebody kept the card and came back to it.

Your Own Payment Surfaces

If your organization publishes a public form that takes a payment, whether a donation page, a registration form or a membership renewal, that form is a card validation endpoint whether or not anyone has treated it as one. Decline rates on those pages are worth watching the same way decline rates on a checkout are watched, and a sudden run of failed small-value submissions is usually somebody else’s list being validated at your expense.

Recommendations

1. Design ingestion and response around hours rather than days, and do not wait for a second sighting before acting, because for 82% of cards there will not be one
2. Retire fixed 30 and 60 day aging rules on card intelligence, since a two-month silence is normal for a card that returns
3. Rank by distinct testing days rather than attempt volume, and route cards seen on three or more separate days into a different queue with a different response
4. Separate repeated attempts on one card number with varying expiry and CVV values from list validation, because the first means somebody holds a partial record and is completing it
5. Inventory every public form your organization runs that accepts a payment, assign an owner to each, and monitor decline rates on them the way you monitor a checkout
6. If you issue cards, check a sample of reported numbers against your own issuance records, since only an issuer can tell a compromised card from a manufactured candidate and the answer changes how you weight the feed
7. Ask your processor what happens between a card being reported and a card actually stopping, because the gap between those two events is where the losses in this data occur

Methodology and Limitations

Every figure in this paper covers 16-digit card numbers that pass a Luhn check. Lifespan figures cover 18,849,072 distinct cards observed in card testing traffic between 25 June 2023 and 27 September 2026, measured as the interval between first and last observation. Repeat testing figures cover 14,474,372 cards and 46,200,338 deduplicated test attempts from 1 January 2024 onward, where an active day is any calendar day carrying at least one observed attempt against that card. All card testing traffic in this data is automated. Endpoint categories are derived from the hosts receiving the traffic, grouped by the function of the receiving service.

Cards failing Luhn checks were excluded rather than analysed, and they behave differently enough to justify the separation. Roughly one in five card numbers we capture fails the check, and those numbers are flagged as declined on first attempt at six times the rate of Luhn valid cards. That population is a mix of malformed captures and manufactured candidates, and mixing it into a lifecycle analysis would distort every figure here.

We tested whether the single-sighting population is card generation rather than testing of genuinely compromised cards. Enumeration leaves near-sequential account numbers arriving at one BIN from one source in a short window, and across nine months near-sequential numbers account for essentially none of the Luhn valid population. We also examined expiry structure, on the reasoning that fabricated card records tend to carry fabricated dates. Expiry months are not uniform in any population we measured, and cards carrying unusually distant expiry years concentrate in issuers and markets where long validity terms are standard rather than in any one operator or BIN. Those cards also arrive with a single fixed expiry and CVV attached, which is what a captured record looks like rather than what guessing looks like.

Randomized generation within a BIN would not be caught by either test. We therefore describe this population as card validation activity, which is likely to include some manufactured candidates alongside genuinely compromised cards. Only an issuer checking numbers against its own issuance records can establish the proportion, and we would welcome that comparison from anyone in a position to run it.

We observe testing attempts and not card status, so nothing here should be read as a statement about whether an individual card was live, blocked or reissued. Decline references in this paper come from parsing response text for explicit failure language, which is a floor on declines rather than a measure of approvals, and we use it only to compare populations measured the same way. Variant counts rise partly because a card tested on more days has more opportunity to show variation, so the comparison that carries weight is between cards arriving with a complete record and those arriving without one. Every figure describes the population we collect, which is a sample of global card testing rather than a census of it, and findings should be read as describing that sample.

About This Research

myNetWatchman has provided cyber fraud intelligence to retailers, financial services, insurance and other industries for more than 20 years. Card testing activity is observed directly rather than inferred, which is what makes the timing questions in this paper answerable at all.

If you would like to see how these patterns look against your own BIN ranges, we are happy to run the analysis and walk you through the results. Contact myNetWatchman to arrange a briefing.