Online platform abuse: fake accounts, bots, promo abuse

Every online service with a sign-up form, a login or a discount code attracts abuse: mass-registered fake accounts, credential-stuffing bots, scalper and scraper bots, and people who farm welcome bonuses, referral credits or free trials with dozens of identities. Modern defence layers bot detection at the edge, device and behaviour signals, graph analysis of linked accounts and a risk score that triggers step-up checks instead of blanket blocking. Operators typically see lower abuse cost, cleaner marketing metrics and fewer support and fraud losses, with minimal friction for genuine customers.

Problem & value

• Who has it: web shops, marketplaces, SaaS with free tiers, fintech/neobank apps, gaming and social platforms, ticketing, and public-sector portals (e.g. fake registrations for citizen services). SMBs feel it as spam registrations, scraped catalogues, card-testing and coupon leakage; enterprises as account takeover, referral rings and inflated acquisition cost.
• Today: static rules (IP blocklists, rate limits, "one coupon per email"), CAPTCHAs and manual review. Attackers evade these with residential proxies, disposable emails, anti-detect browsers and, increasingly, LLM-driven agents that fill forms like humans.
• AI value: supervised models for known abuse patterns, unsupervised anomaly detection for new campaigns, graph models to link accounts via shared devices/payment/addresses, and LLMs for classifying free text (usernames, bios, messages) and drafting case notes.
• Scale of the problem (vendor-reported): Imperva's 2025 Bad Bot Report states automated traffic reached 51 % of all web traffic and bad bots 37 % [1]. This is a vendor measurement on its own customer base, so treat it as indicative, not as an industry-wide census.

Variants

• Fake-account / sign-up fraud: bulk registration for spam, review manipulation (see ANOM-010), bonus farming or later fraud.
• Account takeover and credential stuffing: login-side bot defence (closely related to SEC-005 for internal users).
• Promo / coupon / referral / free-trial abuse ("incentive abuse"): multi-accounting, self-referral rings, return-and-reuse of vouchers (retail returns: ANOM-033).
• Scalping, scraping and inventory-hoarding bots: ticketing, sneaker drops, price scraping.
• Community/social platforms: inauthentic-behaviour networks, spam bots; trust-and-safety workflows. VLMs and text classifiers help with profile pictures and messages.
• Gaming: bot farms and cheat-account rings (see ANOM-036).
• Public sector / SMB lite: contact-form and registration spam protection with privacy-friendly proof-of-work CAPTCHAs.
• AI-agent traffic: distinguishing legitimate, declared AI agents (shopping or research agents) from abusive ones — a new 2025/26 policy question rather than a pure detection task.

How it works

1. client / edge telemetry (HTTP, TLS fingerprint, JS challenge, device signals, IP/ASN reputation)
2. bot-management layer (verified-bot allowlist, proof-of-work / managed challenge)
3. event stream (sign-up, login, checkout, redeem) + feature store (velocity, entropy of email/username, device reuse)
4. scoring: rules + gradient-boosted trees + anomaly detectors + text classifier
5. entity graph (device, IP, email, phone, card, address, referral code)
6. community detection / GNN ring scoring
7. decision engine: allow | step-up (e-mail/SMS/MFA/ID check) | throttle | shadow-ban | block
8. manual review queue (LLM-prepared case summary, reason codes)
9. feedback labels (chargebacks, confirmed abuse, appeals)
10. retraining & rule tuning

• Bot layer: managed challenges and non-interactive proof-of-work checks replace image puzzles; verified crawlers and signed agents are allowlisted (e.g. via Web Bot Auth, an IETF-draft-based scheme using HTTP message signatures [3]).
• Scoring: gradient boosting (XGBoost/LightGBM) on velocity and device features is still the workhorse; isolation-forest/autoencoder-style detectors (e.g. the 61 detectors in PyOD [4]) catch novel campaigns where labels are scarce.
• Graph layer: link accounts through shared identifiers; label propagation and GNN models (e.g. those collected in DGFraud [5]) rank rings for batch review.
• LLMs: classify usernames, bios and review text; summarise an account's evidence for analysts; draft appeal replies. They are not the primary detector — latency and cost are wrong for per-request decisions.
• Human-in-the-loop: borderline scores go to review; permanent bans or denial of a service the user paid for need documented reasons and an appeal route.

