El SQL que necesitás para monitorear abuso de cashback en producción

Prevenir el abuso antes de lanzar reduce el cashback leakage, pero ninguna promo queda blindada para siempre: los atacantes prueban, y las reglas se degradan. Por eso el pre-launch y el monitoreo son complementarios. Acá van las consultas base para vigilar cada vector. Son plantillas — ajustá nombres de tabla y columnas a tu esquema.

Multi-accounting: identidades por dispositivo

Buscás dispositivos o métodos de pago detrás de más cuentas de las que un hogar justificaría:

SELECT device_id,
       COUNT(DISTINCT user_id) AS cuentas
FROM   sessions
GROUP  BY device_id
HAVING COUNT(DISTINCT user_id) > 3
ORDER  BY cuentas DESC;

Repetí la misma lógica cambiando device_id por hash de tarjeta o CBU/CVU. Ver el detalle del vector en esta guía.

Referral rings: cohortes con retención cero

Un referido legítimo compra y vuelve; el nodo de un ring cobra y desaparece:

SELECT r.referrer_id,
       COUNT(*) AS referidos,
       AVG(CASE WHEN u.compras_30d > 0 THEN 1 ELSE 0 END) AS tasa_activacion
FROM   referrals r
JOIN   users u ON u.user_id = r.referred_id
GROUP  BY r.referrer_id
HAVING COUNT(*) >= 5
   AND AVG(CASE WHEN u.compras_30d > 0 THEN 1 ELSE 0 END) < 0.1;

Para detectar los círculos en sí conviene un análisis de grafo sobre la tabla de referidos.

Promo stacking: órdenes con margen negativo

SELECT order_id,
       SUM(benefit_amount) AS beneficios,
       gross_margin
FROM   order_benefits
GROUP  BY order_id, gross_margin
HAVING gross_margin < 0
    OR COUNT(*) > 1;

Velocity: eventos por minuto

SELECT date_trunc('minute', created_at) AS minuto,
       COUNT(*) AS cobros
FROM   cashback_events
GROUP  BY 1
HAVING COUNT(*) > 100   -- umbral vs. tu línea base
ORDER  BY 1;

El umbral correcto no se adivina: sale de simular el ataque contra tus reglas antes de lanzar. Cuando MateGuard corre ese análisis, además del leakage estimado te devuelve exactamente estas consultas, ya calibradas a tu campaña, para que el monitoreo arranque el día uno.