Rate Limiting and Throttling

What it is

Rate limiting is the cheapest control in this vault and one of the most often misconfigured. Teams often treat it as an infrastructure concern (protect the servers). For fraud, the questions are which entity you're counting, on which endpoint, and what happens over the limit.

This note covers request-level limits on endpoints. Value-level limits on how much money can move are in Velocity and Exposure Limits. The two are complementary: rate limits stop discovery (finding a working card, code or password), and exposure limits cap what a discovery is worth.

What it stops (and what it doesn't)

It doesn't stop:

• Attacks spread across large residential-proxy and device pools, where each entity stays under its limit.
• One-try-per-account patterns, where the defense is aggregate failure-ratio monitoring.
• Losses once the attacker is in. That's for Risk-Based Authentication and Step-Up and Velocity and Exposure Limits.

Design considerations

• Count several entities. Per-IP limits alone are easily defeated by IP rotation. Key limits on device identifiers and accounts as well as IPs, enrich IPs with IP Reputation and Proxy Detection, and feed over-limit events into Velocity Signals so downstream models see them. Layer per-account, per-device, per-credential, per-instrument and per-target (for example, per BIN range) limits, plus global failure-ratio monitors that catch distributed attacks no single-entity limit sees.
• Don't lock out the real customer. Hard account lockout after N failed passwords lets anyone lock out any user. Prefer exponential back-off and step-up challenges over lockout, and don't count failures from clearly unrelated devices against the owner's own device. NIST SP 800-63B-4 caps consecutive failed attempts on one authenticator at 100 before it must be disabled, and recommends that prior failures be disregarded after a successful authentication.
• Respond in graded steps: slow down (tarpit), then challenge, then soft-fail, then block. A silent soft-fail (a generic response with no real validation) denies attackers a clean signal.
• Return uniform responses. Make sure the response to an over-limit request doesn't reveal whether the underlying credential, card or code was valid.
• Limit at the business layer as well as the edge. Edge and CDN limits see IPs, while the application sees accounts, cards and codes, so you need both.
• Watch for SMS and voice traffic pumping. OTP endpoints that send messages to attacker-chosen numbers can be abused for telecom revenue fraud. Limit per destination number and per destination prefix.
• Treat partner and aggregator traffic separately. Legitimate aggregators may need higher limits with their own credentials and monitoring.

Implementation path

Customer friction and trade-offs

• Well-tuned limits are invisible to nearly all customers. Friction shows up at the edges: shared IPs (offices, universities, carrier NAT), families on one device, and power users of validation flows (for example, someone adding several cards at once).
• Aggressive lockout produces support calls and gives attackers a denial-of-service lever against specific customers.
• Overly loose limits are invisible until card-network fines or a drained promo budget make them visible.

Measuring effectiveness

• Per-endpoint failure ratio and absolute failure volume, with alerting on deviations from baseline.
• Over-limit events per day by key type. Watch for a shift toward distributed patterns, which suggests the attackers have adapted.
• Card-testing outcomes: authorization decline ratios, small-amount auths, network program alerts.
• Customer impact: lockout-related support contacts; genuine customers hitting limits, which can be estimated from those who later succeed from the same device.
• Time to detect a distributed attack (global-ratio alert) versus time to loss.

Common failure modes

• IP-only limits.
• Unthrottled endpoints: OTP send/verify, balance-check or validation endpoints with no limit at all.
• Inconsistent coverage: limits on web but not on mobile or partner APIs.
• Lockout-as-defense, which harms real customers.
• Over-informative responses that reveal whether a credential, card or code is valid.
• Per-node counters: limits that reset on deploy or are counted per server instead of globally.

Regulatory and policy notes

• NIST SP 800-63B-4 §3.2.2:
  • Verifiers must limit consecutive failed attempts on an authenticator to no more than 100.
  • Disabled authenticators must be rebound before use.
  • Bot detection, increasing delays and risk signals are optional supplements.
• Card networks monitor merchants for excessive authorization attempts and card-testing patterns. Rate limits on card-add and checkout are a first-line way to stay out of those programs (see Card Network Dispute Rules).
• Telecom. SMS traffic pumping costs you money and can breach messaging-provider terms of service.

Mechanisms addressed

• Credential Stuffing (naive and medium-sophistication)
• Card Testing
• Promo Code Abuse and Gift Card Fraud enumeration
• MFA Bypass and OTP Interception (OTP guessing; push-prompt flooding)
• Fake Account Creation (Bots)
• Receipt Fraud (Cashback) mass submission
• Business Logic Exploitation that depends on rapid repeated requests

Related controls

• Bot Management and CAPTCHA
• Velocity and Exposure Limits
• Breached Password Detection
• Multi-Factor Authentication (MFA)
• Rules Engine
• Playbooks: Playbook - Card Testing Members, Playbook - Credential Stuffing Response Members

Sources and further reading

• NIST SP 800-63B-4 §3.2.2 Rate Limiting (Throttling): 100-consecutive-failure cap; rebind requirement; optional bot detection and back-off.
• OWASP Automated Threats to Web Applications: taxonomy for enumeration and automated-misuse patterns.