Data preparation

Data needed: sign-up and login events, IP and device signals, e-mail and phone attributes, voucher or promo redemptions, orders and refunds, and outcomes of earlier blocks or complaints as labels. They live in the shop or app backend, web server logs, the CRM and the PSP. Typical gaps: logs are short-lived or not centralised, accounts and devices are not linked, abusers are never tagged, and consent for device fingerprinting is missing.

Preparation steps: centralise event logs (PREP-005), link accounts through stable identifiers, harvest labels from banned accounts and refunded promos (PREP-020), define abuse categories (PREP-019), and pseudonymise IPs and identifiers for analysis (PREP-022). Check the legal basis for device and behaviour data (PREP-025). For Path A mostly a clean event feed and a way to report false positives are needed. See DATA-003.

Rough share of effort: 20-30 percent on Path A, 40 percent on Paths B and C.

Implementation paths

Which path for whom

• SMB: Path A, because bot management, CAPTCHA and risk-signal services from mature (partly EU-hosted) vendors cover the standard process at low cost.
• Enterprise: Path B, because large platforms have unique abuse patterns and own behavioural data, so vendor signals are combined with in-house scoring and rules.
• Developer: Path C, because open-source rules, graph and anomaly tooling on HW1 gives full control over features and thresholds.
• Public: Path C, because public portals need sovereign hosting and procurement-compatible components for protecting citizen accounts.

Path A — Buy (recommended for most SMBs and mid-market)

• Privacy-friendly CAPTCHA / proof-of-work: Friendly Captcha (German, EU data-centre option, no cookies, vendor-stated) [6]; ALTCHA (open source, self-hostable, cookie-free) [7]; Cloudflare Turnstile (non-interactive challenges, usable without proxying traffic through Cloudflare) [2]; hCaptcha (enterprise bot detection, Account Defense, "zero-PII" claim, vendor-stated) [8].
• Bot management / WAF: Cloudflare Bot Management, Akamai, Imperva (Thales), HUMAN Security, DataDome (French), Arkose Labs, Kasada, Netacea (UK).
• Fraud/abuse platforms: Sift, Forter, Riskified, Feedzai, Sardine, DataVisor, Fraugster-style EU specialists, plus SEON (Hungary/EU) for lightweight email/phone/IP enrichment and scoring. Payment providers (Stripe Radar, Adyen RevenueProtect) cover checkout abuse.
• Choose A when: no in-house data-science team, abuse is a cost not a core risk, and a vendor DPA with EU processing is available. Verify claims with a pilot on your own traffic; vendor "attack volume reduction" numbers are marketing figures.

Path B — Build on cloud APIs

• Signals as APIs: email/phone/IP reputation (e.g. SEON, Twilio Lookup, MaxMind), managed challenges (Turnstile, hCaptcha), cloud ML (Amazon Fraud Detector successors, Google reCAPTCHA Enterprise, Azure services with EU regions).
• Scoring: train gradient-boosted models on your own event logs in a managed ML service (Vertex AI, SageMaker, Azure ML — EU regions); LLM calls (Claude, Mistral, Gemini, GPT via EU endpoints) for text classification and analyst summaries.
• Orchestration: stream events through Kafka/Kinesis/Pub/Sub, decide in a rules engine, push cases to n8n/Power Automate/ticketing.
• Choose B when: you have engineers and unique abuse patterns but no on-prem constraint.

Path C — Self-host (open source)

• Bot defence: CrowdSec (MIT-licensed IDS/IPS/WAF with proof-of-work bot challenge and community blocklists [9]), ModSecurity/Coraza with OWASP Core Rule Set, ALTCHA, Anubis-style proof-of-work gateways, Nginx/HAProxy rate limiting.
• ML: XGBoost/LightGBM, scikit-learn, PyOD [4], PyG/DGL for graphs, Neo4j or Memgraph for entity graphs, Redis/Feast for features, Flink or Kafka Streams for streaming.
• LLM (optional): a small open-weight model (e.g. Qwen3 or Mistral/Ministral class, ≤ 8B) for text classification; embeddings for near-duplicate profile text.
• Hardware: HW1 (CPU servers) suffices for most workloads; add HW2 only for GNN training or local LLMs.
• Choose C when: data must stay on-prem (public sector, banks), or per-request SaaS pricing at very high traffic is prohibitive.

