GH GambleHub

Señales de frenado y puntuación de transacciones

1) Por qué la puntuación y cómo afecta a la monetización

La puntuación antifraude determina si la transacción pasará frictionless, irá a 3DS-challenge/SCA o será rechazada/reorientada a otro método. La calibración correcta da:
  • ↑ Approval Rate sin crecimiento de charjbacks,
  • ↓ los costos de SCA/Challenges y sapport,
  • ↑ LTV a través de pagos COF/MIT sostenibles,
  • cumplimiento de PSD2-TRA (Análisis de riesgo de transferencia) en proveedores/bancos.

2) Tarjeta de señales (qué recoger)

2. 1 Identificación del dispositivo/sesión

Device fingerprint (canvas/webgl/audio, user-agent, fuentes, timezone, idiomas).
Cookie/LocalStorage/SDK-ID, identificadores sostenibles (privacy-safe).
Emuladores/root/jailbreak, proxy/VPN/datacenter-IP, TOR.

2. 2 Geo y red

IP-geo vs país BIN vs país de facturación, retardo de red/RTT, ASN/proveedor.
Frecuencia de cambio IP/geo, «saltos» de tiempo, subredes «tóxicas» conocidas.

2. 3 Atributos de pago

BIN: esquema, país, banco, débito/crédito/prepaid, comercial/personal.
MCC 7995, cantidad/moneda, frecuencia de los intentos de token/tarjeta/dispositivo/cuenta.
Historia 3DS (frictionless/challenge), normalización AVS/CVV, tokens de red (VTS/MDES/NSPK).

2. 4 Comportamiento y comportamiento biológico

Velocidad/ritmo de entrada, copipast, orden de campo, errores CVV/índice.
Patrones de "bots' (sin cabeza, clics automáticos), ciclos anómalos.

2. 5 Cuenta y gráfico de conexiones

Edad de la cuenta, completada por KYC, conjunto con dispositivos/pagos.
Grafo: dispositivos compartidos/IP/tarjetas entre cuentas, clústeres de multiacounts.
Historial de depósitos/retiros, comportamiento en el juego, devoluciones/dispouts.

2. 6 Fuentes externas

Blacklists IP/dispositivos/BIN, señales de comportamiento de servicios antifraude, regiones de riesgo/ventanas temporales.

3) Fichastor y calidad de los datos

Feature Store: definiciones únicas de fichas, versionados, TTL/ventanas temporales (1h/24h/7d/30d).
Paridad online/offline: las mismas transformaciones en realtime y formación.
Control de datos: validación schema, «not null», rangos, anti-descarga (leakage).
Etiquetado: marcar chargeback, confirmed fraud, friendly fraud, legit con fechas; aplique la «verdad diferida» (label delay).

4) Enfoques de puntuación

4. 1 Reglas (motor de políticas)

Rápido y explicable: geo mismatch + velocity → 3DS.
Contras: rigidez, muchos false positives.

4. 2 modelos ML

GBDT (XGBoost/LightGBM/CatBoost) es el estándar para los fichas de tabla; Fuerte interpretabilidad (SHAP).
Modelos de grafo (GraphSAGE/GAT): para conexiones de dispositivos/IP/tarjetas.
Redes neuronales (NatNet/MLP) - cuando hay muchas no linealidades/interacciones.
Conjuntos: GBDT + embed gráfico (node2vec) + reglas.

4. 3 Anomalías

Isolation Forest/LOF/AE para nuevos mercados/historia débil; utilizan como señales, no el veredicto final.

5) Estrategia de umbral y SCA/3DS

Score → acción (ejemplo):
  • 'score ≤ T1' → approve (en eEA: TRA-exempt en PSP/banco, si está disponible)
  • 'T1
  • 'score> T2' → decline/solicitud de alternativa (A2A/billetera)

Calibración: facture los T1/T2 según los objetivos de CBR% y AR%, teniendo en cuenta el coste del reto y el riesgo del chargeback. En las zonas de PSD2, utilice el TRA de los socios, donde está el Freed Rait del proveedor

6) Arquitectura de toma de decisiones en línea

1. Paso pre-auth: recolección de device/geo/velocity → puntuación por ≤ de 50-150 ms.
2. Solución: approve/3DS/decline/routing alternativo (PSP-B, otro método).
3. Integración 3DS: si soft-decline → repetición con SCA sin volver a introducir la tarjeta.
4. Lógica: guardamos 'score', top fiches (SHAP top-k), la acción tomada y el resultado de la autorización.
5. Feedback loop: charjbecs/dispouts → etiquetas en fichastor.

7) Fichas específicas (cheat-sheet)

