Fraude en marketplaces: proteger ambos lados

En un marketplace el fraude no es unilateral: el riesgo puede venir del comprador, del vendedor o de la colusión entre ambos. Una plataforma que solo mira el checkout deja un flanco abierto en onboarding de sellers, liquidaciones y retiros. Esta guía describe patrones típicos y cómo priorizar detección sin frenar el crecimiento del GMV.

Para la solución de producto, vea Kairo Shield para marketplaces.

1. Por qué el marketplace es bilateral

A diferencia de un e-commerce propio, usted intermedia entre dos actores con incentivos distintos:

• El comprador puede disputar, usar tarjetas robadas o abusar de promociones.
• El vendedor puede ser fantasma, clonar catálogo o nunca cumplir el pedido.
• Ambos pueden coludir para simular ventas, lavar fondos o generar chargebacks sistemáticos.

Si su motor de riesgo solo evalúa el pago del comprador, pierde visibilidad sobre el payout al seller — donde muchas pérdidas netas ocurren.

2. Patrones de fraude del lado comprador

Patrón	Señal típica	Impacto
Friendly fraud	Disputas repetidas, mismo dispositivo	Chargebacks concentrados
Tarjetas robadas	Primer compra de alto ticket, dirección distinta al pagador	Pérdida + disputa
Abuso promocional	Cuentas nuevas, cupones en cadena	Margen promocional erosionado

En retail puro estos casos se parecen a fraude en checkout e-commerce. En marketplace, el daño se amplifica porque usted puede haber liquidado al vendedor antes de la disputa.

3. Patrones del lado vendedor

• Seller fantasma: cuenta nueva, catálogo copiado, precios irreales, fulfillment que no llega.
• Triangulación: el seller actúa como intermediario de bienes robados o de terceros desconocidos.
• Retiros acelerados: cash-out inmediato tras la primera venta, destino inconsistente con el historial.

Detectar esto tarde implica pérdida neta: el dinero ya salió hacia una cuenta mula o un beneficiario distinto al seller declarado.

4. Colusión y abuso de plataforma

Los casos más costosos suelen combinar cuentas relacionadas:

• Comprador y vendedor comparten dispositivo, IP o método de pago.
• Transacciones circulares entre cuentas del mismo grupo para inflar reputación o volumen.
• Disputas coordinadas para extraer reembolsos y mantener el producto.

Un antifraude solo de reglas de BIN no correlaciona estos patrones. Necesita eventos de pago, onboarding y payout en el mismo sistema de score.

5. Qué evaluar en cada momento del ciclo

1. Onboarding del seller: identidad, coherencia de datos, velocidad de alta vs. catálogo.
2. Pago del comprador: monto, método, velocity, consistencia pagador–destino.
3. Liquidación / payout: frecuencia, monto acumulado, cambios de cuenta bancaria.

Kairo Shield API permite enviar eventos distintos por tipo de actor y recibir score + decisión en milisegundos — la misma capa para cobro y retiro. Profundice en antifraude para marketplaces.

6. Priorización sin un equipo de fraude enorme

Cuando el GMV crece más rápido que el headcount de riesgo:

• Automatice score y reglas para filtrar ruido.
• Use cola de revisión solo en zona gris (aprobar / revisar / rechazar).
• Mida chargeback rate y pérdida por seller segmentado, no solo global.

También conviene cruzar con cómo reducir chargebacks en pasarelas si usted agrega comercios o opera split payments.

7. Preguntas frecuentes

¿Puedo usar la misma API para comprador y vendedor?
Sí. Diseñe eventos distintos y políticas por tipo de actor; Shield devuelve score y decisión por evaluación.

¿Sirve si ya uso un PSP externo?
Sí. Shield no sustituye el cobro: añade prevención de fraude sobre los eventos que usted controla en su plataforma.

¿Cómo empiezo?
Únase a la lista de espera de Shield API e indique que opera un marketplace o agregador.