One BIN. Two thousand cards.

1,980 of the 2,400 attempts share one six-digit card-range prefix. This exercise uses it as a grouping field, not as a definitive issuer or account identity. Within that group, the gateway reports near-sequential underlying account-number patterns, expiry dates vary in a regular pattern and every amount is €25 or €50. 212 of the 1,980 were approved, and codes went to 212 distinct email addresses on three domains. The remaining 420 attempts show the merchant’s usual mix of BINs, amounts and returning customers, and were approved at the normal rate.

Near-sequential card references across one BIN are a strong signal of enumeration rather than ordinary demand, and the log shows which attempts belong to the pattern. It does not show which of the 212 approvals, if any, were made by the cardholder, and it does not identify who ran the burst.

Engineering finds no new release and no retry loop. Each attempt carries a different tokenised card reference. The gateway supplies an enumeration-pattern indicator; analysts do not access raw card numbers. All 1,980 attempts came through the guest-checkout API from a block of addresses in 203.0.113.0/24, with no page views before the payment call. The gateway’s velocity rule counts attempts per card reference per hour; it did not trigger because each card was used once.

The operational explanation has been tested and fits poorly. The missing page views and single-use cards explain why the existing control stayed quiet. The address block is a lead for a scoped control, not proof of a single actor; shared infrastructure can put unrelated traffic in one range.

212 gift-card codes worth €8,300 were delivered. 37 have been redeemed at partner retailers; 175 are unredeemed and can be suspended by the merchant until reviewed, then restored. The incident runbook permits a temporary rate limit per BIN and per address range for up to 24 hours, with a named owner and a 09:00 review. The acquirer asks for an incident note within one business day for any suspected enumeration event. These deadlines and controls are this fictional merchant’s runbook, not a scheme-wide requirement.

The split between redeemed and unredeemed codes tells you where a reversible action is still possible. The runbook sets the limits of what you can do alone. Nothing here settles whether each approval was fraudulent; that needs the issuers, through your acquirer.