Path D — Custom training

Worthwhile for large platforms with distinctive abuse: train sequence models on click/typing telemetry, GNNs on the account graph, or fine-tune a small encoder on your labelled spam text. Needs thousands of confirmed-abuse labels (hard because labels are delayed and biased by past rules), time-based validation, and an adversarial-drift process (retrain/recalibrate weekly to monthly). Most SMBs should not start here.

State of the art (2026)

• From CAPTCHA to invisible risk signals: challenge-free, proof-of-work and behaviour/telemetry-based checks are standard; image puzzles are largely a fallback because AI solvers defeat them.
• Agent traffic is the new frontier: LLM-driven browser agents run in real browser engines and look human at network level; network-layer-only tools miss them [vendor buyer guidance, e.g. 10]. Cryptographic bot identification (Web Bot Auth drafts) lets sites verify declared agents but is still work in progress [3].
• Graph-first detection finds rings that per-account scoring misses; promo-abuse economics improves most by linking accounts, not by tightening single-account rules.
• Combining supervised and unsupervised methods with fast feedback loops remains better than any single model; public fraud datasets (e.g. IEEE-CIS) are for payments, so there is no standard open benchmark for sign-up abuse — be sceptical of vendor accuracy claims.
• Limits and failure modes: false positives hit privacy-conscious users (VPN, Tor, hardened browsers), shared IPs (CGNAT, universities) and accessibility tools; adversaries adapt within days; labels are delayed; behavioural biometrics raise GDPR and bias questions; over-blocking of declared AI agents may cost legitimate sales.

Shared resources & combinations

• Shared building blocks: tabular-ml + anomaly-detection + streaming + graph-ml are the same stack as payment fraud (ANOM-001), retail returns/POS fraud (ANOM-033), ad fraud (ANOM-027) and UEBA (SEC-005). One feature store and event stream on HW1 can serve all.
• Combine with: ANOM-014 (document/liveness check as step-up for suspicious sign-ups), ANOM-010 (fake reviews from the same rings), ANOM-036 (game cheat accounts), SEC-021 (fake shops/profiles outside your platform), SEC-010 (guardrails if you expose LLM agents or chatbots to bots), ANOM-025 (consumer scam protection; scammers often start with fake accounts).
• LLM components (text classification, case summaries) share small-model serving with ticket triage and moderation use cases.

Effort, cost & KPIs

• Path A: days to weeks; subscription or per-request pricing; CAPTCHA-class tools are low-cost or free for small volumes.
• Path B: 2–4 months for a production pipeline with feedback loop; cloud ML and enrichment-API fees scale with traffic.
• Path C: 3–6 months; engineering plus operations; cheap per request at scale.
• Path D: quarters; dedicated data-science team.
• KPIs: fake-account rate at 7/30 days, bot share of traffic, abuse cost per 1,000 sign-ups, promo cost leakage, false-positive rate and genuine-user challenge rate, step-up completion rate, conversion impact (A/B holdout), time-to-detect a new campaign, manual-review hit rate, appeal overturn rate.

People & change

Involve management (risk appetite vs. conversion), the department lead (growth, marketing, support) as process owner, IT and IT security for integration, and the DPO for fingerprinting and tracking rules (consent under TTDSG and GDPR). Support teams need a clear unblock path for wrongly flagged customers.

Works council: no in the normal case, because the system analyses customers and sign-ups, not employee behaviour; it becomes relevant (§87(1) no. 6 BetrVG) if analyst dashboards measure the performance of support staff, and §90(1) no. 3 still calls for timely information on AI-supported processes where staff workflows change.

