Velocity limits

Velocity limits are rules that restrict how many times a specific action can be performed within a defined time period. Examples include limits on the number of login attempts per minute, withdrawals per hour, or password reset requests per day.

For financial and crypto services, velocity limits are a core fraud and security control. They slow down automated attacks, reduce the impact of compromised credentials, and limit losses from rapid, suspicious activity.

Why velocity limits are used

Velocity limits address several key risks.

Preventing automated attacks

• Credential stuffing – attackers try large numbers of stolen username/password combinations. Velocity limits on login attempts make these attacks slower and less effective.
• Brute-force attacks – limits on password or OTP guesses prevent attackers from rapidly trying many combinations.
• Account enumeration – limits on actions like “check if this email is registered” reduce the ability to harvest valid accounts.

Limiting fraud and abuse

• Rapid withdrawals or transfers – limits on how many withdrawals or outgoing transfers can be made in a short window reduce the damage from account takeover.
• Bonus and referral abuse – limits on sign-ups, referrals, or promotional claims from the same device, IP, or account prevent systematic abuse.
• Card testing – limits on how many card transactions or validation attempts can be made in a short period reduce fraud losses from stolen card data.

Protecting systems and users

• Denial-of-service mitigation – rate limits on API calls or requests help protect infrastructure from overload.
• User safety – slowing down critical actions (for example, password resets, 2FA changes) gives users and support teams time to detect and respond to suspicious activity.
• Operational manageability – by capping the rate of high-risk actions, teams can investigate alerts without being overwhelmed.

How velocity limits work

Velocity limits are implemented as rules that count actions over time and enforce thresholds.

1. Defining the action and window

The service defines:

• Which action to limit, such as:
  • Login attempts.
  • OTP requests.
  • Withdrawals or transfers.
  • Password reset requests.
  • New beneficiary or wallet address additions.
• Time window(s) for the limit, such as:
  • Per minute, per hour, per day.
  • Multiple overlapping windows (for example, 5 attempts per minute and 20 per hour).

2. Counting and tracking

For each relevant subject (user, account, device, IP, or combination):

• The system maintains counters for the number of times the action has been performed in each time window.
• Counters are updated in real time as actions occur.
• Old entries expire as they fall outside the time window (for example, using a rolling window).

3. Enforcing limits

When a new action is requested:

• The system checks the current count against the defined thresholds.
• If the limit is not exceeded, the action is allowed and the counter is incremented.
• If the limit is exceeded, the action is:
  • Blocked immediately.
  • Delayed (for example, “try again in 10 minutes”).
  • Allowed only with additional verification (for example, extra 2FA, manual review).

4. Response and escalation

Depending on the severity and context:

• The user may see a generic message (for example, “Too many attempts. Please try again later.”) to avoid revealing detailed security logic.
• Security or fraud teams may be alerted if limits are repeatedly hit, especially from the same IP, device, or across multiple accounts.
• Additional controls may be triggered, such as temporary account locks, mandatory password changes, or enhanced monitoring.

Common types of velocity limits

Velocity limits are applied across many parts of a financial or crypto service.

Login and authentication

• Login attempts – for example, maximum 5 failed logins per 15 minutes per account or IP.
• OTP requests – limits on how many SMS or authenticator codes can be requested in a given period.
• Password reset requests – caps on how often a user can request a reset link or code.
• 2FA changes – limits on how frequently 2FA methods can be added, removed, or changed.

These limits protect against credential stuffing, brute-force attacks, and account takeover.

Transactions and transfers

• Withdrawal count – maximum number of withdrawals per hour or day.
• Transfer frequency – limits on how many outgoing transfers can be made in a short window.
• Beneficiary additions – caps on how many new recipients or external addresses can be added per day.
• Trade frequency – limits on the number of trades or orders in a very short period (especially for new or high-risk accounts).

These limits reduce the impact of compromised accounts and rapid fraud schemes.

Onboarding and promotions

• Account creation – limits on sign-ups from the same IP, device, or phone number to prevent mass account creation.
• Referral claims – caps on how many referral bonuses can be claimed in a period.
• Promotional offers – limits on how often a user can claim certain promotions or rewards.

