1.- La teoría : qué "corno" debo analizar

1.1 Device fingerpriting

Si alguien me preguntará "¿Qué parámetro determina una actividad sospechosa?", sin duda alguna diria el dispositivo. . Con base en mi experencia como Incident Response en uno de los Bancos Digitaltes (BIG Fintech) más grandes de Estados Unidos, un alto porcentaje de detección, Account Take over, se realizó con base en el dispositivo no conocido.

Qué es un "fingerprint" ?

Un device fingerprint, es un identificado derivado de características del entorno desde el que se conecta el usuario. No es una cookie, es hash construido a partir de atributos que el navegador o la app exponen:

Combinados, esos atributos producen un identificador razonablemente estable y difícil de falsificar por completo.

Las tres preguntas que se le hacen al device

1. ¿Es nuevo para este usuario? Señal moderada por sí sola (mucha gente cambia de

teléfono), fuerte en combinación.

1. ¿Es coherente con el historial? Un salto de Android a Windows desktop, o un

fingerprint de emulador o de navegador headless, indica automatización.

1. ¿Cuántas cuentas distintas opera? Esta es la pregunta cara. Un dispositivo que toca

veinte cuentas no es un usuario con muchas cuentas: es un operador.

Esa tercera pregunta no se puede responder mirando el perfil de un usuario. Requiere mirar todas las cuentas a la vez y es la base del análisis de redes de la sección 1.8.

La limitación

El fingerprinting es una carrera armamentista. Los operadores de fraude pasaron de scripts HTTP simples a instancias reales de Chromium que rotan fingerprints entre sesiones. Un fingerprint de calidad se compra a un proveedor especializado (Fingerprint, Seon, Sift) o se construye con un SDK propio; ninguna de las dos cosas es gratis, y ninguna es infalible. Por eso la señal se combina, no se usa sola.

1.2 IP y red: la señal más sobrevalorada

La IP es lo primero que todo el mundo mira y lo que menos discrimina por sí solo. Lo que se analiza:

Por qué la IP sola no alcanza: los ataques modernos de credential stuffing distribuyen las peticiones entre miles de IPs residenciales justamente para mantenerse por debajo de cualquier umbral de velocity y parecer tráfico normal. Bloquear por IP en ese escenario es jugar al topo.

El valor de la IP está en el cruce: IP nueva
0
device nuevo
1
país inusual es un caso; IP nueva sola es un martes cualquiera.

1.3 Geolocalización: física aplicada al fraude

Acá la señal cambia de naturaleza. Las anteriores son estadísticas "es raro", esta es determinística: "es imposible".

Impossible travel

Se toman dos eventos consecutivos del mismo usuario, se calcula la distancia entre sus coordenadas con la fórmula de haversine (distancia sobre la superficie de una esfera) y se divide por el tiempo transcurrido. Si la velocidad implícita supera la de un vuelo comercial unos 900 km/h no hay explicación benigna posible.

No es "raro". Es que una persona no puede estar en dos lugares a la vez, y por eso esta señal se pondera casi como certeza.

El cruce de direcciones

Este es un análisis que se hace poco y rinde mucho. Una fintech tiene varias direcciones asociadas a la misma operación, y su coherencia entre sí es la señal:

• La dirección declarada por el cliente en el onboarding.
• La ubicación inferida de la IP (geo-IP).
• La dirección de facturación del instrumento de pago.
• La dirección de envío, si hay entrega física.
• El país del documento de identidad y el del teléfono.

Cada divergencia es una señal de baja intensidad; varias juntas dibujan un caso. Que la IP esté en un país distinto al del documento pasa todos los días (gente que viaja). Que la dirección de envío no coincida con la de facturación, y que la IP esté en un tercer país, y que la cuenta se haya creado hace seis días, es otra cosa. Y el cruce entre cuentas es aún más fuerte: quince cuentas distintas que declaran la misma dirección de envío es uno de los indicadores más limpios de red de mulas que existe.

1.4 User-agent: coherencia, no identidad

El user-agent es trivialmente falsificable, así que como identificador no vale nada. Como test de coherencia, sí:

• ¿El UA declara iPhone y el fingerprint dice GPU de escritorio? Contradicción.
• ¿El UA es de un navegador headless o de una librería HTTP? Automatización.
• ¿Cambió de móvil a desktop en la misma sesión? Sesión secuestrada o herramienta.

La regla general: el UA nunca prueba nada por sí mismo, pero su contradicción con otra señal sí prueba algo.

1.5 Monto y comportamiento transaccional

La pregunta central no es "¿el monto es alto?" sino "¿es alto para esta persona?". Un pago de 8.000 dólares es rutina para un importador y una emergencia para un estudiante.

Lo que se analiza:

• Z-score del monto contra el historial propio del usuario: cuántas desviaciones estándar

se aparta de su media.

• Escalada: pagos crecientes en minutos. Es el atacante probando dónde está el límite.
• Velocity de montos: la suma acumulada en una ventana, no cada operación aislada.
• Structuring: montos deliberadamente por debajo del umbral de reporte regulatorio. Diez

operaciones de 9.900 cuando el umbral es 10.000 no es una coincidencia.

• Montos redondos atípicos para el patrón del usuario.

1.6 Velocity: la dimensión temporal

