Velocity Check

Velocity checks are the first-line fraud defense for most payment systems. They operate on the principle that legitimate customer behavior exhibits natural frequency limits — a real cardholder rarely makes more than a handful of purchases per hour on the same card — while fraudulent behavior (automated carding, credential stuffing, BIN attacks) generates transaction volumes that spike far above normal baseline.

What Velocity Checks Measure

Velocity rules can be applied to any transactional attribute that may be shared across fraudulent activity:

Card-level velocity:

• Number of authorization attempts on a single PAN in the last hour/day
• Number of declined transactions on a card before a successful authorization
• Spend amount across transactions in a time window

Device and network signals:

• Number of distinct cards attempted from the same device fingerprint or device ID
• Number of transactions from the same IP address
• Rapid geographic transitions (a cardholder in Singapore and Vietnam within 30 minutes)

Email and account velocity:

• Number of new accounts created from the same IP or device
• Number of payment methods tried on the same account
• Multiple accounts sharing the same card

BIN-level velocity:

• Unusual transaction volume from a single BIN range (may indicate a compromised batch of cards from the same issuer)

Threshold Setting and False Positives

Velocity check thresholds must be calibrated to the specific merchant’s baseline transaction patterns. A threshold that is too aggressive blocks legitimate customers; too permissive and fraud slips through. Common approaches:

Static thresholds: Fixed rules (e.g., block if >5 card attempts per hour). Simple to implement, but not adaptive to seasonality or business model.

Dynamic thresholds: Limits that adjust based on rolling baseline behavior, flagging anomalies relative to what is normal for that merchant or segment.

Soft decline vs. hard block: Rather than immediately blocking, velocity triggers can be set to require additional authentication (3DS challenge, OTP) below a blocking threshold, reducing friction for edge-case legitimate users.

False positive rates matter commercially. A velocity rule that blocks 100 fraud transactions but also declines 50 legitimate orders has a significant revenue cost that must be weighed against the fraud savings.

Velocity Checks vs. Full ML Fraud Scoring

Velocity checks are deterministic rules, not machine learning models. They are faster (sub-millisecond), more transparent (easy to audit and explain), and simpler to tune than ML models. However, they address specific known patterns and can be gamed by fraudsters who distribute attacks across many cards or IPs to stay below thresholds.

A complete fraud prevention stack typically layers velocity checks with:

• Device fingerprinting and behavioral analytics
• ML-based fraud scoring models
• 3DS authentication
• Address verification (AVS) and card security code checks

Southeast Asia Fraud Patterns

SEA-specific fraud patterns require local calibration of velocity rules:

BIN attacks: Testing stolen card data in bulk is common in the region. BIN enumeration attacks — guessing card numbers within a known BIN range — generate high authorization attempt volumes on low-value transactions. Low-value transaction velocity (e.g., $0.01 auth attempts) is a strong indicator of this pattern in SEA.

Cross-border card fraud: SEA-issued cards used fraudulently on international merchant sites exhibit specific velocity patterns — rapid spend across multiple geographies within minutes. Acquirers in Singapore and Hong Kong see this frequently due to their role as cross-border processing hubs.

Account takeover: Credential stuffing attacks against e-commerce platforms in SEA are high-volume. Login attempt velocity and payment method change velocity are important controls for platform operators.

Shared infrastructure fraud rings: SEA fraud networks often operate from a limited set of IP ranges or mobile carrier connections. Carrier-level velocity signals (high transaction counts from a single mobile network ASN) can be effective but require carrier cooperation or proxy/VPN detection.

Merchants with significant SEA transaction volume should review their velocity configurations against region-specific fraud typologies, as rules calibrated for US or European baseline fraud patterns may be misconfigured for SEA risk profiles.