Anti-fraud and anti-bots in ML-based gamification

1) Why a separate anti-fraud system for gamification

Gamification stimulates activity (missions, tokens, cosmetics), which means it provokes:

bots (mission scripts, farm tokens/ratings);
multi-accounts/collusions (team cheating, "throwing" awards);
emulators/root devices (client manipulation);
mission exploit (cycles where progress goes without a real game).

The goals of anti-fraud are to maintain honesty, not overheat UX, maintain privacy/regulation and keep the promo economy sustainable.

2) Signals and features (what to count)

Device and environment

Client integrity certification (mobile/web), emulator/root features, non-standard WebGL/Canvas profile.

Device fingerprint (without PII): combinations of User-Agent, fonts, graphics, rendering time.

Behavioral biometrics

Rate of clicks/leaks, smoothness of curves, micropause, variability of trajectories.

"Human" noises: cursor shake, scrolling microdraf, interval distribution (lognormality).

Game and mission patterns

Repeated cycles of "perfect" length, abnormally stable rates (spin/min).

Narrow windows of activity (for example, exactly every 10 minutes), instant completion of multi-step quests.

Graph signals and network

IP/AS matches, common payment sources (in aggregates), friendship/invitation clusters.

Joint participation in tournaments with "playing along" (strange correlations of results).

Economics/Promo

Disproportionate monetization on missions with tokens, harsh conclusions after pharma.

RG/Context

Extra-long sessions without micro-pauses (bot-sign), night "conveyors."

💡 All features are aggregated and anonymized. PII - only in the scope of regulator requirements.

3) Model stack (how to catch)

1. Anomaly-detectors (unsupervised):

Isolation Forest, One-Class SVM, Autoencoder for behavioral and devices.
Usage: Early "scoring suspicion" without the label "guilty."

2. Graph Analytics and GNN:

Community detection (Louvain/Leiden) + signs of centrality (betweeness, degree).
GNN (GraphSAGE/GAT) for node/edge classification (collusion, account farms).

3. Supervised:

Gradient Boosting/Tabular Transformers on the tags of past investigations.
Calibrated probabilities → confidence in decision-making.

4. Behavioral embeddings:

User2Vec by sequence of events; distances → bot clusters.

5. Contextual bandits for protective measures:

Choosing a minimum barrier (easy check vs hard verification) for the context of risk × UX.

4) Policy engine

Idea: ML gives risk_score, policy decides "what to do" taking into account the economy and UX.

Example of levels:

R0 (green): unlimited; passive monitoring.
R1 (yellow): soft "humanity challenges" (micro-interactions), reduced mission cap.
R2 (orange): device-check, additional tempo control, token issue reduction.
R3 (red): Progress block on controversial missions, manual moderation/temporary award freeze.
R4 (black): ban/CCR review (if regulatory and justified).

Transition drivers: aggregated risk, collusion flags, complaints, signal from providers.

5) Fair barriers without unnecessary friction

Invisible checks: background behavioral biometrics, environment attestation.

Humanity-action instead of captcha: mini-gesture (random drag-pattern, impromptu slider), time-window with micropause.

WebAuthn/Passkeys for "expensive" activities: secure device/identity without password.

Reactive barriers: turn on only at the time of anomalies, not for everyone.

6) Anti-mission patterns (how to prevent "farm")

Variability of requirements: a series of actions in different providers/times/rates.

Cooldowns and content changes: banning the same type of cycles in a row.

Random control events: small "human" checks in the middle of a long mission.

Limiting parallel progress: so that farms do not close dozens of missions at the same time.

7) Compliance, privacy, transparency

Data minimization: only necessary features, storage of anonymous aggregates.

Explainability: reason-codes for controversial actions (for example, "abnormal speed + graph-cluster").

Appeal process: an understandable form of appeal; rapid revision.

RG policies: with signs of fatigue, we reduce the load, and not "push" the player.

8) Success metrics and guardians of the economy

Bot/Collusion catch rate.

False Positive Rate (threshold

Lag to Action.

Emission to GGR and Prize ROI: protection pays for itself.

Complaint/Appeal rate и Appeal overturn rate.

Impact on UX: mission conversion, mute/opt-out from personalization, NPS for honesty.

9) A/B and offline validation

1. Anti-consumption missions: variability vs basic.

2. Humanity check: invisible gesture vs classic captcha.

3. risk_score threshold: soft/hard (different TPR/FPR).

