Crypto Casino
Torrent Gear
Antifraude y antibot en gamificación basada en ML
1) Por qué un sistema antifraude separado para la gamificación
La gamificación estimula la actividad (misiones, fichas, cosméticos), lo que significa que provoca:- bots (scripts de ejecución de misiones, pharm tokens/ratings);
- multiaccounts/collousies (giro del equipo, «cambio» de premios);
- emuladores/dispositivos de ruta (manipulación del cliente);
- explota misiones (ciclos donde el progreso va sin juego real).
Objetivos antifraude: mantener la honestidad, no sobrecalentar UX, cumplir con la privacidad/regulación y mantener la economía promocional sostenible.
2) Señales y fichas (qué contar)
Dispositivo y entorno
Certificación de la integridad del cliente (mobile/web), características del emulador/root, perfil WebGL/Canvas no estándar.
Device fingerprint (sin PII): combinaciones de User-Agent, fuentes, gráficos, tiempo de renderizado.
Biometría conductual
Ritmo de clics/toques, suavidad de las curvas, micropausalidad, variabilidad de las trayectorias.
Ruidos «humanos»: temblor del cursor, microdraif del scroll, distribución de intervalos (lognormalidad).
Patrones de juego y misión
Ciclos repetitivos de longitud «perfecta», ritmo anormalmente estable (giros/min).
Ventanas de actividad estrechas (por ejemplo, exactamente cada 10 min), terminaciones instantáneas de misiones de varios pasos.
Señales gráficas y de red
Coincidencias IP/AS, fuentes de pago compartidas (en agregados), clústeres de amistad/invitación.
Participación conjunta en torneos con «sub-apuestas» (extrañas correlaciones de resultados).
Economía/promoción
Monetización desproporcionada en misiones con tokens, conclusiones abruptas después del pharma.
RG/contexto
Sesiones súper largas sin micropausas (bot-rasgo), «transportadores» nocturnos.
3) Pila modelo (como atrapar)
1. Detectores de anomalías (unsupervised):- Isolation Forest, One-Class SVM, Autoencoder para el comportamiento y los dispositivos.
- Uso: el «scoring de sospecha» temprano sin etiqueta es «culpable».
- Detección comunitaria (Louvain/Leiden) + signos de centralidad (betweenness, degree).
- GNN (GraphSAGE/GAT) para clasificar nodos/aristas (colusiones, granjas de cuentas).
- Gradient Boosting/Tabular Transformers por etiquetas de investigaciones pasadas.
- Las probabilidades calibradas → confianza en la toma de decisiones.
- User2Vec sobre las secuencias de acontecimientos; distancias → «bot clusters».
- Selección de la barrera mínima (cheque fácil vs verificación rígida) en el contexto de riesgo de × UX.
4) Orquestación de reglas (motor de la política)
Idea: ML da risk_score, la política decide «qué hacer» teniendo en cuenta la economía y UX.
Niveles de ejemplo:- R0 (verde): sin restricciones; supervisión pasiva.
- R1 (amarillo): suaves «humanity-challenge» (micro-ayuda), se reduce la tapa de las misiones.
- R2 (naranja): cheque de dispositivo, control de ritmo adicional, reducción de emisión de tokens.
- R3 (rojo): bloque de progreso sobre misiones en disputa, moderación manual/congelación temporal de premios.
- R4 (negro): ban/CUS-rugido (si es permitido regulativamente y justificado).
Controladores de transición: riesgo agregado, banderas gráficas de colusiones, quejas, señal de los proveedores.
5) Barreras honestas sin demasiada fricción
Cheques invisibles: biometría conductual de fondo, certificación del entorno.
Humanity-action en lugar de capchi: mini-gesto (drag-pattern aleatorio, deslizador improvisado), time-window con micropausas.
WebAuthn/Passkeys para actividades «costosas»: asegurar el dispositivo/identidad sin contraseña.
Barreras reactivas: solo se encienden en el momento de las anomalías, no a todos.
6) Anti-patrones de misión (cómo evitar «farmacia»)
Variabilidad de los requisitos: una serie de acciones en diferentes proveedores/tiempos/apuestas.
Couldowns y cambio de contenido: prohibición de ciclos del mismo tipo seguidos.
Eventos de control aleatorios: pequeñas verificaciones «humanas» en medio de una larga misión.
Limitar los avances paralelos: para que las granjas no cierren decenas de misiones al mismo tiempo.
7) Cumplimiento, privacidad, transparencia
Minimización de datos: sólo los ficheros necesarios, almacenamiento de agregados anónimos.
Explainability: reason-codes para acciones controvertidas (por ejemplo, «velocidad anormal + grafo-clúster»).
Proceso appeal: forma comprensible de apelación; revisión rápida.
Políticas de RG: con signos de fatiga, reducimos la carga en lugar de «empujar» al jugador.
8) Métricas de éxito y guardianes de la economía
Bot/Collusion catch rate (la proporción de premios clave identificados antes de recibir).
False Positive Rate (umbral Lag to Action (tiempo desde la anomalía hasta la medida). Emission to GGR y Prize ROI: la defensa se paga a sí misma. Complaint/Appeal rate и Appeal overturn rate. Impacto en UX: conversión de misiones, mute/opt-out desde la personalización, NPS por honestidad. 9) A/B y validación offline 1. Misiones anti-consumo: variabilidad vs básica. 2. Humanity check: el gesto invisible vs capcha clásica. 3. Umbral de risk_score: suave/rígido (diferentes TPR/FPR). 4. Grafos de filtro: con/sin GNN, sólo reglas de gráfico. 5. Orquestador de barreras: bandido contextual vs estático. 10) Pseudocódigo (puntuación → política → acción) 11) Plantillas JSON (reglas y registro) 12) Proceso de respuesta y redtiming Monitoreo en tiempo real: dashboards por ráfagas de riesgo, grafos componentes. 1. detecto de la anomalía → 2) reducción de la emisión/congelación de premios controvertidos → 3) muestreo de registros/grafos → 4) parche de reglas/modelos → 5) recuento retro de premios honestos. Red Team/laboratorio clandestino: simulación de bots (ofuscación, aleatorización), ataques a modelos (ejemplos adversarios). Lanzamientos canarios: lanzamos nuevas barreras al 5-10% del tráfico. 13) UX y comunicaciones Tono neutral y respetuoso: «Se han notado acciones no estándar: confirme que es una persona (30 segundos)». Opciones: «repetir más tarde», «contactar con el soporte», «apelar». Accesibilidad: alternativas para personas con limitaciones motrices/visuales. Transparencia: página «Cómo defendemos la honestidad» con principios generales (sin recetas para abusar). 14) Arquitectura técnica (en resumen) Recopilación de eventos: Kafka/Redpanda, esquemas 'mission _ progress',' input _ stream ',' device _ attest '. Fichestor: en línea (ms-latencia) + fuera de línea (batch 1-6 h). Servicios ML: 'risk-scorer', 'graph-service', 'policy-engine'. Almacén de evidencia: registros inmutables (WORM), cifrado en reposo y en canal. Seguridad: sillas de seguridad RNG en el servidor; cliente - sólo visualización. 15) Lista de verificación antes del lanzamiento Antifraude/antibot en gamificación es una capa de gráficos ML++ barreras honestas que se activan exactamente donde se necesita. La biometría conductual y la anomalía-bebé dan una señal temprana, la gráfica analítica abre las colusiones, el orquestador selecciona una verificación mínimamente suficiente. Con transparencia, privacidad y respeto a UX, el sistema mantiene la honestidad de la competencia, protege la economía de los premios y no convierte el producto en una «franja de obstáculos» para los jugadores de buena fe.
python def score_request(user, event):
x = build_features (usuario, evento) # dispositivo, comportamiento, signos gráficos r_unsup = oc_svm. score (x) # anomalía r_sup = gbdt. predict_proba (x) [:, 1] # probabilidad de frod r_graph = gnn_node_prob (usuario. node_id) # riesgo gráfico risk = calibrate (r_unsup, r_sup, r_graph) # calibración isotrópica return risk
def decide_action(risk, context):
contexto: importancia de la acción, valor de la recompensa, factor UX 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 de misiones if risk <0. 85: return "HOLD_REWARDS" # congelar a rugir return' BAN_OR_REVIEW "
def enforce(action, user):
la barrera mínima necesaria if action = = "SOFT_CHECK": trigger_humanity_challenge (usuario)
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)
Registro de la decisión (para auditoría/apelación):
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}
}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"
}