Velocity Signals

What it measures

Velocity is the most-used and most under-designed feature family in fraud. Every velocity feature is a combination of four choices:

aggregation of event per entity over window e.g., distinct cards of authorization attempts per device over the last 1 hour

Why it matters

Almost every scaled transaction fraud attack has to do more of something than a legitimate customer would: more attempts, more accounts, more instruments, more money in or out, faster than normal. Velocity features measure that excess directly.

Velocity is also how you contain a loss once something has slipped through. Velocity and Exposure Limits are velocity features with an enforcement action attached.

Design patterns

1. Single-entity velocity

Counts and sums for one entity: "withdrawals per account per 24h", "logins per account per hour". These are necessary but easy to dilute, because the attacker can spread activity across accounts.

2. Cross-entity velocity (distinct-count features)

The form is distinct B per A over a window. It's the highest-value pattern because it measures fan-in and fan-out, which is how operations show up:

Fan-out from a stable entity (one device → many accounts) and fan-in to a cash-out point (many accounts → one payout destination) are the two shapes to cover first. Two-hop versions are graph work; see Entity Link Analysis and Graph Analytics.

3. Relative velocity (versus own baseline)

"Today's outbound vs this account's trailing 90-day daily average." This catches Bust-Out Fraud, ATO cash-outs and scams on established accounts, where absolute amounts may be normal for the population but abnormal for this customer. Use ratios or z-scores against the entity's own history, with a floor for new entities.

4. Population velocity (sentinels)

Aggregates across all entities: sign-ups per minute, approval rate per BIN, redemptions per offer per hour, login success rate. These are attack alarms more than per-event features, and they are the fastest way to spot a new MO or a Business Logic Exploitation in progress. See Playbook - Novel Attack Detection Members and Fraud Incident Response.

5. Sequence-aware velocity

"Payout destination changes in the 7 days before a withdrawal", "time since last contact change at the moment of transfer". These bridge velocity and Session Behavior Anomalies: the window is anchored on a risky event rather than on "now".

Windows and decay

