Card fraud velocity rules: stop repeated payment attempts before they become a loss

Velocity controls look for too many payment attempts within a short period using the same card, device, customer account, IP address or other identifier. They are useful against card testing, automated fraud and account takeover, but aggressive rules can also block genuine customers if they ignore normal buying patterns.

Card testing often creates bursts of small attempts

Fraudsters can use stolen card lists to make many low-value authorisation attempts and identify which credentials remain valid.

A merchant that sees dozens of cards from one device or hundreds of low-value failures in minutes should treat that pattern differently from ordinary checkout declines.

Use several velocity dimensions

Rules can count attempts by card, customer account, email, device fingerprint, IP address, shipping address or merchant account.

Combining signals is stronger than blocking one IP after three attempts, because households, offices and mobile networks can legitimately share addresses.

Choose time windows that match the attack

A five-minute rule can catch automated testing, while a 24-hour rule can detect repeated account abuse or excessive refund attempts.

Use different limits for low-value subscriptions, high-ticket retail and marketplace sellers. One global threshold creates unnecessary false positives.

Decline, challenge or review depending on confidence

Not every velocity breach needs a hard block. The merchant can require stronger authentication, hold the order for review or reduce limits.

Use the least disruptive action that still protects the payment environment. High-confidence automated attacks can be blocked more aggressively than ambiguous customer behaviour.

Watch false-positive and approval impact

Track how many blocked transactions later prove legitimate and how much fraud was prevented. A rule reducing fraud by £5,000 but rejecting £50,000 of genuine margin can be poorly calibrated.

Review thresholds after promotions and new-market launches because legitimate transaction frequency can change suddenly.

Escalate sustained attacks beyond the fraud engine

Large card-testing attacks can consume gateway capacity and create scheme or processor concerns. Involve the payment provider and security team when attack volume rises materially.

Protect API keys, CAPTCHA or account controls where appropriate and investigate whether attackers found an unprotected checkout endpoint.

Worked example: an ecommerce merchant receives 3,000 £1 payment attempts in ten minutes from a small set of devices but thousands of different card numbers. A simple per-card rule misses the attack because each card is used once. Device and IP velocity makes the common pattern visible.

Segment trusted repeat customers. A corporate buyer can legitimately place 20 orders in one hour, while a brand-new account doing the same thing can be high risk. Velocity should work with customer history rather than ignore it.

Keep rule changes under change control. During an attack, teams can tighten thresholds quickly, but emergency settings should be reviewed and relaxed when the incident ends so genuine customers are not blocked indefinitely.

Review velocity by payment outcome, not only attempts. Ten successful transactions from one card in two minutes can be as suspicious as twenty declines, depending on the merchant. Rules should consider success, failure, refund and chargeback patterns together.

Use device reputation over time. A device with a long history of good orders can receive more tolerant thresholds than a new device creating several accounts in minutes. This reduces false positives without giving trusted accounts unlimited freedom.

Coordinate velocity controls with promotional events. A flash sale can legitimately increase transaction frequency and create many first-time customers. Fraud teams should adjust monitoring before the campaign rather than discovering afterward that normal demand was blocked.

Keep separate thresholds for login, card-add and purchase events. An attacker can test several stolen cards by adding them to one compromised account before making only one purchase, so purchase velocity alone can miss the pattern.

Use refund and promotion abuse signals as well. A customer creating ten accounts to redeem a first-order discount can be commercially abusive without using stolen cards. Fraud tooling can support broader payment-risk rules where terms and privacy policies permit.

Review issuer-decline feedback. A sudden surge of "do not honour" or stolen-card declines can indicate the merchant is under attack even before internal velocity thresholds are exceeded. Processor and issuer signals should feed the same fraud dashboard.

Keep manual-review queues sized realistically. Sending 20 percent of orders to human review during a campaign can delay fulfilment and create its own loss. Velocity rules should prioritise the highest-risk cases rather than simply move automated uncertainty to staff.

Document every production rule with owner, threshold, purpose and review date. Fraud controls become difficult to manage when dozens of old rules accumulate and nobody remembers why they exist. Periodic cleanup reduces contradictory logic and hidden false positives.