Velocity Checks

A velocity check counts how often a particular event occurs for a particular entity within a defined time window, and acts when the count exceeds a threshold. Five card attempts from one device in a minute. Three applications from one address in a day. Ten logins to different accounts from one IP in an hour.

It is the simplest fraud control that works, and it works because fraud that pays has to happen repeatedly. A single fraudulent transaction rarely justifies the effort; the economics require volume, and volume is countable.

How velocity checks work

Three decisions define any velocity rule: what you count, what you count it against, and over what period.

The entity is the important one, and it is the one most often chosen badly. Counting attempts per IP address is easy and nearly useless against an attacker using mobile proxies, because each request arrives from a different address. Counting per device fingerprint survives address rotation. Counting per verified identity survives both, because the attacker cannot rotate through identities they do not have.

Windows vary by attack. Credential stuffing and card testing are measured in seconds and minutes. Application fraud runs over days and weeks — several applications sharing a phone number across a fortnight is a strong signal that a five-minute window would never see. Most mature systems run several windows on the same entity simultaneously.

Thresholds are where the operational pain sits. Set tight and legitimate patterns break: a family sharing an address, a company registering staff, a customer retrying a declined payment. Set loose and the attacker simply stays beneath the line, because they can measure where it is.

Why the entity matters more than the limit

The instinct when a velocity rule underperforms is to adjust the threshold. It is usually the wrong lever.

A velocity check can only count what it can group. If the identifier is cheap to change, the attacker changes it and the count never rises — not because the threshold was wrong, but because every event landed in a different bucket. Email addresses, IP addresses and phone numbers are all cheap. Devices are harder. A verified identity is the most expensive identifier to rotate, because obtaining another one requires another real person.

This is why identity verification changes what velocity checks can do rather than merely adding a signal. It supplies a durable entity to count on, which makes a whole class of rule possible: how many applications has this actual person made, across how many products, under how many names or addresses. A fabricated identity is specifically designed not to resolve, so on self-asserted data that question cannot be asked at all.

Velocity checks compared with adjacent controls

Velocity checks keep their place in systems that also have models, for two reasons worth stating: they are instantly explainable to a regulator or an analyst, and they can be deployed the same day an attack starts, which no model can.

What velocity checks cannot do

They cannot catch the patient attacker. Anything spread thinly enough falls under every threshold. A fraudster running one application per identity across many institutions generates no velocity signal anywhere, which is exactly the shape of organized application fraud.

They cannot see across organizations. Each firm counts only its own events. The pattern that would be obvious industry-wide is invisible to each participant, which is the argument for consortium data and the reason it keeps being proposed.

They punish legitimate repetition. Shared addresses, corporate networks, families on one device and customers retrying a failing payment all look like velocity. The friction lands on people with a legitimate reason to do the same thing twice.

They tell you nothing about a first event. By construction, a velocity rule needs history. A brand-new identity making its first application has a velocity of one, which is also what every genuine new customer looks like.

Frequently asked questions

What is a velocity check in fraud prevention?

A rule that counts how many times an event occurs for a given entity within a time window and responds when the count passes a threshold — card attempts per device per minute, applications per address per week, logins per IP per hour. It catches the repetition that fraud economics require.

What is a good velocity threshold?

There is no universal figure, because it depends on what legitimate customers do in that product. The more useful question is what entity you are counting on: a well-chosen entity with a loose threshold usually outperforms a poorly chosen one with a tight threshold.

Why do velocity checks produce false positives?

Because legitimate behavior repeats too. Shared households and devices, corporate IP addresses, staff registering colleagues, and customers retrying a payment that keeps failing all generate counts that look like an attack, and the tighter the threshold the more of them are caught.

Do velocity checks still matter when you have machine learning models?

Yes, for two reasons models cannot supply: they are fully explainable, which matters when a decision must be justified, and they can be deployed within hours of a new attack appearing rather than waiting for enough labeled examples to retrain on.

Related reading

• Transaction monitoring — the pattern-based control velocity sits alongside
• Credential stuffing — the attack velocity checks were built for
• Device fingerprinting — a more durable entity than an IP address
• Application fraud — where longer velocity windows earn their place