These controls prevent bonus abuse and synthetic identity fraud.

API and system access

• API rate limits – maximum number of API calls per second, minute, or hour per key or IP.
• Admin actions – limits on sensitive administrative operations to reduce insider risk and accidental mass changes.
• File uploads or data exports – caps on frequency to prevent data exfiltration or system overload.

These protect both the platform and its users from abuse and technical issues.

Velocity limits vs amount limits

Velocity limits are related to but distinct from amount-based limits.

Velocity limits

• Focus on frequency and speed of actions.
• Example: “No more than 5 withdrawals per hour.”
• Primarily target rapid, automated, or burst behaviour.

Amount limits

• Focus on value of actions.
• Example: “Maximum $10,000 in withdrawals per day.”
• Primarily target large cumulative losses, even if spread over time.

Most services use both together. For example:

• “Up to 5 withdrawals per day, with a total limit of $20,000 per day.”
• “Maximum 3 external address additions per 24 hours, and no more than 10 per week.”

This combination limits both rapid bursts and large cumulative exposure.

How velocity limits affect users

From a user’s perspective, velocity limits may be visible in several ways.

Normal use

• Most users never hit velocity limits during everyday activity.
• Limits are set high enough to accommodate normal behaviour while catching abnormal patterns.

High-frequency activity

• If you perform many similar actions in a short time (for example, multiple withdrawals, many login attempts, repeated OTP requests):
  • You may see messages like “Too many attempts. Please wait before trying again.”
  • Some actions may be temporarily unavailable until the time window resets.
• This is intentional to protect your account and the platform.

Suspicious or compromised accounts

• If an attacker tries to:
  • Rapidly guess your password.
  • Request many OTP codes.
  • Execute multiple withdrawals quickly.
• Velocity limits can:
  • Slow or stop the attack.
  • Trigger alerts and additional security checks.
  • Give you and the support team time to respond.

Travel or unusual patterns

• If you are traveling or using the service from multiple locations or devices in a short period:
  • Some actions may be flagged as higher risk when combined with velocity signals.
  • You may be asked for additional verification, even if you do not exceed strict velocity thresholds.

Tuning and balancing

Setting velocity limits is a balance between security and usability.

Too strict

• Legitimate users may be blocked during normal activity (for example, power users, traders, or people managing multiple accounts).
• Increased support workload from users who cannot perform needed actions.
• Frustration and potential churn if limits feel arbitrary or overly restrictive.

Too lenient

• Attackers can perform many attempts or transactions before being stopped.
• Higher fraud losses and greater exposure from compromised accounts.
• More noise for security teams, making it harder to spot real attacks.

Best practice is to:

• Use data-driven thresholds based on typical user behaviour.
• Segment limits by user type, verification level, and risk profile.
• Continuously monitor and adjust limits as patterns and threats evolve.

Good practices for users

To avoid unnecessary friction from velocity limits:

• Avoid rapid, repeated attempts for logins, OTPs, or password resets; wait a few minutes between tries if something fails.
• If you need to perform many similar actions (for example, multiple withdrawals), space them out over time where possible.
• Use official apps and websites; automated scripts or bots are more likely to trigger velocity limits and security blocks.
• If you legitimately need higher frequency (for example, for business or trading activity), contact support to discuss appropriate limits or account tiers.
• If you hit a limit unexpectedly, treat it as a possible security signal and review your account activity.

Good practices for services

For platforms implementing velocity limits:

• Define clear, documented velocity rules for key actions (login, OTP, withdrawals, onboarding, API).
• Use multiple time windows (for example, per minute, per hour, per day) to catch both rapid bursts and sustained abuse.
• Combine velocity limits with other controls (risk scoring, device fingerprinting, IP monitoring, amount limits).
• Monitor false positives and adjust thresholds to minimise impact on legitimate users.
• Provide user-friendly error messages that explain the restriction without revealing detailed security logic.
• Ensure security and support teams can quickly identify and respond when velocity limits are triggered at scale.