Fraud Detection Agent.
Detección de fraude que aprende, sin frustrar al cliente legítimo. Score, challenge o rechazo con audit completo.
El agente custom que evalúa cada transacción y cada interacción crítica con análisis multidimensional (patrón de compra, dispositivo, IP, comportamiento, histórico). Genera score y decide aprobar, lanzar challenge (3DS, OTP) o rechazar. Cierra el loop con outcomes (chargeback / no chargeback) para recalibrar. Para Risk / Fraud, Payment Operations y Commerce IT.
¿Qué hace Fraud Detection Agent?
Fraud Detection Agent analiza cada transacción y cada interacción crítica con señales de patrón de compra, dispositivo, IP, comportamiento del shopper e histórico del cliente. Calcula un score y aplica la decisión: aprobar, lanzar challenge (3DS, OTP) o rechazar. Cada decisión queda en audit trail y alimenta el feedback loop con el outcome real (chargeback o no chargeback) para recalibrar continuamente.
Cómo funciona paso a paso
De la transacción al outcome. 6 pasos con feedback loop continuo.
Trigger en transacción o interacción
Cada checkout, cambio de dirección, alta de medio de pago o uso de promoción crítica activa al agente.
Análisis multidimensional
Hidrata patrón de compra, dispositivo (fingerprint), IP, comportamiento de la sesión, histórico del cliente y velocidad de navegación.
Scoring de fraude
Calcula score normalizado (0-100). Aplica reglas determinísticas como filtro previo y razonamiento sobre las señales para casos en zona gris.
Decisión: aprobar / challenge / rechazar
Score bajo: aprobar sin fricción. Score medio: challenge (3DS, OTP). Score alto: rechazar con motivo. La política de bandas la define Risk.
Log para audit y revisión post-hoc
Cada decisión queda con score, señales, dispositivo e IP en el audit trail. Risk puede revisar y corregir manualmente.
Feedback loop con outcomes
El sistema observa chargebacks reales 30-90 días después y recalibra. Falsos positivos y falsos negativos alimentan el ajuste continuo.
Ejemplo de interacción real
Arquitectura del agente
Las cuatro primitivas que sostienen al Fraud Detection Agent dentro de tu org de Salesforce.
Data
Fuentes de grounding
- Transactions DMO (24 meses labeled)
- Customer 360 + histórico
- Device fingerprint + IP
- Browsing Events de la sesión
- Chargeback outcomes
- Promo Abuse signals
Actions
Lo que el agente ejecuta
- analyzeTransaction
- scoreFraud
- decideOutcome
- request3DSChallenge
- requestOTP
- declineTransaction
- logFraudEvent
- updateModelWithOutcome
Guardrails
Controles de confianza
- Reglas determinísticas como filtro previo
- Bandas de score definidas por Risk
- Override manual en zona gris
- Compliance LATAM (LGPD, Habeas Data)
- Audit trail inmutable
Channels
Dónde aplica el agente
- Checkout (B2C, B2B, D2C)
- Account creation y login
- Cambio de medio de pago
- Aplicación de promociones críticas
- Portal de revisión de Risk
Requiere integración con payment gateway: Sí (3DS, OTP, decline contracts)
Requiere Data Cloud: Recomendado (transacciones labeled + outcomes)
Requiere Einstein Trust Layer: Sí (incluido en Agentforce)
Implementación en 5 fases
De discovery a producción. Fraud Detection Agent en operación en 12-14 semanas.
Discovery y baseline de fraude
Workshop con Risk, Payment Operations, Commerce IT y compliance. Mapeo de tipos de fraude, baseline de chargeback ratio y reglas vigentes.
Data readiness
Transactions DMO de 24 meses con outcomes labeled (chargeback / no chargeback). Device fingerprint capturado. Signals de comportamiento vía Web SDK.
Agent build
Topics, Actions, integración con payment gateway (3DS, OTP), suite de tests sobre fraude conocido. Reglas determinísticas como filtro previo.
Shadow mode + piloto
Sem 9-10 modo shadow: el agente score sin actuar, comparación contra reglas vigentes. Sem 10-12 piloto en 10-15% del tráfico con Risk supervisando.
Rollout y recalibración
100% del tráfico. Recalibración trimestral con outcomes. Retrospectiva mensual con falsos positivos, falsos negativos, drift y nuevos patrones.
Equipo típico de implementación
Requisitos para arrancar
Lo que necesitás tener listo antes de poner Fraud Detection Agent en producción.
Datos mínimos
- Transactions labeled 24 meses
- Device fingerprint y IP capturados
- Signals de comportamiento por sesión
- Chargeback outcomes históricos
Licencias
- Commerce Cloud (B2C, B2B o D2C)
- Agentforce for Commerce (Flex Credits)
- Data Cloud (recomendado)
- Einstein Trust Layer (incluido)
Integraciones
- Payment gateway con 3DS y OTP
- Device fingerprint provider
- Web SDK de Data Cloud
- Webhook de chargeback outcomes
Org readiness
- Sponsor en Risk / Fraud
- Bandas de score definidas por Risk
- Política de challenge y rechazo
- Compliance LATAM al día
KPIs: antes y después
KPIs esperados al implementar este agente. Rangos referenciales para planificación; los resultados reales dependen del estado de los datos y la operación de cada empresa.
| Métrica | Antes | Después | Cambio |
|---|---|---|---|
| Fraud rate | Baseline | -30-50% | Reducción |
| Falsos positivos vs reglas estáticas | Baseline | -20-40% | Mejor precisión |
| Chargeback ratio | Baseline | -25-45% | Reducción |
| Approval rate de transacciones legítimas | Baseline | +2-5 ppt | Mejora |
| Tiempo del equipo de Risk en revisión manual | Baseline | -30-50% | Eficiencia |
| Time-to-value | N/A | 4-8 semanas post go-live | Progresivo |
Solu entrega dashboard con fraud rate, false positives, chargeback ratio, drift del modelo y alertas de patrones nuevos.
Riesgos comunes y cómo los mitigamos
Falsos positivos rechazan clientes legítimos
Bloquear a un cliente legítimo cuesta el ticket actual y la confianza para futuras compras.
Mitigación: Bandas de score con zona gris obligatoria de challenge en lugar de rechazo. Override manual disponible para Risk. Recalibración trimestral basada en falsos positivos confirmados.
Drift cuando aparecen patrones nuevos
Tras 3-6 meses, los atacantes se adaptan y el modelo entrenado con datos viejos pierde precisión.
Mitigación: Monitoring de drift continuo. Recalibración trimestral obligatoria. Alertas sobre patrones emergentes (nuevos device fingerprints, IPs en bloque). Combinación con reglas determinísticas que se actualizan más rápido que el modelo.
Compliance LATAM (LGPD, Habeas Data)
Datos de dispositivo, IP y comportamiento son sensibles bajo regulación de privacidad de Brasil, Colombia y otros países.
Mitigación: Trust Layer con masking de PII. Política de retención explícita por país. Right to be forgotten respetado en el audit trail. Consent layer al checkout.
Latencia que rompe la experiencia de checkout
Si el agente tarda 3-5 segundos en decidir, el shopper abandona el checkout antes de completar.
Mitigación: Latencia objetivo menor a 500 ms para el scoring. Reglas determinísticas como pre-filtro rápido. Fallback a modo conservador (aprobar con monitoring) si supera el umbral de tiempo.
Promo abuse específico de LATAM
Múltiples cuentas del mismo cliente para abusar de cupones de bienvenida o de Hot Sale.
Mitigación: Identity resolution cross-cuenta vía device fingerprint, IP, dirección y método de pago. Threshold de cuentas por dispositivo. Escalation a Risk antes de aplicar la promoción crítica.
Preguntas Frecuentes
No, lo complementa. El gateway sigue ejecutando 3DS y OTP cuando el agente lo solicita. El agente agrega capa de razonamiento sobre señales del Customer 360 y comportamiento que el gateway no tiene. La decisión final del fondeo siempre la toma el banco emisor.
MercadoPago, Stripe, Adyen, Cybersource y dLocal como base. Otros gateways locales se integran vía API REST con autenticación OAuth o equivalente. El agente necesita poder solicitar 3DS y OTP, y recibir el outcome de chargeback.
Idealmente 24 meses con outcomes labeled (chargeback / no chargeback). Con 12 meses se puede arrancar pero el modelo es más débil contra patrones estacionales. La calidad del label importa más que el volumen: chargebacks bien clasificados son la señal de oro del entrenamiento.
Tiene un modo evento comercial con bandas de score más conservadoras (más propenso a challenge en lugar de aprobación directa) durante la ventana del evento, dado que el patrón de tráfico se aleja del baseline. Recalibración rápida con datos del propio evento.
Sí. Trust Layer aplica masking de PII antes de enviar datos al LLM. La retención de signals queda configurada por país según regulación. El cliente puede ejercer right to be forgotten y el audit trail queda con los identificadores anonimizados.
12-14 semanas. La fase más larga es preparar el dataset labeled de chargebacks con suficiente calidad para entrenar el modelo y validar el modo shadow durante 1-2 semanas antes de aplicar decisiones reales en producción.
Menos fraude. Menos falsos positivos. Más conversión legítima.
Hablá con un Commerce Architect de Solu. En discovery mapeamos el baseline de fraude y diseñamos la primera ventana de impacto.