What is Velocity Checks?

Velocity checks are simple fraud rules that watch how often something is happening — same card used twice in a minute, same IP submitting ten declines in five — and flag or block the activity when it crosses a threshold. They're the first line of defence against automated card testing, and they catch most fraud before the more sophisticated risk engines need to get involved.

What Velocity Checks Are

Velocity checks are fraud detection rules that count how often something happens in a defined time window and act when the count goes too high. In payments they typically track how many transactions are attempted on the same card number, from the same IP address, from the same device, or against the same account within a short period — and flag, block, or escalate anything outside normal patterns.

The logic isn't clever and doesn't need to be. Real customers don't try to buy something ten times in two minutes. They don't run five different cards through the checkout in a row. They don't keep retrying the same declined transaction. When those patterns appear, it's almost always card testing, account takeover, or a broken integration — and any of those want attention quickly.

How They Work

A velocity check counts events inside a sliding time window and compares the count to a threshold. When the threshold trips, the system does something predefined: block the transaction outright, queue it for manual review, require an extra authentication factor. Most payment platforms let you stack multiple velocity rules together.

The common ones, in roughly the order they catch fraud:

Transaction Frequency Per Card

How many times the same card number has been used in the last N minutes. A typical rule: "If the same PAN appears more than three times in ten minutes, block." This is the one that catches card testing, where a fraudster runs stolen cards through a low-value purchase to see which still work. It also catches the simpler case of someone using a stolen card to buy three things in a row before the legitimate cardholder notices.

Decline Rate From a Source

How many declined transactions have come from the same IP, device, or account in the last N minutes. Real customers don't usually submit five invalid card numbers in fifteen minutes. Bots do. A typical rule: "More than five declines from a single IP in fifteen minutes — block that IP for an hour." This is the single most effective rule against automated card testing.

Amount Velocity

How much total value has been transacted on a card or account in a time window. Each transaction can look individually plausible while the total adds up to something obviously wrong. "Total transactions on a single card exceed £2,000 in one hour — flag for review."

New Card Velocity

How many new payment cards have been added to the same customer account in the last N hours. Real customers rarely add three new cards in a day. When that happens it usually means somebody who isn't the customer is testing which of their stolen cards work.

Why They Matter

Velocity checks are the cheapest, simplest fraud control you can run. No machine learning, no behavioural baselines, no risk scoring — just clear rules and counters. They're easy to implement, easy to explain to an auditor, and easy to tune when something goes wrong.

Their real value is against automated attacks. Card testing bots, credential stuffing, automated purchasing — they all generate the kind of high-frequency activity that velocity checks are built for. Without them, a fraudster can test thousands of stolen card numbers against your checkout in a single afternoon and you'll pay processing fees and chargebacks on every successful test.

They also protect your customers. If you stop suspicious activity before it goes through, the legitimate cardholder never sees a fraudulent charge on their statement, never starts a chargeback, never loses faith in your business. That's worth more than the fee saving.

Velocity Checks in Phone Payments

Velocity checks usually get discussed in an e-commerce context, but they apply just as much to a contact centre taking card payments by phone. The patterns are slightly different — a fraudster on a phone line can't bot-spam transactions the way they can on a web form — but unusual frequency is still the giveaway.

Useful velocity signals in a contact centre:

  • Multiple cards from one caller — a customer offering three different card numbers in succession because each was "declined" is classic phone-based card testing.
  • Repeat calls from the same number — same caller-ID hitting the payment line with different names or order references is a strong organised-fraud signal.
  • Strings of small transactions — multiple low-value charges in quick succession, especially on different cards, is the phone equivalent of online card testing.
  • Large first-time orders — a never-before-seen caller placing an unusually high-value order isn't automatically fraud, but combined with other risk markers it's worth a second look before the goods ship.

For automated phone payments — IVR card capture — the velocity logic can be applied to the payment gateway just as it would for an online transaction. For agent-assisted payments, the velocity check has to surface in the agent's payment screen so they can act on it in real time without having to interrupt the call.

Setting the Thresholds

The hard part of velocity checks is the numbers. Too tight and you decline legitimate customers; too loose and you let fraud through. The right thresholds depend on your business — a takeaway taking 2,000 transactions a night needs very different rules from a luxury watch dealer doing five orders a week.

The process that works:

  • Pull six months of historical transaction data and look at what "normal" actually means for you. Build the thresholds from your own data, not from a vendor's default settings.
  • Set the initial thresholds conservatively. You'd rather decline a few good customers and have them complain (so you can adjust) than miss the fraud you were trying to catch.
  • Tier the thresholds by customer risk. A repeat customer with three years of clean history can have looser rules than a brand-new account.
  • Combine velocity with the other tools — AVS, CVV check, device fingerprinting, 3DS2. Velocity is the cheap first filter; the more expensive tools deal with what gets through.
  • Watch your false-positive rate. If genuine customers are getting blocked too often, your thresholds are too aggressive and you'll find out about it through angry phone calls.
  • Have an escape valve. If a real business customer needs to make five legitimate purchases in an hour, give them a way to phone you and get unblocked rather than ramping up the threshold for everybody.

Where Velocity Sits in a Wider Strategy

Velocity checks are best as one layer in a stack, not the whole defence. A sophisticated fraudster who knows you use velocity will adapt — pace their attacks below the threshold, rotate through proxy IPs and devices, spread the activity across multiple stolen accounts. Velocity alone doesn't stop that.

Combine velocity with address verification, CVV checks, device fingerprinting, risk scoring, and an authentication step like 3D Secure, and you've got multiple things a fraudster has to defeat at the same time. That's a much harder problem than defeating any one of them. The layers cover each other's weaknesses — that's the point.

How Paytia Uses This

Paytia's PCI DSS Level 1 certified platform incorporates velocity checks as part of its thorough security approach. By processing phone payments through DTMF suppression, Paytia ensures card data is protected at every stage.

Frequently Asked Questions

What is velocity checks?

They're fraud rules that watch how often something is happening — same card used multiple times in a short window, same IP submitting multiple declines, large total value on a single card in an hour — and flag or block the activity when it crosses a threshold. They're the cheapest first line of defence against automated card testing.

Why is velocity checks important for PCI DSS?

PCI DSS doesn't prescribe velocity checks by name, but the standard does require you to detect and prevent unauthorised use of card data and to act on suspicious activity. Velocity checks are one of the simplest ways to evidence that you're doing that, and they protect you from the chargeback and fine cascade that follows a successful card testing attack.

How does Paytia handle velocity checks?

On phone payments specifically, the velocity rules sit in the payment gateway and the rules in our platform around how many failed card attempts an agent can make on a single call. We don't replace your fraud engine; we make sure the phone channel doesn't become the soft entry point that bypasses it.

See how Paytia handles velocity checks

Book a personalised demo and we'll show you how our platform works with your setup.

PCI DSS Level 1
Cyber Essentials Plus

Trusted by law firms, insurers, healthcare providers and regulated businesses worldwide. Learn more about Paytia