Real-time fraud detection.
Decisión sub-segundo, sin frenar al cliente legítimo.
Detectar fraude en tiempo real exige bajar latencia, enriquecer con contexto cross-sistema y aplicar reglas combinadas con scoring de un motor especializado. Con MuleSoft orquestás todo el flujo: el evento de transacción llega, se enriquece en paralelo con histórico, device, geo, blacklist y velocity, se envía al motor (FICO, AWS Fraud Detector, custom), se aplica la decisión y se ejecuta la acción — todo en menos de un segundo, con audit log inmutable.
¿Qué resuelve fraud detection con MuleSoft?
El motor de scoring vive en un sistema especializado, pero la decisión real exige contexto de seis o siete fuentes y reglas de compliance que tienen precedencia. Hacerlo en menos de un segundo, con audit y feedback loop, es trabajo de orquestación. MuleSoft entra como integration backbone: enriquece, llama al motor, aplica compliance, ejecuta la acción y deja la traza inmutable.
- Enriquecimiento en paralelo con histórico, device, geo, blacklist y velocity.
- Decisión combinada: score del modelo + reglas de compliance.
- Acción dinámica: allow / challenge con OTP / block con caso de investigación.
- Audit log inmutable y feedback loop para mejorar el modelo.
Sistemas típicos involucrados
Las familias de sistemas que conviven en una operación de fraud detection en tiempo real.
Sistema transaccional
Core bancario, payment gateway o checkout de e-commerce que publica el evento de transacción y espera la decisión.
Motor de fraude
FICO Falcon, ACI ReD, Feedzai, AWS Fraud Detector o un motor custom basado en Python y modelos propios. MuleSoft no decide, orquesta.
Case management
SAS, Actimize o un Service Cloud configurado como case management para que los analistas de fraude trabajen los casos bloqueados.
Notificación
Twilio para SMS, push notifications a la app, email transaccional para avisos al cliente y alertas al supervisor on-call.
Arquitectura objetivo
Stream de eventos, orquestación con enrichment paralelo, motor de scoring y acción inmediata.
+----------------+ +----------------+
| Transaction | | Login event |
| System | | |
+--------+-------+ +--------+-------+
| |
v v
+-------------------------------------------+
| Event Stream (Kafka / Anypoint MQ) |
+--------------+----------------------------+
|
v
+-------------------------------------------+
| fraud-orchestrator-pa |
| - Enrich con histórico, device, geo |
| - Llama scoring engine |
| - Decision: allow / challenge / block |
+--------------+----------------------------+
|
+-------+-------+--------+-------+
| | | | |
v v v v v
+--------+ +-----+ +-----+ +--------+ +-----+
| Score | | Hold | | Notif| |Compli- | |Audit|
| Engine | | Acct | | | |ance | | |
+--------+ +-----+ +-----+ +--------+ +-----+System APIs
fraud-engine-sapi conversa con el motor de scoring. risk-context-sapi expone histórico, device, geo y blacklist. account-action-sapi materializa hold, unhold y freeze sobre la cuenta.
Process APIs
fraud-orchestrator-pa es el corazón: enriquece, decide y ejecuta. case-investigation-pa abre casos de investigación cuando la transacción se bloquea, con todo el contexto necesario.
Experience APIs
fraud-dashboard-eapi entrega vista en vivo de transacciones y alertas. investigator-eapi sirve a los analistas trabajando casos en case management.
Flujo paso a paso
Cómo se evalúa y resuelve una transferencia sospechosa, end-to-end.
- 1 El cliente intenta una transferencia o compra. El sistema transaccional publica un evento transaction.requested.v1 con todos los detalles.
- 2 fraud-orchestrator-pa consume el evento del bus en streaming.
- 3 La Process API enriquece en paralelo: tx-history-sapi devuelve histórico, device-sapi reporta device fingerprint, geo-context-sapi compara con perfil, blacklist-sapi y velocity-sapi cierran el contexto.
- 4 Cada llamada de enrichment tiene su propio timeout corto. Los resultados disponibles se ensamblan en un payload de decenas de features para el motor.
- 5 fraud-engine-sapi POST /score envía las features al motor (FICO, AWS Fraud Detector o custom) y recibe el score y la decisión recomendada.
- 6 Sobre el resultado del modelo se aplican reglas de compliance que tienen precedencia: ciertas operaciones siempre bloquean independiente del score.
- 7 La decisión final se materializa: score bajo permite la transacción, score medio dispara challenge con OTP por SMS o app, score alto bloquea y crea caso de investigación.
- 8 Si la decisión es challenge, se envía OTP vía Twilio o push y se espera confirmación del cliente con su propio timeout.
- 9 Si la decisión es block, se notifica al cliente con un mensaje claro de actividad inusual, se crea el caso en case management y se alerta al supervisor on-call.
- 10 Si el motor de scoring no responde, fallback a reglas determinísticas conservadoras (block sobre umbral configurado) para no dejar al cliente esperando.
- 11 Audit log inmutable registra inputs, output, latencias y decisión con cifrado, alimentando reportes regulatorios y feedback loop hacia el modelo.
Patterns aplicados
Los patrones que sostienen una operación de fraud detection en producción.
Sub-second latency end-to-end
Diseño obsesivo con la latencia. Cada llamada tiene timeout estricto y la composición evita encadenamientos innecesarios.
Enrichment en paralelo
Histórico, device, geo, blacklist y velocity se consultan en simultáneo. La latencia total tiende al máximo de las partes, no a la suma.
Decision tables parametrizables
Los thresholds y reglas viven fuera del código y se ajustan sin redeploy. Ops puede tunear allow/challenge/block según el comportamiento real.
Idempotency
Una misma transacción evaluada dos veces da el mismo resultado. Crítico para auditoría regulatoria y para evitar dobles bloqueos por reintentos.
Compliance gates sobre ML
Compliance siempre tiene precedencia sobre el score: ciertas reglas bloquean aunque el modelo no marque riesgo.
Audit log inmutable
Write-only, cifrado, con retención regulatoria. Sin él no hay defensa frente al regulador ni feedback útil para el modelo.
Cómo lo implementamos
Cinco fases del assessment a una operación tunable, con feedback loop hacia el modelo.
Mapa de fraude y stack actual
Inventario del sistema transaccional, motor de scoring vigente, fuentes de contexto, casos representativos de fraude y compliance, latencia tolerada por canal. Entregables: assessment, runbook actual, target de latencia por endpoint.
Orquestación y reglas
Diseño de fraud-orchestrator-pa, contratos de las System APIs de enrichment, integración con el motor de scoring, modelo de decision tables, política de fallback, audit y feedback loop con el modelo.
Construcción end-to-end
Implementación de la orquestación, integración con motor de fraude, case management y notificación, audit pipeline asincrónico. Tests MUnit, performance testing crítico, sandbox conectado a réplicas del motor real.
Hardening y go-live controlado
Hardening, security review, dry runs con casos reales, calibración de thresholds. Go-live por canal con monitoreo intensivo, rollback plan claro, hypercare con fraud ops y compliance.
Tuning y modelos nuevos
Tuning continuo de reglas, feedback loop hacia el modelo, integración con nuevos motores, expansión a nuevos canales (e-commerce, telco, pagos QR), capacitación del equipo del cliente para gobernar el sistema con autonomía.
Requisitos del proyecto
Lo que tiene que estar disponible del lado del cliente para arrancar.
Datos mínimos
Acceso a histórico de transacciones, device fingerprint, fuentes de blacklist y geo, motor de scoring vigente y reglas de compliance documentadas.
Licencias y capacidades
Anypoint Platform, Anypoint MQ o Kafka según volumen, conectores al sistema transaccional, motor de fraude y case management, infraestructura para audit cifrado.
Integraciones típicas
Sistema transaccional, motor de scoring, case management, notificación al cliente (SMS, push, email) y al supervisor on-call, audit pipeline y reportería regulatoria.
Pre-requisitos organizacionales
Sponsor de risk management, fraud ops disponible, compliance involucrada desde el día 1, plan de feedback loop hacia el modelo y runbook de incident response.
KPIs operativos
Las métricas que típicamente mejoran tras la implementación. Sin números de mercado: cada cliente fija su baseline.
| KPI | Qué mide | Por qué importa |
|---|---|---|
| Decision latency P99 | Latencia P99 de la decisión end-to-end desde el evento hasta la acción. | Por encima del segundo se degrada la experiencia de los clientes legítimos. Es la métrica más vigilada. |
| Block rate | Porcentaje de transacciones bloqueadas sobre el total evaluado. | Subidas o bajadas bruscas indican drift del modelo o ataques en curso. |
| False positive rate | Porcentaje de bloqueos que después se confirmaron como legítimos. | Cada falso positivo es un cliente molesto. Es el KPI que más empuja el tuning del modelo. |
| False negative rate | Fraudes que pasaron y se identificaron post-hoc. | Es el costo directo en pérdidas. Cierra el feedback loop hacia el modelo. |
| Engine fallback rate | Porcentaje de transacciones decididas por reglas conservadoras porque el motor no respondió. | Indicador de confiabilidad del stack de scoring y disparador de mejoras de SLA con el proveedor. |
| Audit completeness | Porcentaje de decisiones con registro de auditoría completo y cifrado. | Sin audit completo no hay reporte regulatorio defendible ni feedback útil al modelo. |
Time-to-value: primera ola de transacciones evaluadas en producción tras 14 a 20 semanas desde el kickoff, con métricas observables desde el primer mes.
Cómo se mide: dashboard entregado por Solu sobre Anypoint Monitoring, complementado con Splunk o Datadog y reportes regulatorios formales hacia el área de compliance.
Preguntas frecuentes
No. MuleSoft no es el motor de detección. El cerebro de scoring vive en FICO Falcon, AWS Fraud Detector, Feedzai o un modelo Python custom. MuleSoft orquesta: recoge el evento, enriquece con contexto, consulta al motor, aplica compliance, ejecuta la acción y deja el audit. Hace que esa cadena pase en menos de un segundo.
Tres pilares. Enrichment en paralelo, no encadenado. Timeouts estrictos con fallback determinístico cuando alguna fuente se atrasa. Audit pipeline asincrónico para no impactar la respuesta principal. La fase de Build incluye performance testing con perfiles de carga reales y la observabilidad expone P99 por componente.
Hay fallback determinístico: reglas conservadoras tuneables que bloquean sobre umbrales claros (montos altos, destinatarios nuevos, geos sospechosas). El cliente percibe continuidad del servicio aunque con políticas más estrictas. Cada uso del fallback queda registrado y dispara alerta al equipo del proveedor de scoring.
Sí. Cuando una transacción se bloquea, fraud-orchestrator-pa abre el caso vía investigator-eapi con todo el contexto: payload, score, features que pesaron, audit. Service Cloud o el case management que use el cliente recibe el caso listo para trabajar, sin que el analista tenga que reconstruir la historia.
La arquitectura está diseñada para cumplirlos. Latencia, audit log inmutable, retención regulatoria, segregación de duties entre ops y fraud, y reportería periódica. La fase de Deploy incluye conformance testing con compliance, security review y la documentación entregable. Los reportes regulatorios se generan desde el audit pipeline.
Decisión sub-segundo. Audit log inmutable.
Hablemos del estado de tu motor de scoring y tu stack transaccional, y diseñamos juntos el roadmap.