Velocity Checks That Stay Explainable

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.

That sentence is what support reads to a customer. It is what an auditor asks you to replay. It is what you change next week when a flash sale proves the threshold was wrong. If you cannot say the identifier, the action, the window, and the threshold out loud, you do not have a velocity rule. You have a feeling.

The four parts of a velocity rule

**Identifier.** Customer id, device fingerprint, IP, email, or BIN. Use the most stable key you actually collect. IP is fine for a short stuffing window and bad as your only key on a shared mobile network. Device fingerprint is stronger for card testing and multi-accounting. customer.externalId is what you need when the same person is retrying a payout.

**Action.** Login, authorization, payout, signup. Do not mix them in one count unless you mean to. Five failed logins is stuffing. Five low-value authorizations on new PANs is card testing. Five payouts to new counterparties is a different problem. The event name on the API call is how you keep those counts from lying.

**Window.** Two minutes for stuffing. An hour for card testing. A day for low-and-slow mule patterns. The window is part of the policy. A threshold that looks sane over a day will destroy a checkout during a ten-minute sale if you shrink the window without sitting in the queue.

**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. BLOCK only the high-confidence bursts you have already seen and named.

Card testing is the textbook case: many PANs, few customers, one device, low amounts. The rule is not "risky payments." The rule is "more than N authorizations from this fingerprint in this window, with distinct cards, under this amount." See what a velocity check is if you need the short definition next to the case template.

Why this beats a score nobody can explain

Auditors and customers ask why a payment was held. A score of 0.81 does not answer that. A named rule with four parts does.

Naiza's rule engine can return ALLOW, REVIEW, or BLOCK with a reason tied to an event id. Risk scoring ranks cases so the highest-risk ones rise to the top of the queue, and named rules carry the policy. That is the same split as explainable rules versus black-box ML.

Keep the event id on the payment or login record. When the threshold was wrong, you want to find every fire from that rule, not every "elevated score" from last Tuesday. Tuning is a conversation about the four parts. It is not a request to "make the model nicer."

Roll the rule out like it will be quoted

Shadow or REVIEW first, then enforce. Shared NATs, family tablets, and campaign traffic will all look fast. Sit with those cases. If the cluster is a household, leave the rule in REVIEW or raise the threshold. If the cluster is one device, many cards, and small amounts, list the fingerprint and move that slice to BLOCK.

Do not stack five velocity rules on day one. Ship one sentence. Watch it. Then write the next. A pile of overlapping windows is how you get a queue nobody trusts and a BLOCK rate you cannot explain in the weekly review.

Naiza's velocity rules measure event counts and amounts within defined time windows. Record the identifier, action, window, and threshold so investigators can explain each decision.