Velocity rules
Velocity rules prevent automated bot attacks and card testing scripts by restricting payment frequency within defined time windows. Fraud rules administrators can configure transaction velocity checks to block repetitive attempts from specific cards, IP addresses or user accounts before processing.
- Category
- Risk
- Capabilities
- 6
- Available on
- All plans
Fraud rules administrators face constant threats from automated card testing scripts and botnet attacks. Malicious actors deploy scripts to attempt thousands of small-value authorisations in rapid succession, validating stolen payment details while generating excessive gateway fees and artificially inflating decline rates across the broader payment infrastructure.
Cardflo provides strict time-based rule sets to mitigate high-frequency attacks before they reach the acquirer network. Administrators can deploy payment velocity limits across rolling time windows, immediately declining subsequent attempts from the same IP address, email or card PAN once the defined volume or count threshold is breached.
Setting transaction frequency limits per card or IP automatically prevents fraud. This protects merchant revenue and safeguards MIDs by enforcing proactive risk management across all acquirer partners.
Velocity rules overview
Protecting a checkout environment requires precise time-based constraints that identify unnaturally fast purchasing behaviour. Velocity rules allow administrators to construct specific thresholds based on the time elapsed between transactions originating from identical data points.
While overarching risk logic belongs in a primary risk engine, non-time based attribute filtering requires dedicated transaction rules, and live monitoring queues sit within real-time fraud monitoring, velocity management specifically handles temporal constraints. The Cardflo orchestration layer measures frequency and volume spikes in milliseconds.
Administrators define exact sliding windows, from single minutes to thirty days, placing maximum caps on card usage, device fingerprints, or total basket values. Once an entity exceeds its allotted authorisation limit, the system declines subsequent traffic automatically, preventing authorisation fees and shielding acquirer partners from processing thousands of fraudulent card testing attempts.
How velocity rules works
Defining the time window
Administrators select the precise duration for the temporal constraint, ranging from rolling minute-by-minute measurements to fixed daily or monthly cycles. The orchestration layer tracks incoming traffic against this specific timeframe, storing the timestamp of each payment attempt in a central database. This baseline establishes the foundation for calculating event frequency across different user entities and payment instruments over time.
Selecting the tracked data point
The rule configuration requires a specific data element to monitor across the chosen timeframe. Fraud teams can isolate device fingerprints, email addresses, billing postcodes, or specific bank identification numbers. The platform aggregates all checkout attempts sharing this exact data point, regardless of whether the user attempts to switch cards, alter their name or utilise different acquirer partner routes.
Setting frequency and volume thresholds
The final configuration step determines the maximum permitted count or total currency value within the defined window. Once the aggregated attempts reach this numerical cap, the system triggers the velocity fraud prevention mechanism. Any subsequent payment requests sharing the tracked data point receive an automatic soft or hard decline without ever reaching the authorisation stage.
Why velocity rules matters
Mitigating gateway authorisation fees
Automated bot scripts can generate tens of thousands of authorisation attempts in a single hour. Each attempt incurs a gateway fee, even if the issuing bank eventually declines the transaction. Limiting transaction frequency at the orchestration layer intercepts these requests before submission, protecting merchants from severe financial losses caused by raw authorisation costs during a coordinated attack.
Shielding acquirer partner relationships
Submitting a massive volume of failed transactions damages merchant credibility with acquirer partners and card schemes. Card testing spikes artificially inflate decline ratios, which can trigger network compliance reviews or mandatory remediation programmes. Implementing time-based constraints ensures that bulk fraudulent attempts never reach the processing network, maintaining a healthy approval ratio and preserving stable processing agreements.
Regulatory notes for velocity rules
Scheme compliance and testing mitigation
Major card networks like Visa and Mastercard enforce strict guidelines regarding authorisation attempt manipulation. Merchants experiencing high volumes of automated card testing face immediate financial penalties under scheme compliance frameworks.
Failing to intercept bot attacks artificially inflates network decline rates, triggering mandatory risk reviews and potential processing suspensions.
Employing strict frequency limits at the gateway level is a recognised standard for maintaining compliance with scheme authorisation requirements.
By blocking repetitive testing sequences before transmission to the acquirer network, merchants preserve their authorisation ratios, avoid scheme monitoring programmes, and ensure their infrastructure meets baseline security expectations.
Data retention for velocity tracking
Effective velocity management requires the temporary storage and rapid retrieval of transaction data points, including IP addresses, email hashes, and truncated primary account numbers.
Under the General Data Protection Regulation and similar frameworks, this data must be processed lawfully under the basis of fraud prevention and network security.
The orchestration layer handles this temporary data aggregation strictly within the bounds of PCI DSS compliance.
Stored data used for calculating temporal frequency is encrypted, tokenised, and automatically purged when it falls outside the maximum configurable rolling window, ensuring that fraud mitigation does not compromise consumer data privacy requirements.
Velocity rules use cases
Bot controls for instant fulfilment
Digital voucher merchants face automated card testing because low-value codes are fulfilled immediately and bots can submit many card numbers within seconds. Cardflo applies rolling card, device and IP counters, blocking further authorisation attempts when configurable transaction volume limits are reached within the selected time window.
Recurring payment frequency controls
Online services can receive bursts of newly created accounts from one IP, with each account used to test a different stolen card. Cardflo combines per-IP and per-user velocity checks, limiting authorisation attempts and distinct card numbers across minute or hourly windows before bot traffic reaches acquirer partners.
Ticket purchase volume limits
Ticket operators face concentrated bot traffic during timed on-sales, where automated buyers spread purchases across accounts while reusing cards, IP addresses or BIN ranges. Cardflo enforces counters for successful and attempted transactions during the release window, declining activity that exceeds configured purchase frequency or volume limits.
BIN rotation attack controls
Fraudsters rotate card numbers across multiple BINs while retaining the same IP, device or user session, creating rapid sequences of low-value authorisation attempts. Cardflo tracks distinct cards and BINs against shared identifiers within configurable intervals, then blocks further attempts when the permitted count is exceeded.
Velocity rules by the numbers
This range reflects industry-standard results for merchants who implement automated velocity blocks on card-testing bursts compared to those relying solely on issuer-side declines.
Typically, well-tuned velocity thresholds flag a small minority of transactions for manual review, ensuring that risk teams focus on high-probability fraud without overwhelming operational capacity.
Most modern gateway risk engines execute velocity check logic within this timeframe, representing a negligible impact on the total checkout response time for the end consumer.
Methodology: these figures are illustrative ranges drawn from published industry data and observed merchant cohorts, not guarantees. Actual results depend on your risk profile, card mix, geography and acquiring setup, and are confirmed only in your own pricing and approval terms.
Related terms
Talk to our team about a live rollout across our acquirer partners' rails.
What you get with Velocity rules
- Enforce strict payment velocity limits based on the number of attempts from a single IP address per hour.
- Block card testing sequences by restricting the total number of distinct cards used per user session.
- Configure card velocity tracking to decline subsequent transactions when a specific primary account number exceeds daily caps.
- Calculate cumulative transaction values over thirty-day rolling windows to identify and restrict excessive spending behaviour automatically.
- Define unique frequency thresholds for specific geographic regions or high-risk business models requiring tighter fraud controls.
- Restrict the total count of failed authorisation responses permitted from a single email address within five minutes.
A short scoping call, then a written plan for your MIDs.
Questions about Velocity rules
How do rolling time windows differ from fixed time windows?
Fixed windows reset at a specific time, such as midnight Coordinated Universal Time, regardless of when the first transaction occurred. A user could technically perform their maximum allowed volume at 23:59 and repeat the process at 00:01.
Rolling time windows measure backwards from the exact millisecond of the current transaction attempt.
If a rule restricts five purchases per twenty-four hours, and a user attempts a sixth, the system checks precisely the preceding twenty-four hours to calculate the total, offering far superior protection against automated bot scripts.
Can velocity checks monitor total transaction value instead of just transaction count?
Yes, administrators can configure temporal limits based on aggregate currency values rather than raw transaction volumes. This is particularly useful for identifying account takeover scenarios where a fraudster attempts to drain stored value or maximise a stolen card limit before detection.
The orchestration layer converts incoming amounts to a unified base currency in milliseconds, calculating the cumulative spend against the defined temporal threshold. If the requested transaction pushes the total over the allowable limit, the system declines it immediately.
What happens to a user who legitimately triggers a velocity limit?
When a legitimate customer exceeds a configured threshold, the platform returns a specific decline code indicating a temporal restriction. Depending on the merchant setup, the frontend application can display a custom message asking the customer to try again later or contact customer support.
For high-value users, finance teams can manually whitelist specific email addresses or customer IDs within the dashboard, exempting them from standard frequency constraints while maintaining baseline security for unverified traffic.
Should declined attempts count towards card testing velocity limits?
Declined attempts should normally contribute to card testing velocity limits because automated attacks often generate many unsuccessful authorisations before finding valid card details.
Administrators can configure time windows and attempt limits by card, IP address, user account or BIN, while choosing which payment statuses enter each count.
Including declines and technical failures helps block repeated attempts even when no payment is approved, although thresholds should be tested against legitimate retry patterns.
Related features.
Related guides.
See how Cardflo compares.
Ready to improve your payments setup?
Tell us about your business. We'll match you with the right acquiring partners and the right route, typically inside a week.