4. Graph filters: with/without GNN, only graph rules.

5. Barrier orchestrator: static vs contextual bandit.

10) Pseudocode (scoring → policy → action)

python def score_request(user, event):
x = build_features (user, event) # device, behavior, graph characteristics r_unsup = oc_svm. score (x) # anomaly r_sup = gbdt. predict_proba (x) [:, 1] # fraud probability r_graph = gnn_node_prob (user. node_id) # graph risk = calibrate (r_unsup, r_sup, r_graph) # isotropic calibration return risk

def decide_action(risk, context):
context: action importance, reward value, UX factor if risk <0. 25:  return "ALLOW"
if risk < 0. 45:  return "SOFT_CHECK"  # humanity-gesture, micro-pause if risk < 0. 65:  return "DEVICE_ATTEST" # integrity + сниж. cap missions if risk <0. 85: return "HOLD_REWARDS" # freeze to review return "BAN_OR_REVIEW"

def enforce(action, user):
minimum required barrier if action = = "SOFT_CHECK": trigger_humanity_challenge (user)
elif action == "DEVICE_ATTEST": run_integrity_attestation(user. device)
elif action == "HOLD_REWARDS": freeze_rewards(user, duration="72h")
elif action == "BAN_OR_REVIEW": open_case_to_fraud_ops(user)

11) JSON templates (rules and log)

Risk Level Policy:

json
{
"policy_id": "anti_fraud_s1",  "tiers": [
{"name":"R0","risk_lt":0. 25,"action":"allow"},   {"name":"R1","risk_lt":0. 45,"action":"soft_check"},   {"name":"R2","risk_lt":0. 65,"action":"device_attest_and_cap"},   {"name":"R3","risk_lt":0. 85,"action":"hold_rewards_review"},   {"name":"R4","risk_gte":0. 85,"action":"ban_or_kyc_review"}
],  "caps": {"missions_per_day_r2": 2, "token_emission_multiplier_r2": 0. 5},  "appeal": {"enabled": true, "sla_hours": 48}
}

Decision log (for audit/appeal):

json
{
"decision_id":"dec_2025_10_24_1415",  "user_id":"u_45219",  "risk_components":{"unsup":0. 38,"sup":0. 41,"graph":0. 57},  "final_risk":0. 51,  "action":"device_attest_and_cap",  "reasons":["abnormal_click_tempo","graph_cluster_c17"],  "expires_at":"2025-10-27T14:15:00Z"
}

12) Response process and redtiming

Real-time monitoring: dashboards for risk spikes, graph components.

Incident runbook:

1. anomaly detection → 2) reduction of emission/freezing of controversial awards → 3) sampling of logs/graphs → 4) patch of rules/models → 5) retro recalculation of honest awards.

Red Team/underground laboratory: simulation of bots (obfuscation, randomization), attacks on models (adversarial examples).

Canary releases: rolling out new barriers for 5-10% of traffic.

13) UX and Communications

Neutral, respectful tone: "Non-standard actions noticed - confirm that you are human (30 sec)."

Options: "repeat later," "contact support," "appeal."

Accessibility: Alternatives for people with motor/vision limitations.

Transparency: How We Protect Integrity page with general principles (no prescriptions for abuse).

14) Technical architecture (in brief)

Collection of events: Kafka/Redpanda, schemas' mission _ progress', 'input _ stream', 'device _ attest'.

Fichestor: online (ms-latency) + offline (batches 1-6 h).

ML services: 'risk-scorer', 'graph-service', 'policy-engine'.

Evidence storage: immutable logs (WORM), encryption at rest and in the channel.

Security: RNG security seeds on the server; client - visualization only.

15) Pre-release checklist

Calibrated probabilities (Platt/Isotonic), FPR in the target corridor.
Graph signals and correlation cross-device are connected.
Barrier orchestrator configured (low risk friction minimum).
Built-in RG guards and appeals; log audit and reason-codes.
Privacy and storage policies are compliant.
Canaries, alerts and recovery runbook configured.

Antifraud/antiboot in gamification is a layer of ML + graphs + honest barriers that are included exactly where needed. Behavioral biometrics and anomaly-detection give an early signal, graph analytics reveals collusions, the orchestrator selects the minimum sufficient check. With transparency, privacy and respect for UX, the system maintains the integrity of the competition, protects the awards economy and does not turn the product into an "obstacle course" for conscientious players.