A velocity check counts events per identifier in a window
A velocity check counts events per identifier over a time window and flags counts that a real applicant pool would not produce. NIST's identity-proofing guidelines for digital identity providers describe fraud velocity checks as monitoring the frequency and pattern of transactions over time, and say they can protect against scaled and automated attacks. The event can be a started form, a one-time-password request or a submitted application. The identifier can be a device, an IP address, a phone number, an email address or a cluster of those linked together.
| Counter | What a spike suggests | Where it goes wrong |
|---|---|---|
| Device | One handset or emulator submitting many applications under different names. | A household sharing one phone looks the same. A reinstall can create a new app identifier and reset the count. |
| IP address | A script or device farm working from a small pool of addresses. | Offices and carrier-grade NAT put many real people behind one address, while residential proxy networks spread one bot across many. It stays worth keeping as a baseline. |
| Phone number | One number behind several identities. | Household members can share a number, so one number behind two identities is weak evidence alone. OWASP also advises checking the carrier type, since VoIP numbers are cheap. |
| Email address | Generated or disposable addresses created in bursts. | A count per domain also catches colleagues at one employer, and disposable-domain lists need regular refreshing. |
| Linked identifiers | A cluster of names that share a phone number, address, IP address or device. | One shared link is common among relatives. Clusters with several shared links are the strong case. |
Common counters and the main way each one goes wrong.
Windows matter as much as counts
A count means little without its window. A short window, measured in minutes, usually catches the burst a script produces, and a long window, measured in days, the slower ring that keeps every identifier under the burst limit. Run windows of different lengths, and avoid fixed-window counters: OWASP warns they allow bursts at the boundary between two windows and recommends sliding-window or token-bucket algorithms.
Where the line sits is a business choice: a lower threshold stops more scripts and holds more genuine applicants.
Single counters get beaten by rotation
Attackers adapt to whichever key is counted. OWASP notes that limits per IP address are coarse and defeated by residential proxy networks, and that limits per session are defeated by clearing cookies. Device identifiers are not permanent either: Android's developer guidance calls the Firebase installation ID relatively easy to reset, because it persists only as long as the app is installed. A ring that rotates addresses and reinstalls the app can look new on every attempt.
What survives rotation is the combination. OWASP notes that fingerprinting helps detect bots that rotate IP addresses but reuse client environments. The Federal Reserve's 2020 white paper describes link analysis that screens for multiple account applications from one IP address or device. So count distinct identities per device, per phone and per address, then count the clusters they form. Android's guidance sets a limit: a reset advertising ID must not be linked to the old one without the user's explicit consent, and it points to the Play Integrity API for abuse protection. The pages on recycled identities and device farms cover those patterns.
Behavioural signals show how the form was filled
Velocity says how much. Behavioural signals say how a form was completed, so they do not depend on which identifier a script rotates. NIST's identity-proofing guidelines require providers to run automated-attack protections such as bot detection and behavioural analytics, and OWASP lists behavioural signals and honeypots among application-layer controls. Signals a lender can log from a web form include:
- Form-fill timing: total time, time per field and how regular the intervals are.
- Typing versus paste: whether each field was typed, pasted or autofilled, and whether answers were corrected.
- Navigation and session pattern: how the applicant reached the form and whether the session restarted repeatedly.
- Honeypot fields: a hidden field that people never see. OWASP lists it as a cheap control with no impact on legitimate users, because bots fill it and humans do not. Build it hidden from screen readers and excluded from autofill, as OWASP's own markup does.
Treat each as weak evidence, because ordinary use produces every one: autofill fills a form in seconds, and an advert can send people straight to the form. The stronger case is the same pattern repeating across many applications from one source, such as near-identical timing on every field. Scripts that randomise delays or simulate typing weaken these signals, so use them as one input among several.
OWASP treats page-level telemetry such as mouse paths, scroll and focus as a last resort: collect it only on sensitive flows, with consent where the law requires it, disclose it in the privacy notice and keep raw signals for hours to days. NIST's guidelines require identity-proofing providers to assess the privacy risk of each fraud check before it goes live. Honeypots and mouse paths exist only on web forms; an app flow exposes a different set.
Checks misfire on shared devices, networks and habits
The Federal Reserve's 2020 white paper warns that focusing on any one characteristic alone can lead to false positives or disadvantage certain types of legitimate customers.
| Source of error | Why it happens | Safer handling |
|---|---|---|
| Shared handset | A 2022 YouGov survey of Android users, reported in a 2024 Google preprint, found that 73% of respondents in India and 39% in Nigeria share a phone with someone in their household. | Count distinct identities per device and require other signals before holding anyone. |
| Office or campus network | Devices behind one router share a single public IP address. | Use the IP address as a supporting signal and count by device and identity. |
| Carrier-grade NAT | An operator can share one public address among many subscribers. RFC 6269 says penalty-box defences, which block an address after too many requests, stop working under large-scale address sharing. | Avoid a hard limit per IP address. Step up verification instead of blocking. |
| Autofill and paste | Password managers and browsers fill fields in one step. NIST's authentication guidelines require password entry to allow password managers and autofill and recommend permitting paste, so the behaviour is ordinary. | Treat paste as context, never as a verdict. |
| Privacy browsers | OWASP notes that privacy-respecting users often look bot-like and advises against blocking on a hardened browser alone. | Prefer a challenge to a block. |
Common false-positive sources and a safer response.
OWASP describes a graduated response: log and flag at low confidence, step up the check at medium, restrict specific actions at very high, and hold with manual review only once abuse is confirmed. Hard-blocking on the first signal, it adds, gives attackers a clean signal to iterate against. In a lending flow a step-up can be a fresh phone verification.
Tune thresholds with outcome feedback
A threshold set once drifts out of date, because traffic changes and attackers adapt to fixed limits. NIST's identity-proofing guidelines require identity providers to monitor the performance of their fraud checks and the services that rely on them to review those checks periodically to adjust thresholds. In India, the Reserve Bank's 2024 fraud directions (para 3.1.3) require upper- and middle-layer NBFCs to review periodically the early warning indicators they use to monitor loan accounts and transactions.
- Log the decision with its signalsRecord which counters and behaviour signals fired, with the window and the count. OWASP lists hidden rules with no logging as an anti-pattern, because you cannot tune what you cannot see.
- Attach outcomes as they arriveJoin each decision to what happened next: the lender's status, then disbursal, then first-payment default once the first instalment falls due. Partner postbacks carry the early outcomes. The late ones arrive well after the click, so read recent cohorts as incomplete.
- Replay a candidate threshold on past trafficCount what the new limit would have held and compare the later outcomes of the held and released groups. Keep it when the held group's fraud or default rate is well above the released group's and the good applicants it catches cost less than the losses it avoids. Held applicants have no outcomes, so a live limit hides its own mistakes: release a small share through a step-up to measure them.
- Change one rule at a timeMove one threshold or window, keep the rest fixed, and watch the held share and the next batch's outcomes. Prefer a step-up to a stop while the evidence is thin.
- Review on a scheduleRepeat after any change in sources, products or markets. Lead quality by source covers the outcome measures that show when a source has shifted.
Behaviour and velocity in CYBERTECH screening
CYBERTECH reads counts and behaviour signals together with its other checks, and none decides alone. How our screening works covers all five.
NIST, OWASP and the Federal Reserve paper are US or industry guidance on good practice, not rules for lenders in India, Kazakhstan, Nigeria or Peru, where local data protection and lending rules apply. This is general information, not legal advice.
Related guides
- Screen loan leads for fraud and fit before they reach youFive checks, including fit to your own criteria, screen applicants before handoff. No single signal decides, and a stopped applicant is not delivered to you.
- Emulators and device farms are found by patterns, not one device checkHow emulators, rooted or cloned devices and device farms appear in loan applications and installs, which signals expose them and what lenders can control.
- Duplicate, recycled and synthetic identities hide between applicationsHow duplicate applications, recycled identities and synthetic identities appear in lead flows, and why de-duplication should run before billing.
- Measure loan lead quality by source, from approval to delinquencyHow a lender measures lead quality by source: approval, disbursal, first-payment default, 30+ DPD, fraud rate and cost per disbursed loan.
Sources
- NIST: Digital Identity Guidelines, SP 800-63A-4, Identity Proofing and Enrollment (2025)
- NIST: Digital Identity Guidelines, SP 800-63B-4, Authentication and Authenticator Management (2025)
- OWASP: Bot Management and Anti-Automation Cheat Sheet (2026)
- IETF: RFC 6269, Issues with IP Address Sharing (2011)
- Federal Reserve Banks: Mitigating Synthetic Identity Fraud in the U.S. Payment System (2020)
- Android Developers: Best practices for unique identifiers (2026)
- Google: Security and Privacy Product Inclusion, arXiv preprint (2024)
- Reserve Bank of India: Master Directions on Fraud Risk Management in NBFCs (2024)