Velocity Limits y Anti-Abuse

1) Qué es velocity y por qué lo necesita

• reducir el flúor y la explotación de los bonos/promociones,
• proteger la infraestructura de pago de las «tormentas» de los retraídos,
• mantener una conversión saludable, traduciendo los intentos dudosos en un desafío (3DS/SCA) en lugar de un «fallo duro» siempre que sea posible.

Los controles Velocity complementan la puntuación, AVS/CVV, 3DS2/SCA y smart-routing.

2) Qué entidades limitar (scopes)

• Entidades de pago: 'card _ token' (vault/network), 'bin', 'issuer', 'psp _ route'.
• Personalizado: 'account _ id', 'kyc _ level', 'email/phone'.
• Técnicos: 'device _ id' (fingerprint/SDK), 'ip', 'asn',' session _ id '.
• Contexto empresarial: 'bonus _ id', 'campaign _ id', 'country', 'mcc 7995' subtipo (depósito/retirada).
• Financiero: 'amount _ bucket' (micro/mediano/grande), 'currency', 'payment _ method'.

3) Ventanas y contadores

Ventana fija (T = 15m/1h/24h): simple pero sensible a los límites.
La ventana deslizante es más precisa, según el intervalo «deslizante».
Bucket Leaky/Bucket Token - suavizar las ráfagas, establecer un ancho de banda constante.
Combinado: burst (ráfaga corta) + sustained (flujo largo).

• 'device _ id': ≤ 3 intentos de autorización en 15 minutos; ≤ 10 en 24 horas.
• 'card _ token': ≤ 2 decline seguidos sin 3DS; el tercero es el 3DS obligatorio.
• 'ip': ≤ 5 'card _ token' únicos a la 1 hora (de lo contrario, captcha/bloque).
• 'account _ id': ≤ 2 depósitos cancelados seguidos; a continuación, el culdown 1 hora.

4) Algoritmos de restricción (corto)

• Inicialice 'capacity' y 'refill _ rate'.
• Antes de cada intento, «saque» 1 token; si no hay tokens - challenge/decline.

• La cola se filtra a una velocidad constante; los eventos que llegan desbordan - throttle.

• 1ª repetición: 2-5 min → 2ª: 10-20 min → 3ª: 1-2 h → parada, o transferencia a un método alternativo.

5) Políticas de decisión (decisioning)

• Allow: bajo riesgo, dentro de los umbrales.
• Desafío: superaron el umbral «blando» → 3DS/SCA/capcha/KBA (preguntas).
• Throttle: restringir temporalmente (couldown) con UX transparente.
• Decline: infracciones graves (exceso masivo de tarjetas, bot pools, bonus abuse).
• Reroute: cambio de método/PSP (por ejemplo, A2A) en una ráfaga de '91/96' en el emisor.

Mini matriz de ejemplo

'device _ id' intenta ≥ 3 en 15 min y 'cvv = N' ≥2 → Decline + capcha.
'card _ token' 2 soft-decline consecutivo → 3DS-challenge (obligatorio).
'ip' ≥ 5 'account _ id' únicos en 30 min → Throttle 30 min + KYC-check.
'account _ id' depósito-retiro-depósito en 10 min (carrusel) → Desafío o límite en la cantidad.

6) Velocity para depósitos, retiros y retiros

• Proteja los «micro-rellenos» (muchas transacciones pequeñas): límite de cantidad y volumen de negocios total por T.
• Con la serie '05 '/' 14 '/' 54' - detenga el «exceso» de datos, traduzca a 3DS.

• Extienda las colas CIT y MIT. Para el MIT, utilice las ventanas blandas T + 1/T + 24h.
• Soft-decline 'SCA required' → inmediatamente 3DS, no quite los intentos.

• Límites separados por cantidad/frecuencia: por ejemplo, ≤ 2 salidas/24h y ≤ N por suma/semana.
• «Escalera» KYC: cuanto mayor sea la verificación, mayores serán los límites.
• Detect «circling»: depósito rápido y retiro instantáneo - revisión manual/hold.

7) Promociones y bonificaciones Anti-Abuse

Por-campaign caps: 'bonus _ id' ≤ X activaciones en 'device _ id '/' ip '/' payment _ fingerprint'.
«Enchufes» (tramo de dinero entre cuentas): gráficos-análisis de tarjetas compartidas/IP/dispositivos.
Cool-off Windows: después del depósito de bonificación - prohibición de retiro instantáneo, reglas transparentes en ToS.
Sanciones por niveles: desde bloqueos temporales hasta «permanentemente», con un diario de causas.

