Velocity Checks That Stay Explainable
Write velocity rules with an identifier, action, window, and threshold so operations can defend ALLOW, REVIEW, and BLOCK decisions.
A velocity check is only as good as the sentence you can read in a case file. “Too much activity” is not a rule. “More than five authorizations from the same device fingerprint in ten minutes” is.
The four parts of a velocity rule
1. **Identifier** — customer id, device fingerprint, IP, email, or BIN. Use the most stable key you actually collect. 2. **Action** — login, authorization, payout, signup. 3. **Window** — two minutes for stuffing; one hour for card testing; a day for low-and-slow mule patterns. 4. **Threshold and outcome** — count or sum, then REVIEW or BLOCK.
Start new rules in REVIEW. Measure false positives on flash sales and shared mobile networks, then BLOCK only the high-confidence bursts. Card testing is the textbook case: many PANs, few customers, one device, low amounts. See what a velocity check is and card testing.
Why this beats a score nobody can explain
Auditors and customers ask why a payment was held. Naiza’s rule engine can return ALLOW, REVIEW, or BLOCK with a reason tied to an event id. Risk scoring can still rank cases; it should not hide the policy. Read explainable rules vs black-box ML.