Enumeration.

Fictional scenario. Synthetic data. Your notes stay on this browser; do not enter real customer information.

Every scheme in this series is taken apart the same way: what it needs, what it leaves in your data, what innocent thing leaves the same marks, and where it is usually caught. We start with enumeration because it is the one most desks meet first, and the one most often answered with a button that was too big.

OWASP's automated-threats catalogue gives it two entries. OAT-001, Carding, is the use of many card details against a payment endpoint to find which are live. OAT-010, Card Cracking, is filling in the missing values of a partly known card. From the defender's chair the traffic looks the same and the response is the same.

What the scheme needs.

Seen from the desk, enumeration needs four things, and every one is something a merchant chose.

An endpoint that answers. The attack is a question asked thousands of times, and it only works if the answer comes back per attempt. A checkout that returns a detailed decline reason is more informative to an attacker than one that does not, which is the first thing to notice about your own.

A cheap question. If every attempt costs the attacker a step-up challenge or a delay, the arithmetic changes. OWASP’s automated-threat descriptions makes the same point from the merchant's side: attempts can incur costs under the merchant’s processing contract, including unsuccessful ones.

Something worth having at the end. Digital goods, gift cards, anything delivered before anyone looks. Pondside Gifts, our fictional gift-card merchant, is the kind of target this describes.

No one watching the declines. Enumeration announces itself in the decline count long before the approvals, and it is usually missed because the desk measures what got through.

What it looks like in your data.

A synthetic illustration. On a quiet night Pondside sees forty attempts between 02:00 and 03:00. On the night in question, 3,800.

• Attempts per BIN per hour climb from single figures to the thousands. The BIN count stays small; one or a handful.
• Distinct card numbers run close to the number of attempts. In this illustration, 3,800 attempts carry 3,650 distinct cards. The attack is walking, not retrying.
• Decline reasons lean towards "invalid card" and "no such account" rather than "do not honour". The cards being tried mostly do not exist yet.
• Approval rate collapses. A checkout that approves 85 per cent of attempts on a normal night approves 1.5 per cent.
• Basket values cluster at the bottom of the catalogue: EUR 5, EUR 10, the cheapest thing that delivers instantly.
• Device and IP concentration: a few device references, a few addresses in one range, carrying almost everything.

The ratio that matters most is distinct cards to attempts. Near one, you are looking at enumeration. Far below one, you are looking at something else.

What else looks like this.

Three honest things produce a spike in attempts, each distinguished by one field.

A marketing send. An e-mail to a hundred thousand customers at 02:00 produces a burst of real purchases. Distinct cards are high, but the approval rate is normal and the devices are many.

A retry storm. A checkout that resubmits declined payments unasked produces many attempts on few cards. Distinct cards are low. The decline reasons repeat.

A partner integration gone wrong. A reseller replaying a stored batch against the wrong endpoint produces attempts on cards that exist and were once approved. The decline reasons will say so.

Each is distinguished within a minute by looking at the right column before touching a rule.

Where it is usually caught.

Enumeration is caught at one of three places, in descending order of comfort.

At the attempt rate, by a velocity rule that counts attempts rather than approvals: per BIN, per device, per address, per hour. This is early and cheap, and velocity rules that age well explains why the rule's scope matters more than its number.

At the approval tail, when someone notices a few dozen small gift-card sales at an odd hour. Later, and the goods have gone.

Programme classification depends on the network, region, reporting period, applicable entity and the current rules. Reconcile the acquirer’s event counts and exclusions before comparing a calculated rate with a confirmed threshold. Do not treat a generic floor, ratio or fee quoted in a summary as a universal programme decision.

A desk card.

• Count attempts per BIN per hour. Approvals are the tail, not the signal.
• Check distinct cards against attempts before you name the pattern.
• Read the decline reasons: "invalid card" says walking, "do not honour" says checking.
• Scope the first action to the BIN range, channel, product and window. Give it an owner and a review time.
• Tag every approval from the window into a named cohort. It will come back.

Read next.

The full working of a burst, with its costs, is in A thousand cards, one question. The first hour is in The first fifteen minutes. Try the case BIN attack at Pondside Gifts, and look up enumeration. Part two is triangulation fraud, where the card is stolen but the customer is real.

Edited 6 November 2026. Primary references are listed above; fictional scenarios are not claims about Antifrog customers or operating experience.

Fictional learning material. Any numerical examples are synthetic. Use only authorised, appropriately minimised records for workplace exercises; do not upload customer information to this learning site.