A thousand cards, one question.

Fictional scenarios and synthetic data. Reviewed 6 November 2026.

At 02:14 the Pondside Gifts authorisation graph goes vertical. By 02:40 there are 3,800 attempts where a quiet Tuesday night would carry forty. Nearly all are declined. A few dozen are approved. Tomas is on call and has the dashboard open; he is reaching for the "block the BIN" button. The question for the next hour is not whether this is an attack. It is what the attack is for, and what the right-sized response looks like.

What is actually being decided.

An enumeration burst looks like one problem and is really three decisions stacked on top of each other.

The first is classification: is this traffic automated card enumeration, or something benign that resembles it (a marketing send, a partner integration gone wrong, a retry storm from a mobile app)? OWASP's automated-threats catalogue files the attack as OAT-001, Carding, and describes it at the level we will use here: many authorisation attempts, drawn from a range of card numbers, to find which ones are live. We do not need to know more than that to defend against it.

The second is containment: which traffic to interrupt, at what scope, for how long, and who owns the decision. The cost on one side is the approved fraudulent transactions and the disputes they will become. The cost on the other side is every genuine Pondside customer who happens to be using a card from the same issuer at 02:30.

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.

Three decisions, three owners: the analyst on call, the merchant, and the acquirer. Name all three before you act.

Count attempts, not approvals.

The instinct is to look at what got through. Resist it for the first ten minutes.

An observation: between 02:14 and 02:40, Pondside received 3,800 authorisation attempts across one six-digit BIN, with card numbers spread across the range and expiry dates and CVVs varying. Of those, 3,742 were declined and 58 were approved, for values between EUR 5 and EUR 25. All 58 used a gift-card product with instant digital delivery.

An inference: someone is testing a list to find live cards, and the gift cards are the cash-out. That inference is strong, but it is still an inference, and the alternative is worth keeping alive for ten minutes: a partner integration at a reseller could in principle replay a batch of stored cards against the wrong endpoint. The difference shows in the attempt distribution. A replayed batch reuses the same card numbers; an enumeration walks through fresh ones. Pull the distinct-card count and the decision makes itself.

The provider card-testing documentation, which we use for operational mechanics rather than scheme rules, makes the same point from the other side: the volume of declined attempts is itself the cost. Each attempt has an authorisation fee attached, declined or not, and the pattern of declines is the earliest and cleanest signal you will get. Approvals are the tail of the distribution. The body of it is the declines.

Scope the response to the shape of the attack.

The "block the BIN" button interrupts every cardholder of that issuer, genuine or not, for as long as the block stands. At 02:30 on a Tuesday that cost is small. At 09:00 on a Saturday before a holiday it is not. The response should match the shape of the attack, not the shape of the button.

In this illustration, the burst has four edges you can draw a box around: one BIN range, one channel (the web checkout, not the app), one product family (instant-delivery gift cards), and one time window. A rule that says "for the next six hours, require a step-up on web gift-card purchases from this BIN range, and decline above three attempts per card per hour" touches almost nobody who is not part of the attack. A rule that says "decline this BIN" touches everybody.

The fictional numbers help here. Suppose Pondside normally sees 400 genuine transactions a day from that BIN range, concentrated between 08:00 and 22:00. The scoped rule, running overnight, interrupts perhaps a dozen of them. The blanket block, left in place until someone reviews it at 09:00, interrupts a hundred or more and converts several into support tickets and a few into lost customers. Neither number is real. The ratio between them is the point.

Write the action with its four parts on it: scope, owner, duration, review time. The companion piece on velocity rules that age well argues that every rule is a sentence with those parts; an emergency rule is no exception. It is just a sentence written quickly.

The approvals are tomorrow's disputes. Keep the list.

The approved transactions may generate later fraud reports or disputes. Keep those records separate from refunds and alerts, then reconcile the exclusions actually recognised in the acquirer’s dated extract. Do not assume a refund automatically removes a fraud report or that a local alert record guarantees a particular monitoring adjustment.

So keep the list. Every approved transaction from the burst goes into a cohort with a tag: the date, the BIN, the rule that would have caught it. Pondside can then refund proactively where delivery has not completed, respond to alerts quickly where it has, and tell Stilling Bank exactly what to expect. The acquirer would rather hear "58 transactions, here is the list, here is what we did" on Wednesday than discover them in a ratio report in December. The article on two ratios and their denominators covers what the acquirer is actually counting.

A failure mode to watch.

A consequential mistake is to treat the end of the burst as the end of the incident. The traffic stops at 03:10, the rule is left in place, Tomas goes back to bed, and nobody writes down what happened. Three weeks later the disputes arrive, the acquirer asks a question, and the only record is a rule with no owner and a Slack thread. The attack took an hour. The consequences take a quarter. The case note written at 03:30 is the most valuable thing produced that night, and the Volume 02 piece on case notes someone can audit describes what it should contain.

A way to work it.

1. Confirm the shape before the cause. Distinct cards per BIN per hour, decline rate, channel, product. If distinct cards are high and reused cards are low, treat it as enumeration.
2. Draw the box. BIN range, channel, product family, window. Write the containment rule to fit the box, not the button.
3. Give the rule an owner, a duration and a review time, in the rule's own description field.
4. Tag every approved transaction from the window into a named cohort. Decide tonight what you will do with undelivered orders.
5. Tell the acquirer in the morning, with the cohort attached, before the fraud reports arrive.
6. At the review time, measure what the rule interrupted that was not part of the attack. Narrow it or retire it.

Take it to the desk.

If an enumeration burst started at 02:00 tonight, who would see it first, and what is the first action they are allowed to take without waking anyone? If the answer is "block the BIN", ask what the second action would be, and whether the first one could have been that instead.

Try it: BIN attack at Pondside Gifts, and the Volume 01 case Card testing. Read next: The first fifteen minutes. Look up: enumeration, card testing.

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.