Checklist de reglas antifraude para campañas de referidos

El bono de referido paga por traer un cliente. El problema es que la mayoría de los programas pagan por traer un registro, y un registro es trivial de fabricar a escala. La diferencia entre ambos es donde vive todo el leakage. Esta checklist cierra esa brecha.

1. Reglas de pago del bono

• ☐ El bono se paga después de una acción de valor difícil de falsificar (primera compra sobre un umbral, o retención a 30 días), no al registro.
• ☐ El referido debe ser un usuario nuevo real (no una cuenta reactivada ni un duplicado del referente).
• ☐ Existe un tope de bonos cobrables por referente en un período dado.

2. Identidad y unicidad

• ☐ El beneficio se topea por identidad verificada (KYC) o device_id, no por cuenta.
• ☐ Hay verificación de unicidad de dispositivo y método de pago antes de acreditar.
• ☐ Se bloquean alias de email y patrones de datos sintéticos conocidos.

3. Exclusión y velocidad

• ☐ Está definido explícitamente qué otras promos no se acumulan con el bono de referido.
• ☐ Hay un límite de referidos por unidad de tiempo (anti-velocity) por usuario y global.
• ☐ Existe un circuit breaker que pausa la campaña ante picos anómalos de altas.

4. Monitoreo en producción

• ☐ Hay una consulta que detecta grafos de referidos cerrados (círculos entre pocas identidades).
• ☐ Se mide la retención por cohorte referida: si es cercana a cero, es un ring.
• ☐ Existe una alerta cuando la tasa de referidos por dispositivo supera un umbral.

5. Validación pre-lanzamiento

• ☐ Se corrió un test adversarial sobre las reglas del programa.
• ☐ El leakage estimado en USD está cuantificado y es aceptable.
• ☐ El parche de Términos y Condiciones fue revisado por legales.

Si tildaste menos de la mitad de esta lista, tu programa de referidos probablemente esté financiando granjas ahora mismo. Los referral rings son silenciosos: crecen en el número de "usuarios" mientras la retención real cae.