8) Arquitectura: dónde vivir las reglas velocity

Puerta de enlace en tiempo real (en el orquestador): solución ≤ 50-100 ms.
Almacenamiento de contadores: in-memory (Redis/KeyDB) + «resúmenes» a largo plazo (DWH).
Fichero: ventanas/unidades únicas (15m/1h/24h/7d).
Rule engine + ML scoring: «safety-net» reglas sobre el modelo.
Banderas de configuración: «habilitar 3DS», «más estricto en la región X», «pausa PSP-A».
Idempotencia: protección contra duplicados en repeticiones/tiempos de espera.

9) Pseudocódigo de reglas (esbozo)

pseudo on payment_attempt(ctx):
s = features(ctx) // device/ip/account/bin/score/avs/cvv/history if counter(device, 15m) >= 3 and cvv_fail(device, 15m) >= 2:
return DECLINE(reason="velocity_device_cvv")
if soft_declines(card_token, 1h) >= 2:
return CHALLENGE_3DS()
if uniq_accounts(ip, 30m) >= 5:
return THROTTLE(ttl=30m)
if score > T2 and velocity(account, 1h) > Vmax:
return DECLINE(reason="high_risk_burst")
return ALLOW

10) Patrones UX (sin romper la conversión)

Mensajes claros: "Demasiados intentos en poco tiempo. Pruebe en 15 minutos o confirme en el banco".
Botón «Repetir más tarde» con el temporizador.
Sugerencia de alternativas: A2A/billeteras locales cuando se reproducen.
Auto-3DS sin volver a escribir los detalles en SCA-soft.
Capcha sólo puntual (por señales IP/ASN/bot), no a todos.

11) Cumplimiento y privacidad

GDPR/PII: almacenar IDs mínimos (hashes de dispositivos, tokens de tarjetas, last4), políticas transparentes.
PCI DSS: sin PAN/CVV en los logs; eventos velocity sin datos sensibles.
PSD2/SCA: traduzca los excesos en desafío cuando corresponda, en lugar de los fallos totales.

12) Métricas, alertas, SLO

• Approval Rate (general y cuando se activan las reglas).
• False Positive Rate rige velocity (proporción de bloques honestos → sobre la legitimidad posterior).
• El número de «tormentas» retraídas y el tiempo medio de recuperación.
• Proporción de traducciones de decline → challenge con un resultado exitoso.
• Chargeback rate en los segmentos donde los límites se han disparado (esperamos ↓).

• Spike '05/14/54' + aumento de intentos> X en 15 minutos en el clúster BIN/ASN.
• La ráfaga '91/96' → el aumento automático del umbral T1 + routing en PSP-B.
• FP-rate de la regla> de destino (por ejemplo, 1. 5 × mediana semanal).

• La solución velocity ≤ 100 ms p95.
• Porcentaje de pagos exitosos transferidos a 3DS en lugar de rechazar ≥ objetivo.

13) Anti-patrones

Un límite «total» universal para todos los mercados y tipos de clientes.
Bloquear por 'AVS = U/S/G' en países donde AVS no funciona a tiempo completo.
No compartir CIT/MIT: rompe suscripciones/repeticiones.
Retraer sin jitter y sin idempotencia son tomas y tormentas.
Ocultar las razones del fracaso - el sapport y la toxicidad están creciendo.

14) Lista de verificación de implementación

• Mapa de entidades (scopes) y ventanas (15m/1h/24h/7d).
• Selección de algoritmos: sliding + token bucket para bursts.
• Normalización de retiros: backoff + jitter, separado para CIT/MIT.
• Integración con 3DS/SCA: auto-desafío con excesos suaves.
• Límites individuales para retiros y bonificaciones; Verificación gráfica de vínculos.
• Observabilidad: dashboards KPI/alertas/reglas de auditoría.
• Plantillas de mensajes UX y métodos alternativos.
• Políticas PCI/GDPR: tokens, enmascaramiento, minimización de PII.
• Pruebas A/B de umbrales de mercado/BIN/ASN y perfiles de clientes.
• Incidencias de playbooks: degradación del emisor/PSP, estallido de bots.

15) Resumen

Los límites de velocidad efectivos son ventanas y contadores de varios niveles a través de diferentes entidades, algoritmos de suavizado (bucket token/leaky), retraídas inteligentes y un estrecho vínculo con la 3DS/SCA y la puntuación. Dicho circuito reduce los fluidos y abusivos, no sofoca la conversión, y ayuda a mantener la monetización estable con la volatilidad de los emisores y el tráfico.