Compute the same feature over several windows. A small family (minutes, hours, days, weeks) lets rules and models see both bursts and slow builds. Ratios between windows (last hour vs last week's hourly average) are often more predictive than either window alone.

Exponential decay is underused. A decayed counter keeps a single number per entity that reflects recent activity more than old activity, without storing every event. It suits long-memory features like "claims behavior" or "returns propensity" where calendar windows are too blunt.

How to collect it

• Build. Velocity is only as good as your entity resolution and event logging. Most of the difficulty is engineering:
  • Point-in-time correctness. Training features must be computed as of each historical event, using only data available then. Leakage here is the most common reason a velocity-heavy model looks great offline and disappoints in production. See Fraud Data Architecture.
  • Online/offline parity. The real-time feature store and the batch training pipeline must compute the same thing. Test this explicitly.
  • Late and out-of-order events. Returns, chargebacks and ACH returns arrive days later. Decide whether features use event time or processing time, and document it.
  • Idempotency. Retries and duplicate events inflate counts. Deduplicate on event IDs.
  • Cardinality and hot keys. Shared IPs (carrier NAT) and popular merchants are "hot" entities with huge counts. Cap, sample, or exclude them, or the feature becomes noise and the store becomes slow.
  • Approximate distinct counts. Probabilistic sketches make high-cardinality distinct counts feasible at scale. Accept small error for big savings, but not where an exact count is a regulatory limit.
• Buy. Fraud platforms and payment processors ship velocity features on their own entities (cards, merchants, network-level counts) that you can't compute yourself. Consortium velocity (activity across institutions) is a buy-only signal; see Credit Bureau and Consortium Signals.

How to use it

• Pick entities attackers can't cheaply rotate. Velocity on IP alone is easy to dilute through residential proxies (IP Reputation and Proxy Detection). Velocity on payout destination, funding bank account, or a hardware-anchored device key is much more expensive to dilute.
• Count attempts and failures as well as successes. Card testing and stuffing are visible in declines and failed logins long before any success.
• Normalize by exposure. "Five redemptions per day" means something different for a power user than for a two-day-old account. Combine with tenure (Customer Tenure and History).
• Use velocity to set limits as well as to flag. Velocity and exposure limits cap the damage of what detection misses, especially on instant rails and provisional funds (Velocity and Exposure Limits, Funds Availability Holds).
• Feed models and rules from the same feature store, so rule authors and data scientists aren't maintaining two definitions of "withdrawals in 24 hours" (Rules Engine, Machine Learning Models).
• Document every feature (entity, event, aggregation, window, time semantics, owner). Undocumented velocity features become unexplainable rule triggers during audits and QA (Rule Governance and Change Management).

Strengths and limitations

Strengths: simple, explainable, cheap at decision time; works across every industry and rail; the backbone of both rules and models; essential for containment.

Limitations:

• Fixed velocity limits can be probed and then operated just under. Keep thresholds internal, prefer scored features over published hard limits, and vary responses. Assume any static limit will eventually be learned.
• Distributed attacks dilute single-entity velocity. Cross-entity and population features are the countermeasure.
• Slow attacks (aged accounts, patient bust-outs) stay under short windows. Long windows and relative velocity address this.
• Engineering debt in feature pipelines is a frequent root cause of silent detection failures. Monitor feature distributions and null rates (Model Risk Management).

False positives and fairness

• Legitimate bursts: payday, holidays, tax refunds, promotions you launched yourself, market volatility for brokerage customers, and end-of-month bills.
• Shared entities: households, carrier NAT, campus networks and office IPs inflate counts on device, IP and address.
• Power users and small businesses: resellers, gig workers receiving many P2P payments, and others using consumer accounts heavily. Distinct-senders-per-recipient features over-fire on them, so consider segment-specific baselines.
• Benefit and payroll timing concentrates inflows for lower-income customers on specific days. Population baselines should know the calendar.

Privacy and compliance considerations

• Velocity features are derived from personal data and inherit its obligations. Keep them in fraud-purpose stores with defined retention (Privacy and Data Use in Fraud Prevention).
• Nacha's 2026 fraud-monitoring rules require ODFIs and many originators, third-party service providers and third-party senders to have risk-based processes reasonably intended to identify entries suspected of being unauthorized or authorized under false pretenses. Phase 1 took effect March 20, 2026 and Phase 2 on June 19, 2026 (practically June 22, because June 19 is a federal holiday). Velocity on originations, payees and returns is a natural part of such processes. See Nacha Rules and ACH Risk.
• NIST SP 800-63A-4 lists transaction analytics, including velocity anomalies, among recommended fraud checks for identity proofing.
• Customer-facing limits (daily transfer limits) should be disclosed where required. Internal detection thresholds should not be.

Mechanisms it helps detect

Card Testing · Credential Stuffing · Fake Account Creation (Bots) · Multi-Accounting · Promo Code Abuse · Referral Abuse · Sign-Up Bonus Abuse · Receipt Fraud (Cashback) · Instant Funding Abuse (Kiting) · ACH Funding Fraud · Money Mules · Bust-Out Fraud · Real-Time Payment Rail Fraud · Refund and Return Fraud

Related signals and controls

• Signals: Fast In Fast Out Patterns, Transaction Pattern Anomalies, Entity Link Analysis, Device Reputation and Linkage, Promo and Reward Redemption Patterns, Customer Tenure and History, Session Behavior Anomalies
• Controls: Velocity and Exposure Limits, Rate Limiting and Throttling, Rules Engine, Machine Learning Models, Real-Time Transaction Risk Scoring, Funds Availability Holds
• Program: Fraud Data Architecture, Real-Time Decisioning Architecture, Rule Governance and Change Management

Sources and further reading

• Nacha: Fraud monitoring Phase 1 and Phase 2 rules: effective dates (March 20 and June 19, 2026), covered parties, risk-based monitoring for unauthorized and false-pretenses entries.
• NIST SP 800-63A-4: transaction analytics on IP, geolocation and velocity anomalies as a recommended fraud check.
• OWASP Automated Threats to Web Applications: automated threat classes (carding, account creation, credential stuffing) defined by repetition and volume.
• FinCEN Alert FIN-2024-Alert004: rapid transactions on new or low-history accounts and immediate withdrawal after deposit as red flags.