Casos de Uso
Cómo se ve el éxito, en tres fragmentos de tráfico de producción real.
Las cifras de nuestra sección de resultados — una reducción mediana de chargebacks de aproximadamente el 47 %, una tasa de falsos positivos inferior al medio por ciento, la verificación respondiendo en unos pocos milisegundos — provienen de integraciones como las siguientes. Los casos aquí son composiciones anonimizadas; los patrones son reales.
Marketplaces
El problema: anillos de cuentas falsas que crean decenas de cuentas para hacer review-bombing, manipular rankings de vendedores o abusar de promociones de bono de bienvenida.
La señal: doce cuentas creadas en dos horas, todas desde diferentes conexiones — pero con señales del navegador y de manipulación que apuntan a un mismo clúster automatizado.
Cómo se acumula la señal
Un solo registro desde una conexión doméstica en un navegador real no tiene nada de particular. Doce registros desde doce conexiones domésticas diferentes, en lo que parece ser el mismo navegador automatizado con la misma firma de manipulación, es un anillo de cuentas falsas.
Las categorías que disparan juntas aquí:
- Automatización y bots (01) — firmas de navegador headless en cada cuenta.
- Manipulación de fingerprint (02) — tests de renderizado que no coinciden con la versión del navegador declarada.
- Abuso de infraestructura (03) — proxies residenciales vendidos por un operador de fraude conocido.
- Anomalías de comportamiento (06) — formularios de registro rellenados con patrones idénticos y el mismo timing.
Ninguna categoría individual marcaría el anillo. La puntuación de riesgo combinada sí.
La política
El marketplace bloquea en el nivel superior — el anillo, no los clientes — y pasa a la verificación por teléfono cuando el riesgo es alto y la confianza es sólida. Todo lo demás fluye sin cambios. En la práctica, toda la política es unas pocas líneas de código que leen el nivel de riesgo que devuelve Noxtica.
El resultado
Los registros falsos caen aproximadamente un 70 % en el mes posterior a la integración. La conversión de registro de los clientes reales no cambia.
Servicios Financieros
El problema: fraude con tarjeta no presente, especialmente ataques de apropiación de cuentas donde el atacante tiene los datos de la tarjeta pero no los dispositivos conocidos del titular.
La señal: una sesión cuyo perfil no coincide con los dispositivos conocidos del titular de la tarjeta. La respuesta es una verificación de paso adicional, no un bloqueo directo. Los clientes reales no sienten fricción; los anillos de fraude ven una comprobación extra en cada transacción.
Cómo se acumula la señal
El fraude con tarjeta no presente usa cada vez más datos de tarjeta reales y robados en dispositivos controlados por el atacante. El dispositivo es el diferenciador. Mantenemos un perfil por cliente; cuando llega una transacción desde un perfil que no hemos visto para ese cliente, lo marcamos.
Las categorías que disparan juntas aquí:
- Comprobaciones de hardware (05) — el dispositivo nuevo puede tener una firma diferente de gráficos, audio o memoria.
- Abuso de infraestructura (03) — los anillos de fraude a menudo operan desde rutas de centro de datos incluso cuando usan proxies residenciales en el frente.
- Anomalías de comportamiento (06) — timing de pago que no coincide con el historial del titular.
La señal de dispositivo nuevo por sí sola no es maliciosa — los clientes compran teléfonos, cambian portátiles, reinstalan sistemas operativos. La ponderamos contra las otras categorías para separar “cliente en un dispositivo nuevo” de “atacante con datos de tarjeta robados”.
La política
Un cliente que regresa en un dispositivo conocido, por debajo del nivel superior, fluye directamente sin fricción. Cuando el riesgo es alto — o aparece un dispositivo nuevo en una transacción inusualmente grande — la sesión recibe una verificación de paso adicional en lugar de un bloqueo directo. El sesgo es siempre hacia dejar que los clientes reales completen la compra.
El resultado
Las pérdidas por chargebacks caen aproximadamente entre un 45 y un 50 % en tres meses. La verificación de paso adicional la ven solo una pequeña fracción de las transacciones, y la gran mayoría de ellas se completan con éxito — clientes reales pasando la comprobación.
Plataformas Sensibles a la Identidad
El problema: las plataformas sin contraseña y de inicio de sesión único necesitan confirmar que la entidad que hace clic en un enlace de inicio de sesión es la misma que lo solicitó. Los kits de phishing y los servicios de relay de enlaces rompen esa suposición.
La señal: un enlace clicado desde un perfil diferente al que lo solicitó activa un paso de verificación adicional. Los kits de phishing y los servicios de relay de enlaces quedan atrapados en esta barrera.
Cómo se acumula la señal
Cuando se solicita un enlace de inicio de sesión, registramos el perfil solicitante. Cuando se hace clic en el enlace, volvemos a comprobar el perfil y comparamos. Si coinciden — mismo navegador, mismo dispositivo — el enlace autentica automáticamente. Si no, tratamos el clic como una sesión diferente y requerimos un paso de verificación adicional.
Las categorías que disparan juntas aquí:
- Manipulación de fingerprint (02) — los kits de phishing a menudo usan navegadores headless cuyo perfil no coincide con el dispositivo real del usuario.
- Anomalías de comportamiento (06) — el tiempo entre la solicitud y el clic, el origen del tráfico y cómo cambia la sesión son señales relevantes.
- Abuso de infraestructura (03) — los servicios de relay de enlaces normalmente operan desde infraestructura en la nube.
La política
Si el dispositivo que hace clic coincide con el que solicitó el enlace, el enlace de inicio de sesión funciona automáticamente. Si no, la plataforma requiere un segundo factor antes de dejar pasar la sesión. La comprobación de coincidencia es una comparación simple contra el perfil registrado cuando se emitió el enlace.
El resultado
El éxito del phishing contra campañas de enlace de inicio de sesión cae drásticamente — típicamente una reducción superior al 90 % en ataques de relay de credenciales exitosos. Los usuarios reales que legítimamente cambian de dispositivo ven un paso de verificación adicional y luego se añaden a la lista de dispositivos de confianza para futuros enlaces.
Patrón: Cuándo Bloquear, Cuándo Desafiar
En los tres casos de uso, la estructura de la política es la misma:
- Riesgo crítico — bloquear con registro. Estas sesiones no valen el costo de un desafío.
- Riesgo alto — desafiar: verificación de paso adicional, un segundo factor o revisión manual. Los clientes reales lo pasan; los bots no.
- Riesgo medio — observar. Registra la sesión y ponla en el panel, pero sin añadir fricción.
- Riesgo bajo o mínimo — permitir. La gran mayoría del tráfico.
Estas cuatro acciones se mapean al modelo de riesgo de cinco niveles: los dos niveles más bajos colapsan en “permitir” para casi todos, pero mantenerlos separados es útil en el panel para entender dónde se sitúa tu población.
Lecturas relacionadas
- Categorías de amenazas — detalle sobre cada una de las seis categorías que estos casos de uso referencian.
- Por qué calibración, no veredictos — por qué la política es tuya, no nuestra.
- Principios de ingeniería — las restricciones operativas detrás de los valores por defecto.