Lo esencial
- Hay dos capas: prevención pre-lanzamiento (sobre las reglas) y detección transaccional (sobre las operaciones en tiempo real).
- MateGuard vive en la primera: simula el ataque a tus reglas antes de publicar y estima el leakage en USD.
- Sift, Forter y SEON viven en la segunda: evalúan usuarios y transacciones cuando la campaña ya está corriendo.
- No compiten: se complementan. Lo barato es cerrar el hueco en el diseño; lo caro es descubrirlo en la conciliación de fin de mes.
El punto de partida: "prevenir el fraude promocional" no es un solo problema. Es dos. Uno es de diseño —¿las reglas de mi promo se pueden explotar?— y se resuelve antes de lanzar. El otro es de ejecución —¿esta transacción concreta es abusiva?— y se resuelve en tiempo real. Ninguna herramienta hace bien las dos cosas, porque son momentos y datos distintos.
Las dos capas, lado a lado
| Pre-lanzamiento (testing adversarial) | Transaccional (runtime) | |
|---|---|---|
| Ejemplos | MateGuard | Sift, Forter, SEON |
| Cuándo actúa | Antes de publicar la campaña | Mientras la campaña está viva |
| Sobre qué opera | Las reglas de la promoción | Usuarios y transacciones individuales |
| Qué responde | "¿Cómo van a romper estas reglas y cuánto voy a perder?" | "¿Esta operación puntual es fraude?" |
| Entregable típico | Vectores, leakage en USD, parches de T&C y SQL de monitoreo | Score de riesgo por evento, bloqueo o revisión |
| Momento del ciclo | Diseño | Operación |
La categoría de fraude transaccional está madura y es excelente en lo suyo: puntuar operaciones en vivo. Pero por definición actúa después de que la promo salió, cuando el diseño ya está congelado. Si una regla es explotable, la plataforma transaccional te ayuda a mitigar el sangrado, no a evitarlo desde el origen.
Qué hace MateGuard (y qué no)
MateGuard corre un test adversarial de las reglas de una campaña antes del lanzamiento. Usa una arquitectura Maker-Checker: una IA atacante simula perfiles abusadores que intentan explotar la promo, y una IA juez (LLM-as-judge) evalúa cada vector, estima el impacto económico y prioriza las correcciones. El enfoque está motivado por la literatura de reward hacking en modelos de lenguaje.
Lo que no hace, y conviene decirlo claro: MateGuard no evalúa transacciones en tiempo real, no reemplaza device fingerprinting ni un motor de scoring en producción, y no es una herramienta de fraude de pagos. Es el checkpoint de riesgo del diseño de la campaña.
La alternativa más barata: revisión manual
Antes de comparar productos, la alternativa por defecto de casi todos los equipos es "lo revisamos entre nosotros". Es válida y gratis, pero tiene dos límites conocidos: depende de que una persona anticipe todos los vectores (los cuatro clásicos y sus combinaciones), y no cuantifica la pérdida en dólares, así que no podés priorizar ni justificar el riesgo ante finanzas. Una checklist fija —como la nuestra de referidos— reduce el sesgo, pero sigue siendo estática frente a un atacante creativo.
Cómo elegir (o combinar)
- Lanzás promos de cashback o referidos recurrentes: sumá una capa pre-lanzamiento para no rediseñar bajo fuego cada vez.
- Ya tenés fraude transaccional: MateGuard lo complementa entregándote el SQL de monitoreo que alimenta tus alertas y reduce el volumen que tu motor runtime tiene que frenar.
- Todavía no tenés nada: empezá por el diseño. Cerrar huecos antes de lanzar es el dólar mejor invertido; el abuso que evitás no necesita ser detectado después.
Probá la capa pre-lanzamiento en tu próxima campaña
Describí tu promo y MateGuard te devuelve los vectores, el leakage en USD y el SQL de monitoreo. Convive con la herramienta de fraude transaccional que ya uses.
Analizar una campaña gratis →