Velocity (detrás de las ventanas T = 15m/1h/24h/7d):
  • intentos por dispositivo/IP/token/account/email tarjetas únicas/BIN/emisores por dispositivo cuota de falla '05/ 14/54/51/91/96'
Geo/Net:
  • IP_country ≠ BIN_country; distance(user_profile_geo, IP_geo)
  • Categoría ASN (amb/residente/datacenter), proxy/flag docenters
Behavioral:
  • time_to_fill_form, focus switches, paste_rate, typo_rate
  • «ventanas nocturnas» por hora local de la cuenta
Payments:
  • nuevo BIN/banco para la cuenta, prepaid/debit, primera transacción COF
  • 3DS_method_done, pasado challenge outcome, AVS/CVV normalización
Graph:
  • degree (dispositivo), triangles, IP compartida con clústeres de chargeback embedding_score (proximidad a clústeres de frod)

8) Explicabilidad y control del sesgo

SHAP/feature importance para soluciones de límites de T1/T2.
Las reglas de «safety net» sobre el ML son: por ejemplo, 'CVV = N' ⇒ challenge/decline independientemente de la baja puntuación.
Políticas de fairness: no utilizar atributos prohibidos; auditoría de la discriminación indirecta.

9) Experimentos y calibración

Pruebas A/B: reglas baseline vs ML; ML-on vs ML-off; T1/T2 diferentes.
Métricas: AR, CBR%, tasa 3DS, éxito de desafío%, costo/aprobado.
Profit-weighted ROC: optimizar no AUC en el vacío, sino la economía (loss matrix: FP = volumen de negocios perdido, FN = chargeback-loss + fees).

10) Monitoreo y deriva

drift de datos (PSI/KL) por fichas clave; target drift (charjbeki).
Alertas: crecimiento 'score> T2' en el clúster BIN/país; el estallido de '05' después de 3DS.
Readaptación regular (semanal/mensual) con safe-deploy (shadow → canary → full).
Control de calibración (Brier score, reliability curves).

11) Relación con routing y PSP

El scoring influye en el smart-routing: para scores de borde, envíe al PSP con el mejor AR al BIN/emisor.
Cuando se degrade ACS/emisor (ráfaga '91/96'), aumente temporalmente T1 (más frictionless con bajo riesgo) o redireccione a PSP-B.

12) Procesos y «governance»

Tarjeta modelo: propietario, versión, fecha de lanzamiento, KPI objetivo, riesgos.
Cambio-control: RFC para nuevas reglas/umbrales, registro de resultados A/B.
Paquete de muelle TRA para PSD2: descripción de la metodología, métricas de frod, frecuencias de procedimientos.

13) Anti-patrones

Mezclar fondos fuera de línea y en línea sin control de latencia → fugas/falsas victorias.
Hacer «decline total» en horas pico - mata AR y LTV.
Confiar sólo en las reglas o sólo en el ML.
Ignore las señales SCA-soft y no inicie 3DS si es necesario.
Lógica PAN/PII sin mascarilla: violación de PCI/GDPR.

14) Lista de verificación de implementación

  • Fichastor con paridad online/offline y validación de esquemas.
  • Normalización de AVS/CVV/3DS, servicio BIN, device-fingerprinting.
  • Modelo GBDT + reglas-safety-net + (opcional) grafo-embedding.
  • Calibración del umbral de T1/T2 bajo AR/CBR/Costo; Política SCA/TRA.
  • Servicio de puntuación en línea ≤150 ms, SLA/alertas.
  • Infraestructura A/B y métrica económica (profit-weighted).
  • Monitoreo de la deriva, readiestramiento regular, registro de lanzamientos.
  • Políticas PCI/GDPR: PAN-seguro, minimización de PII, registros explicables de soluciones.

15) Resumen

Un fuerte antifraude en iGaming es una combinación de: señales ricas (device/geo/BIN/comportamiento/grafo), fiestor constante, reglas de conjunto ML +, estrategia de umbral claro bajo SCA/TRA, y disciplina de operación (A/B, deriva, explainability) Así que retendrá la conversión, reducirá los charjbacks y hará que los ingresos sean predecibles.

Contact

Póngase en contacto

Escríbanos ante cualquier duda o necesidad de soporte.¡Siempre estamos listos para ayudarle!

Iniciar integración

El Email es obligatorio. Telegram o WhatsApp — opcionales.

Su nombre opcional
Email opcional
Asunto opcional
Mensaje opcional
Telegram opcional
@
Si indica Telegram, también le responderemos allí además del Email.
WhatsApp opcional
Formato: +código de país y número (por ejemplo, +34XXXXXXXXX).

Al hacer clic en el botón, usted acepta el tratamiento de sus datos.