Data protection: profiling of users at scale and device fingerprinting make a DPIA likely (Art. 35 GDPR); AVV with vendors. AI literacy: support the abuse and support teams with short training on scores and false-positive handling (Art. 4 AI Act). Pilot: run in monitor-only mode for a few weeks, review a sample with support staff, then enforce soft measures (extra verification) before hard blocks. Typical concern: "real customers get locked out"; address with step-up checks instead of bans, appeal channel and false-positive KPI. See GUIDE-005, GUIDE-009 and GUIDE-011.

Risks, regulation & compliance

• EU AI Act: typically minimal risk. Annex III (e.g. creditworthiness) explicitly excludes systems for detecting financial fraud from the credit-scoring category [11], and bot or abuse scoring is not itself listed. Check for edge cases: biometric categorisation or emotion inference on behaviour would move into regulated or prohibited territory (Art. 5) and should not be used; remote biometric identification is out of scope here (see ANOM-014 for one-to-one verification). Where a platform denies access to essential services (benefits, insurance) via the score, the system may become high-risk.
• GDPR: IP addresses, device IDs, behavioural data and account graphs are personal data. Legitimate interest (Art. 6(1)(f), Recital 47 on fraud prevention) is the usual basis but needs a documented balancing test; minimise retention and document purposes. If a score alone leads to a significant adverse effect, Art. 22 and the CJEU SCHUFA ruling (C-634/21) on automated scoring make human review and explanation necessary. Perform a DPIA for large-scale profiling.
• ePrivacy (Art. 5(3)): reading information from the user's device (fingerprinting, telemetry scripts) generally needs consent unless strictly necessary; EDPB Guidelines 2/2023 clarify the broad technical scope [12]. Prefer server-side signals and proof-of-work approaches that avoid storing/reading device data.
• DSA (EU) for platforms: online platforms must take measures against misuse and offer notice-and-action and statement-of-reasons processes for account restrictions; keep reasons and appeals documented.
• Sector rules: banks and payment firms (PSD2/PSD3 fraud monitoring, DORA ICT governance, AML onboarding); consumer-law fairness for promo terms.
• Mitigations: graduated responses (challenge before ban), reason codes, audit logs, bias checks by geography/ASN/device, holdout evaluation, vendor DPAs and EU processing, avoid cross-site tracking.

Getting started

1. Quantify the problem: fake-account rate, cost per promo redemption, bot share of traffic, share of support tickets caused by abuse.
2. Put a low-friction bot layer in front of sign-up, login and checkout (Turnstile, Friendly Captcha or ALTCHA) and add rate limits and disposable-email checks.
3. Log all events with stable IDs and outcomes; start a labelled abuse table (confirmed ring, chargeback, manual ban).
4. Add a gradient-boosted risk score plus a simple entity graph (device/payment/address links) and run it in shadow mode against rules.
5. Introduce graduated actions and a review queue with an appeal path; write the DPIA/legitimate-interest assessment before enforcement.

Sources

1. Imperva — 2025 Bad Bot Report — https://www.imperva.com/resources/resource-library/reports/2025-bad-bot-report/
2. Cloudflare — Turnstile documentation — https://developers.cloudflare.com/turnstile/
3. Cloudflare — Web Bot Auth documentation — https://developers.cloudflare.com/bots/concepts/bot/verified-bots/web-bot-auth/
4. PyOD — anomaly detection library documentation — https://pyod.readthedocs.io/en/latest/
5. safe-graph — DGFraud, graph-based fraud detection toolbox — https://github.com/safe-graph/DGFraud
6. Friendly Captcha — product and privacy information — https://friendlycaptcha.com/
7. ALTCHA — open-source proof-of-work CAPTCHA alternative — https://github.com/altcha-org/altcha
8. hCaptcha Enterprise — https://www.hcaptcha.com/
9. CrowdSec — open-source IDS/IPS, WAF and bot detection — https://github.com/crowdsecurity/crowdsec
10. Arkose Labs — bot and fraud prevention vendor — https://www.arkoselabs.com/
11. EU AI Act — Annex III, high-risk systems — https://artificialintelligenceact.eu/annex/3/
12. EDPB — Guidelines 2/2023 on the technical scope of Art. 5(3) ePrivacy Directive — https://www.edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-22023-technical-scope-art-53-eprivacy-directive_en