Velocity es cuántas veces ocurre algo en una ventana de tiempo. Es la familia de reglas que frena bots, scripts y operaciones automatizadas — y **en Bolivia el ROMS del BCB la exige explícitamente**, junto con montos límite, dispositivo de confianza y ubicación geográfica.

Se mide sobre casi cualquier eje: logins por minuto, transacciones por hora, fallos de autenticación consecutivos (la firma del credential stuffing), dispositivos distintos por cuenta, cuentas distintas por dispositivo.

Su virtud práctica: no necesita campos opcionales. Solo timestamp y tipo de evento, que están siempre. Es la familia que sigue produciendo señal cuando el export del cliente es pobre.

1.7 Secuencias: la coreografía del ATO

Las señales anteriores miran eventos. Esta mira el orden entre ellos, y es donde aparecen los patrones que ninguna regla aislada ve, porque cada paso por separado es legítimo:

Login desde un dispositivo nuevo → cambio de contraseña → cambio de email → desactivación de notificaciones → transferencia.

Ninguna de esas cinco operaciones es sospechosa. La secuencia completa, en veinte minutos, es un account takeover de manual. La lógica del atacante es explícita: primero bloquea al dueño —cambia credenciales, apaga las alertas para que no le llegue el aviso y recién después mueve el dinero, en el caso de tener herramienta para análisis de llamadas a Endpoints o APIs, ayudá a mapear el ataque

Por eso el par "cambio de credencial seguido de movimiento de fondos" es uno de los patrones de mayor severidad del catálogo.

1.8 Análisis de redes: el cruce entre cuentas

Todo lo anterior evalúa una cuenta contra su propio pasado. Este análisis pregunta otra cosa: ¿qué cuentas están conectadas entre sí? Se construye un grafo donde los nodos son las cuentas y existe una arista si comparten algún atributo: un dispositivo, una IP, una dirección de envío, un teléfono, una cuenta destino, un instrumento de pago. Después se buscan los componentes conexos grupos de cuentas alcanzables entre sí.

Una cuenta aislada con actividad rara es un caso. Un componente de once cuentas unidas por dos dispositivos es una operación, y se trata distinto: no se bloquea una transacción, se congela un conjunto y se reporta.

Este es el análisis que más difícil resulta de hacer a mano y el que más se beneficia de la automatización: nadie encuentra un componente conexo de once nodos leyendo un Excel.

1.9 Cómo se combinan las señales (y el error de sumarlas)

Con las señales sobre la mesa hay que producir una decisión. Y acá está el error más común de los sistemas de reglas caseros: sumar los puntos de cada regla.

Sumar tiene dos defectos graves:

1. Satura con ruido. Tres señales débiles y correlacionadas —device nuevo, IP nueva, UA

nuevo, que en la práctica son el mismo hecho: la persona se compró un teléfono— suman lo mismo que un impossible travel. El sistema bloquea a un cliente legítimo.

1. Exige acumulación para lo evidente. Una señal casi-certera debería decidir sola, sin

necesidad de que otras cuatro la acompañen.

El enfoque correcto es noisy-OR: cada señal reduce multiplicativamente la probabilidad de que el evento sea legítimo. Las señales se acumulan con rendimientos decrecientes, y una señal fuerte domina por sí sola.

2.- De la teoría al motor

La teoría dijo que la anomalía es relativa a la persona. Eso exige estado por usuario:

código
```python
class UserProfile(BaseModel):
    user_id: str

    known_devices: set[str]          # ¿este device es nuevo PARA ÉL?
    known_ips: set[str]
    known_countries: set[str]
    known_user_agents: set[str]

    amount_stats: RunningStats       # media y desviación incrementales
    typical_hours: dict[int, int]    # histograma de horas habituales

    event_count: int
    last_event: LastEventReference | None   # para impossible travel
    recent_events: list[RecentEvent]        # ventana para velocity y secuencias

Cada familia teórica se convirtió en una clase con un peso, una razón legible y su evidencia. Este es el estado real, señal por señal:

Instalación

Como siempre, te recomiendo utilizar venv o el que más te guste a vos, la idea es no corromper el interprete principal

Ahora existe una estructura que se debe respetar del csv

El archivo *.yaml, es fundamental ya que permite mapear la estructura a utilizar para el análisis

La herramienta recibe el contenido de las transacciones con base en el archivo "yaml" y genera un análisis y reporte de los hallazgos:

Puede hacer un análisis en tiempo real del archivo en cuestion:

1. Se inicializa el motor de análisis
2. Utilizando feed_live, los datos a ser analizados, mas la estructura de los datos a verificar
3. Detectó 2 transacciones con diferencia de horas, minutos desde 2 ubicaciones diferentes
4. Identifico 34 transacciones un tiempo corto
5. Con base en el flujo, actualización de credenciales, dispostivios nuevos, transferencia inmediata, se detecto Account Take Over

Y dónde entra el machine learning

Nada de esto es un argumento contra el ML. Es un argumento sobre el orden. Después de unos meses de operación tenés el dataset que hacía falta. Ahí el ML entra donde aporta de verdad: capturar patrones que nadie codificó y ajustar los pesos que hoy son juicio experto. Pero entra sobre un sistema que ya funciona.

El error no es usar ML. El error es esperar a poder usarlo.

El motor corre offline sobre un export CSV, sin credenciales ni acceso a producción. El mismo núcleo alimenta la auditoría batch y el servicio en vivo: lo que se valida en el reporte es, byte por byte, lo que corre después en producción.