Alertas de fraude y de anomalías en pagos con umbrales claros
Una alerta que salta todo el tiempo se ignora y una que nunca salta no protege. Esta guía arma un sistema de alertas con reglas, umbrales estadísticos y acciones definidas por nivel de riesgo.
Dos tipos de señales
Reglas conocidas. Patrones que ya sabes que son riesgosos. Ejemplo: cambio de cuenta bancaria de un proveedor seguido de un pago grande.
Anomalías. Comportamientos que se salen de lo normal para ese cliente, proveedor o canal. Ejemplo: un cliente que siempre paga $ 2.000.000 y de pronto paga $ 20.000.000 con una tarjeta nueva.
Las reglas atrapan lo conocido. Las anomalías atrapan lo nuevo. Usa las dos.
Pagos entrantes y salientes
Separa los dos flujos, porque los riesgos son distintos.
| Flujo | Riesgos típicos |
|---|---|
| Entrantes (cobros) | Tarjetas robadas, contracargos, pruebas de tarjetas con montos pequeños |
| Salientes (pagos a proveedores, reembolsos) | Suplantación de proveedor, cambio de cuenta, facturas duplicadas, reembolsos a cuentas distintas |
Reglas base para pagos salientes
- Cambio de datos bancarios de un proveedor en los últimos N días antes de un pago. N es un supuesto que defines tú.
- Factura con el mismo valor, proveedor y fecha cercana a otra ya pagada.
- Pago a un proveedor creado hace pocos días.
- Reembolso a una cuenta distinta a la del pago original.
- Pago fuera de horario o aprobado por quien también lo creó.
Reglas base para pagos entrantes
- Muchos intentos fallidos con la misma tarjeta o desde el mismo origen en poco tiempo.
- Varios montos pequeños seguidos, típicos de prueba de tarjetas.
- Datos de facturación y envío inconsistentes.
- Cliente nuevo con monto muy alto.
Coordina con tu pasarela. Muchas ya tienen controles de fraude. Tus reglas complementan con datos que solo tú tienes, como el historial del cliente en tu ERP.
Umbrales estadísticos simples
Para anomalías no necesitas un modelo complejo al inicio. Un umbral por desviación respecto al historial propio funciona bien como primera versión.
Puntaje z del monto:
z = (monto − promedio_historico) / desviacion_historica
Ejemplo de supuesto: alerta si z > 3 y hay al menos 10 pagos históricos.
Los montos suelen tener colas largas. Una alternativa robusta usa la mediana y la desviación absoluta mediana (MAD):
z_robusto = 0,6745 × (monto − mediana) / MAD
Otras señales con umbral:
- Frecuencia: pagos en la última hora frente al promedio por hora del cliente.
- Novedad: primera vez con ese medio de pago, ese banco o ese país.
- Velocidad de cambio: datos de contacto o bancarios modificados recientemente.
Puntaje de riesgo combinado
Suma señales con pesos. Ejemplo de supuesto:
| Señal | Puntos |
|---|---|
| Cambio de cuenta bancaria en los últimos 15 días | 40 |
| z del monto > 3 | 25 |
| Proveedor creado hace menos de 30 días | 20 |
| Fuera de horario | 10 |
| Creador y aprobador son la misma persona | 30 |
Y niveles con acción:
| Puntaje | Nivel | Acción |
|---|---|---|
| 0–29 | Bajo | Sigue el flujo normal |
| 30–59 | Medio | Revisión de una persona antes de ejecutar |
| 60 o más | Alto | Bloqueo y verificación por otro canal |
Los pesos y cortes son supuestos de partida. Ajústalos con tus datos.
Dónde entra la IA
- Explicar la alerta. Un modelo redacta por qué saltó, con las señales y los datos. La persona entiende en segundos.
- Leer contexto no estructurado. Correos de solicitud de cambio de cuenta, por ejemplo, con señales de urgencia o de dominio parecido al real.
- Agrupar alertas relacionadas. Varias alertas del mismo proveedor en un caso.
El puntaje y la decisión de bloqueo son código. El modelo no decide si un pago sale.
Arquitectura
La etiqueta final de cada alerta es oro. Con ella mides y ajustas.
Verificación por otro canal
Para cambios bancarios y alertas altas, verifica por un canal distinto al de la solicitud. Si el cambio llegó por correo, llama al número del proveedor registrado en tu maestro. El número que trae el correo se ignora.
Métricas
| Métrica | Fórmula |
|---|---|
| Precisión de alertas | alertas confirmadas como fraude / alertas |
| Cobertura | fraudes detectados por alerta / fraudes conocidos |
| Alertas por día | conteo, por nivel |
| Tiempo de resolución | horas promedio por alerta |
| Pagos legítimos demorados | alertas falsas que retrasaron un pago |
Si la precisión es muy baja, el equipo dejará de revisar. Sube los umbrales o refina reglas antes de que eso pase.
Errores comunes
- Umbrales globales para clientes o proveedores muy distintos.
- Alertas sin acción definida.
- Verificar por el mismo canal del atacante.
- No etiquetar el resultado de cada alerta.
- Confiar solo en los controles de la pasarela para pagos salientes.
Checklist
Preguntas frecuentes
¿Necesito mucho historial para empezar?
Las reglas funcionan desde el primer día. Los umbrales estadísticos necesitan historial por entidad. Mientras no exista, usa umbrales por grupo, como proveedores del mismo tipo.
¿Esto reemplaza el control interno?
No. Lo apoya. La segregación de funciones y las aprobaciones siguen siendo la base.
¿Qué hago si un fraude ya ocurrió?
Contacta de inmediato a tu banco, documenta el caso y consulta con tu asesor legal. Luego agrega la regla que lo habría detectado.