Reglas vs. machine learning en antifraude

En prevención de fraude transaccional, la discusión reglas vs. machine learning fraude suele simplificarse de más. En producción, casi siempre conviven. Este artículo aclara cuándo priorizar reglas transparentes, cuándo aporta un modelo de machine learning y cómo combinarlos en pasarelas y fintechs colombianas.

1. Qué hace cada capa

Reglas de negocio: condiciones explícitas (monto, horario, geolocalización, velocity) que usted define y puede auditar. Ideales para tipologías conocidas: “primer depósito + retiro en menos de X minutos”, “transacción fuera de horario habitual”.

Machine learning: modelos que aprenden combinaciones no obvias de señales. Requieren datos etiquetados, monitoreo de drift y explicación para compliance.

La literatura técnica muestra que modelos supervisados suelen superar reglas puras en métricas como F1, pero a costa de más cómputo e ingeniería — por eso las arquitecturas recomendadas son híbridas: score de ML + capa de reglas.

2. Cuándo empezar (o quedarse) con reglas

Priorice reglas si:

• Tiene poco historial etiquetado de fraude confirmado.
• Necesita explicabilidad inmediata ante auditores o chargebacks.
• Quiere iterar política en días, no en ciclos de reentrenamiento.
• Opera tipologías locales claras (PSE, Bre-B, cash-out rápido).

Guía detallada: reglas antifraude personalizadas en Colombia.

3. Cuándo sumar machine learning

El ML aporta cuando:

• El volumen y la diversidad de patrones superan lo que reglas fijas pueden cubrir.
• Tiene labels de fraude (chargebacks cursados, casos confirmados) en volumen útil.
• Busca reducir falsos positivos en segmentos donde reglas rígidas bloquean clientes buenos.

El score no reemplaza la política: responde “cuánto riesgo”; usted decide aprobar, revisar o rechazar. Vea qué es un score de riesgo transaccional.

4. Arquitectura híbrida típica

Flujo vía API (como Kairo Shield):

1. Payload de transacción → endpoint de evaluación.
2. Respuesta: score, decision, rules_triggered.
3. Su backend aplica política de negocio.

Las reglas capturan política explícita; el modelo captura señales débiles en conjunto. En early stage, muchas operaciones ganan más con reglas + score bien operados que con un modelo opaco sin dueño.

5. Errores comunes

Error	Consecuencia
Solo reglas rígidas	Falsos positivos, conversión caída
Solo ML sin reglas de negocio	Decisiones opacas, difícil defensa ante auditor
ML sin labels locales	Modelo calibrado para otro mercado
Sin monitoreo	Drift silencioso cuando cambia el mix de pagos

En Colombia, métodos como PSE y Bre-B cambian el mix rápido — riesgos de métodos de pago locales.

6. Build vs. buy del componente ML

Armar un equipo interno de ML antifraude implica nómina, MLOps y meses hasta producción. Para la mayoría de pasarelas y PSPs, integrar una API especializada entrega score + reglas en semanas. Compare números en Kairo Shield vs. equipo propio de ML.

7. Conclusión

No elija “reglas o ML”. Elija orden y peso: reglas para política auditable y tipologías claras; ML para patrones complejos cuando hay datos. Kairo Shield API trae ambos en early access con soporte en español.