The first fifteen minutes.

Fictional scenarios and synthetic data. Reviewed 6 November 2026.

02:10 on a Monday. The on-call phone at Northbank Pay shows Pondside Gifts: 1,400 authorisation attempts in the last ten minutes against a same-slot baseline of about 30. Decline rate 92 per cent. The reader is on call, Ines is asleep, and the first thing to decide is what not to do yet.

What is actually being decided.

An authorisation burst forces two decisions in a hurry. The first is whether this is an attack at all. The second is how wide an action to take. The temptation is to collapse both into one: block the merchant's traffic and sort it out in the morning. That is the widest possible action taken on the least possible evidence, and it is the one the merchant will remember.

The merchant carries the lost sales of every legitimate customer caught in a block, and the dispute and fee exposure of every fraudulent approval that got through. The PSP carries the explanation to Stilling Bank if the approvals become fraud reports, and the relationship if the block was wider than it needed to be. The person on call carries the first fifteen minutes. This runbook is for them.

Minutes 0 to 3. Confirm against the right baseline.

Before anything else, check the comparison. Compared with what, exactly explains why the all-hours average lies; at 02:10 on a Monday the same-slot baseline is what matters. Pull the last eight Monday 02:00 slots. In this illustration they average 30 attempts with a decline rate of 5 per cent. The observed 1,400 attempts at 92 per cent declined are more than forty times the count and eighteen times the rate. Confirmed: this is not a Monday night.

Then look at what OWASP’s automated-threat descriptions and the OWASP automated-threats catalogue describe as the common shape of OAT-001 (carding) and its cousin, enumeration: many attempts, small or identical amounts, high decline rate, often at a quiet hour. We cite both for the shape. The observations here fit it: amounts between €1 and €5, decline rate 92 per cent, quiet hour. "This is card testing" is an inference. It is a strong one, and the alternative (a legitimate integration gone wrong, retrying in a loop) should be written down beside it, because it does happen.

Minutes 3 to 8. Find the narrowest entity.

The burst has a shape, and the shape names the entity to act on. Cut the 1,400 attempts by the obvious dimensions and look for where they concentrate.

In this illustration: one BIN accounts for 840 of the 1,400 attempts (60 per cent). Source IPs are spread across the 203.0.113.0/24 range and two others; no single address holds more than 4 per cent. Device references are mostly absent, which on a hosted checkout is itself an observation. The remaining 560 attempts sit on a handful of other BINs with the same small amounts. Of the 112 approved attempts, 101 are on the concentrated BIN. Beneath the burst, the merchant's ordinary traffic in the window, 22 attempts at ordinary amounts from the usual mix of BINs, is declining at 9 per cent, close to normal.

The narrowest entity that holds most of the burst is the BIN. Not the merchant, not the IP range (too spread), not the device (too absent). A thousand cards, one question covers why one BIN appears and what the approvals mean.

Minutes 8 to 12. Act on that entity, in the template.

The action is written as a sentence before it is applied, with its four properties: scoped, owned, reviewable, reversible.

IF an authorisation attempt at Pondside Gifts carries BIN <the concentrated BIN> THEN decline before authorisation for 60 minutes. Owner: the on-call analyst. Review: 03:10, or sooner if the burst moves. Rollback: remove the BIN from the pre-authorisation decline list; approvals already made are not reversed by this action.

A second, narrower action sits beside it for the approvals: flag the 101 approved transactions on the BIN for a hold on fulfilment, owner the merchant's operations contact, review by 09:00, rollback by releasing the hold. Gift cards that have not been delivered cannot be cashed out.

What is not done: no merchant-wide block; no block on the 203.0.113.0/24 range, which may carry real customers tomorrow morning; no permanent rule. Sixty minutes is long enough to see whether the burst moves to a second BIN, and short enough that a mistake costs an hour.

The alternative we keep alive: the attack moves. At 02:35 the same amounts appear on a second BIN. The runbook does not say "block the merchant now". It says repeat minutes 3 to 12 for the new entity, and record that the attacker is rotating, which is itself evidence for the morning.

Minutes 12 to 15. Write it down and tell the merchant.

The note goes in the template from Write the note for the person who reopens it: trigger, observations with their source, the inference labelled, the action with its four properties, what would change your mind, status. At 02:25 it takes four minutes and is the only record anyone will have at 09:00.

The merchant gets a short message: what was seen, what was done, when it will be reviewed, and what they should do (hold fulfilment on the flagged orders). Not a diagnosis, not a promise. If approved attempts exceed the merchant's agreed threshold for acquirer notification, it is better to draft the note to Stilling Bank now and send it in the morning with the review attached than to send nothing and be asked. What the acquirer asks says what they will want.

After fifteen minutes.

The hour that follows is observation. Does the burst stop, move or thin? Does the ordinary traffic's decline rate stay near baseline (if it rises, the action is too wide)? At the review time, the action is either extended with a new review time, narrowed, or rolled back, and the note is updated. In the morning, Ines and Tomas read the note, the decline codes (What a decline is trying to tell you) and the approvals, and decide what rule, if any, should exist by Tuesday. The runbook ends where the analysis begins.

A failure mode to watch.

The burst is treated as the emergency and the approvals are forgotten. The declines are loud and the action targets them. The 101 approvals are quiet and ship in the morning, become fraud reports in three weeks, and count against the merchant in a programme the on-call analyst was not thinking about at 02:10. The declines are the attacker's noise. The approvals are the attacker's result. Act on both.

A way to work it.

1. Before any burst: agree with each merchant the widest action the on-call analyst can take alone, and the contact who can hold fulfilment at night. Write both in the merchant file.
2. Before any burst: have the same-slot baseline for attempts and decline rate on a panel the on-call phone can open.
3. Minutes 0 to 3: confirm count and rate against the slot. Write the alternative explanation in one line.
4. Minutes 3 to 8: cut by BIN, IP, device, amount, endpoint. Name the narrowest entity holding most of the burst.
5. Minutes 8 to 12: write the action sentence with owner, review time and rollback. Apply it. Flag the approvals for a fulfilment hold.
6. Minutes 12 to 15: write the note, tell the merchant, draft the acquirer note if the approvals warrant it. Set the review alarm.

Take it to the desk.

At 02:00 on a Sunday, who on our team can take a scoped action on a merchant's traffic without asking anyone, and what is the widest action they can take alone?

Try it: Overnight burst of authorisations across sequential card numbers Look up: card testing · enumeration · velocity

The Volume 01 case card-testing is the daytime version of this night, and the note Card testing beyond declines is the short argument for watching the approvals.

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.