The verification dashboard looks perfect. Completion is above forecast, SMS failures are barely visible, and new registrations keep arriving as the campaign scales. Then finance notices that payouts don't match the quality of the accounts behind them. Risk reviews the traffic and finds the same device fingerprints, shared network infrastructure, recycled identifiers, and unusually synchronized behavior hiding beneath a clean funnel.
That moment is familiar to teams running growth campaigns, onboarding flows, marketplaces, crypto products, and verification-heavy platforms. Suspicious activity detection isn't about distrusting every new user. It's about recognizing when several ordinary-looking actions form an organized pattern, then applying enough friction to protect the business without punishing legitimate customers.
Table of Contents
- When Verification Traffic Looks Too Clean The first checks to run
- What Suspicious Activity Detection Means The detection pipeline
- Core Signals and Data Sources Worth Watching
- Detection Techniques From Rules to Behavioral Models
- Implementation Path From Features to Feedback Loops Build features that describe relationships
- Metrics That Beat Model Accuracy Measure the queue, not just the classifier
- Why Virtual Numbers Change the Game Detect the network around the number
- Practical Best Practices You Can Ship Monday Tune actions by confidence
- Close the loop safely
When Verification Traffic Looks Too Clean
A campaign can look healthy right up until the first downstream signal breaks the story. The growth team sees successful OTP delivery and completed verification. Finance sees account credits, refunds, or payouts that don't fit the acquisition source. Support sees something stranger, the usual questions about failed codes, locked accounts, or missing rewards have almost disappeared.
That combination deserves investigation. Bots and coordinated operators don't complain about confusing screens. They repeat a working path, submit quickly, and move to the next account. A traffic surge with unusually consistent device characteristics, identical browser fingerprints, or the same network relationships across supposedly independent users can be more informative than the headline completion rate.
The first checks to run
Start with the funnel, but don't stop at verification completion.
- Compare account relationships: Look for repeated mobile numbers, email addresses, devices, IPs, referral codes, payment instruments, or payout destinations across profiles.
- Inspect timing: Synchronized sign-ups, identical delays between registration and OTP submission, and repeated retry patterns can indicate automation or campaign coordination.
- Follow the value: Connect verification events to credits, withdrawals, promotions, chargebacks, or account changes. Suspicion rises when the cleanest traffic produces the least credible value.
- Review the quiet channels: A sudden lack of support complaints isn't proof of abuse, but it can support the hypothesis that the traffic isn't behaving like ordinary customers.
Practical rule: A metric becomes a risk signal when it looks strong in isolation but becomes inconsistent with downstream behavior.
The growth team's instinct is to keep the campaign live. The risk team's instinct is to pause it. The productive response sits between those extremes: preserve evidence, isolate the affected cohort, slow only the riskiest paths, and test whether the suspicious relationships continue after friction changes. That approach protects legitimate acquisition while giving analysts enough context to determine whether “too clean” means efficient, automated, or coordinated.
What Suspicious Activity Detection Means
Suspicious activity detection continuously collects identity, device, network, and behavioral signals, compares them with known risk patterns, and determines what action to take before abuse becomes a loss. It is not a single KYC check, blacklist, or permanent yes-or-no verdict. On verification-heavy platforms, the same process must also distinguish coordinated multi-account campaigns from legitimate users moving through a high-friction funnel.
A production detection system handles three jobs: recording events, interpreting whether behavior is normal or coordinated, and deciding whether to allow the user, add friction, decline the action, or open a case. The stack must support each job without treating one signal as proof of intent.
The detection pipeline
A production system typically includes these layers:
- Collection: Capture login, registration, verification, profile, payment, payout, and support events with timestamps and stable entity identifiers.
- Enrichment: Add device characteristics, network classification, phone attributes, geolocation context, account history, and links between related entities.
- Feature engineering: Turn raw events into measures of reuse, velocity, concentration, sequence order, and change from a user's normal behavior.
- Scoring: Apply deterministic rules, weighted heuristics, statistical methods, or machine learning models.
- Decisioning: Map the result to an action, such as allow, step-up verification, manual review, temporary hold, or decline.
- Feedback: Return analyst outcomes, appeals, confirmed abuse, chargebacks, and overrides to the detection logic.
The key difference from a one-off identity check is continuity. A user can pass document verification and later join a coordinated multi-account campaign. A legitimate user can also present a disposable virtual number, shared network, or changing device without committing abuse. Detection therefore evaluates context across sessions, relationships, and outcomes. Rules should create explainable triggers, while review and feedback determine whether thresholds catch abuse without blocking legitimate campaign traffic.
Core Signals and Data Sources Worth Watching
Strong detection combines four signal families, then tests whether they agree. IP intelligence adds network context, but it rarely proves who operated a session. Datacenter hosting, proxy, VPN, or Tor indicators can raise suspicion, as can rapid account creation from one address, geolocation drift, shared egress, or concentration in one autonomous system. A residential connection reduces some infrastructure concerns without making the activity legitimate.
Device intelligence provides continuity across sessions. Stable fingerprints, canvas and hardware characteristics, emulator indicators, rooted or jailbroken states, and multiple device identities cycling through one network can indicate farming or spoofing. Treat fingerprints as probabilistic evidence. Privacy tools, shared workspaces, mobile resets, and browser changes can also produce legitimate variation, so device reuse should usually increase review priority rather than trigger an automatic decline.
Phone and SMS data require the same caution. Carrier and line type, number reputation, reuse across profiles, OTP request timing, and silent retry behavior can separate ordinary verification from organized attempts. AUSTRAC identifies shared mobile numbers, email addresses, and IP addresses across customer profiles, false or unverifiable identity data, and test payments as suspicious banking-sector patterns in its banking-sector suspicious activity indicators.
Behavioral signals can expose coordination that static attributes miss. Review session duration, typing cadence, navigation paths, time to submit, funnel velocity, and the order of profile changes. Account-takeover guidance highlights unfamiliar geographies, proxy or VPN or Tor exit nodes, rapid multi-account attempts, and immediate changes to phone, password, or payment settings after login as important signals in account takeover fraud detection.
For teams monitoring on-chain communities or token-related activity, relationship analysis matters too. A resource such as find risky Solana tokens can help practitioners examine surrounding risk context instead of relying on isolated events. Disposable virtual numbers make phone reputation less decisive, especially in multi-account campaigns, so detection should combine number reuse with device, network, behavior, and entity relationships. The overlap between independent signal families is what moves a case from unusual to actionable.
Detection Techniques From Rules to Behavioral Models
Rules remain useful because they're fast, interpretable, and easy to deploy. A rule can stop an obvious automation pattern or route a high-risk event to review without waiting for a model release. The problem starts when teams treat a growing rule library as a complete detection strategy. Attackers learn fixed thresholds, distribute activity across accounts, and change one attribute while preserving the underlying coordination.
Heuristic scoring handles the gray zone. Instead of blocking because one condition fired, it assigns weight to several interpretable features, such as shared identifiers, network concentration, device reuse, or unusual verification velocity. That gives risk teams a way to calibrate friction by confidence and explain decisions to analysts.
Machine learning and behavioral analytics are most useful when relationships span sessions and entities. Supervised models learn from labeled outcomes. Unsupervised methods can surface clusters and anomalies that weren't encoded in advance. Graph-based analysis can connect accounts, devices, numbers, IPs, referrals, and payouts, exposing a campaign where each individual account looks ordinary.
A mid-stage platform shouldn't begin with an elaborate model. Start with rules for the obvious abuse, use heuristics for uncertain traffic, and reserve ML or graph analysis for cross-session correlation. The right question isn't whether one method is superior. It's which method catches this adversary at an acceptable customer cost.
Payment and verification teams also need to connect detection with loss operations. Tools and workflows that help lower chargebacks belong downstream of the same decision framework, because a signal that looks modest at registration may become important once it connects to disputed payments or payout abuse.
Implementation Path From Features to Feedback Loops
A detection engineer starts with events, not a model. Pull registration, login, OTP, profile, payment, payout, and account-status events from the verification pipeline. Give each event a reliable timestamp and connect it to entities such as account, device, phone, IP, referral source, and payment method.
Build features that describe relationships
Useful features turn raw activity into comparable windows and lookups:
- Reuse: Count how many profiles share a phone, email, device, network, or payout destination.
- Velocity: Measure registrations, OTP requests, retries, logins, and profile changes over relevant time windows.
- Concentration: Identify whether activity clusters around one ASN, referral source, device family, or number range.
- Entropy: Track whether one device uses many numbers, whether many devices use one network, and whether identifiers vary in a way that looks deliberately distributed.
- Sequence: Record what happens immediately after verification, including profile edits, funding, promotion use, or withdrawal attempts.
Don't collapse every feature into one flat cutoff. Define separate action bands. High-confidence automation may justify an automatic decline. Conflicting signals may call for step-up verification. A borderline cluster belongs in an analyst queue with the evidence attached.
A useful operating loop looks like this: collect events, engineer features, score activity, route decisions, then label outcomes. If a heuristic flags a burst of sign-ups sharing one ASN and disposable number ranges, the analyst's decision shouldn't disappear into a case-management system. Feed that label back into the rule weight, the feature store, and any supervised model that uses the same pattern.
The loop needs short review cycles. Manual overrides, appeals, chargebacks, confirmed abuse, and successful verifications should change thresholds and routing while the evidence is still relevant. Before exposing users to a new block, run the logic in shadow mode, compare its alerts with outcomes, and release it gradually.
Use the following walkthrough as a practical complement to the implementation process:
Metrics That Beat Model Accuracy
A model can look excellent in a notebook and fail in production. A high ranking metric doesn't tell you whether analysts can review the queue, whether legitimate users can finish verification, or whether the system prevents meaningful loss.
The old benchmark mindset also misses the operational constraint. FinCEN's historical review of U.S. bank compliance performance found that large banks reviewed about 16 million alerts and filed more than 640,000 SARs in 2017, while law enforcement followed up on a median of only 4% of those SARs; the study estimated that 90% to 95% of reported individuals were likely innocent, as described in FinCEN's year review. The lesson isn't that detection is pointless. Broad coverage without prioritization overwhelms the people responsible for turning alerts into decisions.
Measure the queue, not just the classifier
Track operational outcomes at the action threshold:
- Alerts per analyst: A queue that grows faster than review capacity will age, regardless of model quality.
- False-positive ratio: Break it down by rule, model version, geography, product, and user segment.
- Time to decision: Delayed review can turn a suspicious account into a completed payout or irreversible transfer.
- Prevented loss per false positive: This forces the team to price customer friction against the value of intervention.
- Legitimate challenge rate: Measure how often good users encounter step-up verification or a hold.
- Appeal outcomes: Successful appeals expose where the system is overconfident.
Set a loss budget first, then translate it into an alert budget that analysts can handle. From there, choose a precision floor for each action. Automatic declines need stronger evidence than review alerts, while a low-friction challenge can tolerate more uncertainty if recovery is quick and clear.
This is also an engineering and governance problem. Teams responsible for secure software delivery with DevArmor should treat detection changes as production changes, with versioning, access controls, testing, and auditability. For a practical risk-assessment lens, see this fraud risk assessment guide, then connect the findings to analyst capacity and customer experience rather than leaving them as a standalone scorecard.
Why Virtual Numbers Change the Game
A phone number is a risk signal, not proof of identity. Virtual and disposable number services can let one operator receive verification codes across multiple accounts, rotate identifiers, and distribute activity so that no single profile looks extreme. That weakens assumptions based on number age, country prefix, successful SMS delivery, or apparent possession of a handset.
The mistake is to block every virtual number. Some legitimate users choose one to protect privacy, avoid spam, manage testing environments, or operate across countries. A virtual number may raise a question, but it shouldn't answer the question by itself. The useful distinction is between an isolated privacy choice and a coordinated relationship pattern.
Detect the network around the number
Link phone activity to the rest of the identity graph:
- Repeated use of one number across unrelated profiles is a high-signal relationship.
- Recycled number patterns combined with shared devices or IPs deserve more weight than either feature alone.
- Synchronized account creation, repeated OTP retries, and consistent gaps between registration and verification can reveal orchestration.
- Referral codes, campaign identifiers, payout destinations, and post-verification actions can expose the operator's objective.
AUSTRAC's guidance specifically includes repeated shared identifiers as suspicious patterns, which supports treating phone reuse as contextual evidence rather than a standalone verdict. The same principle applies to number reputation. A number's carrier or line type can inform scoring, but behavior and relationships should determine the action.
Low-and-slow operators may remain below simple daily limits by spreading activity across accounts, devices, networks, and sessions. Use longer observation windows and graph relationships to detect distributed coordination. Monitor re-verification attempts, carrier changes, and ownership churn, while allowing a credible user to recover through proportionate review.
For teams that need a clear primer before tuning these controls, this explanation of what a virtual number is provides useful terminology. The detection objective remains the same: identify organized evasion without turning privacy-preserving behavior into automatic guilt.
Practical Best Practices You Can Ship Monday
Start by naming the abuse cases, not by selecting a model. Write down how multi-account campaigns, SMS pumping, disposable-number use, device farming, payout manipulation, and low-and-slow evasion would appear in your product. If the team can't describe the event sequence, it can't build a useful feature or explain a decision to an analyst.
Build an interpretable score from a compact feature set:
- Account and device age: New entities deserve context, not automatic rejection.
- Identifier reuse: Connect numbers, emails, devices, IPs, payment methods, and payouts.
- Network concentration: Look for clusters around shared egress, ASN, proxy, VPN, or Tor infrastructure.
- Verification velocity: Include request timing, retries, completion order, and synchronization.
- Behavioral consistency: Compare navigation, typing, session length, and time to submit.
- Account relationships: Deduplicate linked cases so analysts see the campaign rather than isolated alerts.
Tune actions by confidence
Use hard blocks for high-confidence automation or known abuse infrastructure. Apply step-up verification when signals conflict, and send borderline traffic to a review queue. A user with a virtual number and a stable account history should not receive the same treatment as a new cluster showing shared devices, synchronized OTP requests, and rapid payout activity.
Operational quality determines whether the system survives contact with growth. Prioritize alerts by estimated loss, deduplicate related cases, cap queue volume, and show analysts the evidence behind each score with recommended next steps. Track confirmed abuse rate, false positives by signal and segment, review time, automation coverage, appeal outcomes, and cost per prevented incident. Overall accuracy alone won't tell you whether the program is working.
Close the loop safely
Label outcomes from declines, investigations, chargebacks, successful appeals, and manual overrides. Test new rules in shadow mode, roll them out gradually, monitor drift, and version every material change. Review retention limits and access controls for IP, device, phone, and behavioral data, documenting why each signal is collected and how long it remains useful.
The best teams treat privacy review and abuse review as one operating discipline. That keeps legitimate users, including people who use virtual numbers for valid reasons, inside the product while making coordinated abuse expensive and visible. These principles align with broader fraud prevention strategies, but the implementation should always reflect your own funnel, loss profile, and review capacity.
SMS Activate provides disposable and long-term virtual numbers for receiving verification codes across supported services, helping privacy-conscious users and legitimate teams avoid exposing personal phone numbers during account verification. Visit SMS Activate to review available countries, service coverage, and pay-per-use verification options for your testing or multi-account workflows.