A velocity rule is a sentence with four parts.

Fictional scenarios and synthetic data. Reviewed 6 November 2026.

Lagoon Casino's rule set contains a line that reads "more than 3 deposits in 24 hours: review". Nobody on the current team wrote it. It fires about four hundred times a day, the review queue has learned to clear it in seconds, and last month it interrupted a long-standing player on a weekend tournament who then closed his account. Tomas wants to raise the threshold to 6. Ines wants to know why it is 3. Both are asking the wrong first question.

What is actually being decided.

A velocity rule is a claim that a certain count, over a certain time, for a certain entity, separates behaviour you want to look at from behaviour you do not. The Volume 02 piece on rules you can explain argues that every rule is a claim and should be written like one; velocity rules are the case where the claim has a fixed grammar. There are four parts and a rule is not finished until all four are written down.

The event: what is being counted. Deposits, authorisation attempts, declined attempts, logins, new accounts, refund requests. The key: per what the count is kept. Card, account, device, IP, e-mail domain, delivery address, BIN. The window: the span of time over which the count accumulates, and whether it is rolling or calendar. The threshold: the number at which the rule fires, and the action it takes when it does.

"More than 3 deposits in 24 hours" has an event, a window and a threshold. It does not say per what. Per account? Per card? Per device? The rule engine knows, because somebody chose a field when they built it. The team does not, and that is the first fix. The decision on the desk is not "3 or 6". It is "what behaviour was this rule written to find, does that behaviour still exist in this form, and is this the sentence that finds it?"

The two costs are the usual two. The player interrupted at the tournament is a false positive in the Google crash-course sense, a positive prediction that was wrong. The pattern the rule was written for, if it still exists, is the false negative when the threshold rises. Neither cost is visible in the firing count alone.

The key is a choice about behaviour.

The key is the part most often chosen for convenience rather than for the behaviour in question. In this fictional case, the rule turns out to be keyed on account. Four deposits in a day from one account is a heavy session, and at a casino a heavy session is a known shape of a genuine customer. It is not, on its own, the shape of anything the risk team should be interrupting.

Now ask what the rule was for. A plausible original purpose, and the one the oldest change log entry hints at, was card testing: many small deposits to check which stolen cards work before using them elsewhere. OWASP’s carding description describes that pattern from the merchant's side. The behaviour there is "many attempts per card", or "many cards per device", not "many deposits per account". An account-keyed rule catches it only by accident, when the tester uses one account for every card, and catches genuine heavy players in some cases.

So the first rewrite is a key change, not a threshold change. "Declined deposit attempts per card over 1 hour exceeds 2" and "distinct cards per device over 24 hours exceeds 3" are two sentences that between them describe the original purpose better than the rule that was running. Each would fire a small fraction of the four hundred times a day, and the piece on BIN attacks and enumeration describes what the second one looks like when it fires in earnest.

The alternative to keep alive: perhaps the rule was never about card testing. Perhaps it was about chasing losses, a responsible-gambling concern rather than a fraud one, and the account key was right all along. That is not for the fraud desk to decide alone, but it is a reason to find out before rewriting, and a reason the rule should have had a "why" in its description field from the start.

The window is a clock, and there are two of them.

The window should match the clock of the behaviour you are counting. Automated enumeration, in the OWASP catalogue's description, runs on a clock of minutes. A refund ring runs on a clock of weeks. A rule with a long window may react too late if its threshold and aggregation obscure a short burst; a rule with a one-hour window applied to a weeks-scale pattern never sees it at all.

There is a second clock, the customer's, and the window has to be checked against that one too. In this synthetic illustration, a sample of 10,000 genuine Lagoon players shows a median of 1 deposit per active day, a 95th percentile of 3, and a 99th percentile of 5, with the top of the distribution concentrated on tournament weekends. A threshold of 3 on a 24-hour account window therefore interrupts roughly 5 per cent of active genuine players on a normal day and considerably more on a tournament day. Those numbers are invented; the method is not: pull the genuine distribution for your key and window, and see where the threshold sits on it before anything else.

Rolling versus calendar is a smaller choice with large edge effects. A calendar-day window resets at midnight, and anyone who has found a rule's threshold finds its reset time soon after. Rolling windows cost more to compute and are harder to game.

Thresholds drift because businesses do.

A threshold set in a given month encodes the business of that month: its products, its customers, its promotions, its fraud. Twelve months later the products have changed and the threshold has not. This is drift, and the piece on baselines and seasonality treats the measurement side. The rule side is simpler: a threshold without a review date will be wrong eventually, and nobody will notice, because a rule that fires too often looks like a busy day and a rule that stops firing looks like a quiet one. The case The silent rule is built on the second failure.

The threshold is a price, and the companion article on threshold tuning with a cost matrix is the full method. The short version for a velocity rule: pull a month of firings, label a sample as "would have wanted to see" or "would not", and compute precision at the current threshold and at two others. A rule that is right one time in forty is a tax on the review queue, and the Volume 01 study The quiet queue is about what that does to the people working it.

A failure mode to watch.

A consequential mistake is to tune the threshold of a rule nobody can explain. Raising 3 to 6 reduces the firings and feels like progress, but if the key is wrong, the rule at 6 still finds the wrong thing, only less often. The genuine heavy player is interrupted less; the card tester, who was never caught by this rule, is unaffected. The team has spent a tuning cycle improving a rule's silence. Find the sentence first. If the four parts cannot be written down, with a reason for each, the honest move is to retire the rule and write the one you meant.

A way to work it.

1. Write every velocity rule as a sentence: count [event] per [key] over [window] exceeds [threshold], then [action]. Mark any part that cannot be filled in.
2. For each rule, write the behaviour it was meant to find, in one line. If nobody knows, look at the change log, then the oldest case notes that cite it.
3. Check the key against the behaviour. If the behaviour is per card and the key is per account, rewrite before tuning.
4. Pull the genuine distribution for the chosen key and window. Place the threshold on it and note the share of genuine customers above it.
5. Label a sample of last month's firings and compute precision at three thresholds. Price the trade in both directions.
6. Give the rewritten rule an owner, the one-line "why" in its description, and a review date no more than a quarter away.

Take it to the desk.

For each velocity rule we run, can we say in one sentence what it counts, per what key, over which window, and why that threshold? Which rule has the oldest "why"? That one is the one to open first.

Try it: The silent rule, and the Volume 01 case False positive. Read next: A rule is a claim. Write it like one.. Look up: velocity, drift.

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.