Approach

Etapas del método, en orden

Fase 1

Revisión de eventos disponibles

Antes de hablar de modelos, revisamos qué señales ya emite la aplicación: tiempos entre pulsaciones al introducir importes, correcciones sobre un mismo campo, pausas antes de confirmar, secuencia de pantallas visitadas. No pedimos instrumentar nada nuevo si esos eventos ya existen. La conversación se centra en qué se puede leer sin tocar los flujos de autenticación ni el consentimiento vigente.
Fase 2

Definición del patrón de referencia

El sistema no compara contra una plantilla biométrica fija, sino contra la cadencia habitual de la misma sesión y el mismo dispositivo. En esta etapa acordamos la ventana temporal de referencia, qué operaciones entran en el análisis y cómo se tratan los cambios legítimos de dispositivo o de red. Es el momento de separar ruido de desviación real.
Fase 3

Integración como capa complementaria

La puntuación de riesgo se entrega a los sistemas antifraude ya desplegados. No sustituye la autenticación ni decide por sí sola: aporta un indicio más que el motor existente interpreta con sus propias reglas. La integración respeta los flujos de consentimiento y no almacena pulsaciones crudas más allá de lo estrictamente necesario para el cálculo.
Fase 4

Calibración de umbrales

Con datos de sesiones reales ajustamos los umbrales para equilibrar detección y fricción. Un cambio brusco en la cadencia de una transferencia junto con navegación errática hacia menús poco usados pesa distinto según el tipo de operación. Aquí se decide qué combinaciones activan una verificación adicional y cuáles solo se registran para revisión posterior.
Fase 5

Seguimiento y lectura conjunta

La capa no se entrega y se olvida. Revisamos periódicamente la tasa de falsos positivos, los casos que el equipo humano descartó y las variaciones estacionales en el comportamiento de los clientes. Ese seguimiento es lo que permite mantener la señal útil a lo largo del tiempo sin erosionar la confianza del usuario.

Cada fase puede detenerse si los indicios no justifican continuar. Preferimos decir esto antes de empezar que descubrirlo a mitad del proceso.

Preguntas que suelen aparecer antes de integrar señales de tecleo

¿Qué se observa exactamente mientras el cliente introduce una operación?

Se registran tiempos entre pulsaciones, duración de cada tecla, pausas al pasar de un campo a otro, correcciones antes de confirmar y la secuencia de pantallas visitadas. No se lee el contenido escrito ni el importe. La lectura se hace sobre la cadencia, no sobre los datos que el usuario introduce.

¿Se compara contra una plantilla biométrica fija del titular?

No. El patrón de referencia se construye con la propia sesión y el dispositivo en uso, y se contrasta con el comportamiento habitual reciente de esa misma cuenta. Así se evita depender de una huella rígida que cambia con el cansancio, el teclado o la versión de la app.

¿La capa decide por sí sola si una operación es fraudulenta?

No. Genera una puntuación de riesgo que los sistemas antifraude ya desplegados interpretan junto con el resto de señales. La decisión final de bloquear, pedir verificación adicional o dejar pasar sigue en manos de la entidad y de sus reglas existentes.

¿Se almacenan las pulsaciones en bruto?

Solo se conserva lo estrictamente necesario para calcular y comparar la señal durante la sesión. No se guardan secuencias de teclas ni se identifica a la persona fuera del contexto de esa operación concreta. El detalle de retención se acuerda con cada entidad según su marco normativo.

¿Cómo se integra sin rehacer los flujos de autenticación?

Trabaja sobre eventos que la aplicación ya emite al teclear y navegar. No sustituye la autenticación, no añade pasos obligatorios al cliente y respeta los consentimientos vigentes. La puesta en marcha se coordina con el equipo que mantiene la app para no alterar la experiencia actual.

¿Qué ocurre cuando la señal marca una sesión legítima?

Los falsos positivos existen y se gestionan con verificación escalonada, no con bloqueos automáticos. Antes de cualquier medida conviene revisar el contexto de la operación y el historial reciente. Puedes ver cómo lo abordamos en el artículo sobre falsos positivos y, si necesitas hablar del caso concreto de tu entidad, escribirnos desde la página de contacto.

Si tu equipo trabaja con requisitos de cumplimiento internos, revisa también nuestras condiciones en términos de uso y la política de tratamiento en política de privacidad.

Qué entra y qué no entra en el análisis conductual

Antes de hablar de señales, conviene fijar el terreno. Esta página describe cómo trabajamos, y esa descripción arrastra varias precisiones que suelen quedar en el aire: qué se mide, sobre qué base se compara, quién decide y qué queda fuera del alcance. Las reunimos aquí para evitar lecturas forzadas del método.

La comparación es intrasujeto, no contra un patrón universal Cada sesión se contrasta con el comportamiento previo del mismo usuario en el mismo dispositivo y contexto operativo. No existe una plantilla biométrica fija que alguien deba cumplir. Si el titular cambia de teléfono, teclea con una mano o escribe desde una red distinta, el sistema aprende ese nuevo punto de partida antes de emitir cualquier lectura. Esto explica por qué no identificamos personas fuera de la sesión: no hay una huella permanente contra la que cotejar, solo una referencia que se reconstruye con cada uso.
La puntuación de riesgo no es una decisión El análisis devuelve un valor que los sistemas antifraude ya desplegados interpretan según sus propias reglas. No bloquea operaciones, no autoriza transferencias y no sustituye la autenticación existente. Cuando la cadencia al introducir un importe se rompe o la navegación se vuelve errática hacia menús poco frecuentes, lo que entregamos es un indicio para que el motor de decisión del banco lo pondere junto al resto de señales. La responsabilidad de actuar sigue donde estaba.
No se almacenan pulsaciones crudas Los eventos de teclado y navegación se procesan en el momento y se resumen en métricas agregadas. No conservamos la secuencia de teclas ni el contenido de lo escrito, y no retenemos datos biométricos más allá de lo necesario para calcular la desviación. Tampoco se identifica al usuario fuera del contexto de la sesión: el análisis vive y muere con la operación que lo generó, sin construir un perfil paralelo.
La integración respeta los flujos ya existentes Trabajamos con eventos que la aplicación bancaria ya emite: foco en campos, tiempos entre pulsaciones, correcciones, desplazamientos y secuencia de pantallas. No pedimos acceso a contenidos, no interceptamos credenciales y no alteramos los mecanismos de consentimiento que el banco tenga establecidos. Si un flujo requiere autenticación adicional, esa decisión pertenece al banco y a su marco normativo, no a esta capa.
Los falsos positivos existen y se gestionan Ningún sistema conductual es perfecto. El cansancio, un cambio de dispositivo o una variación natural pueden marcar una sesión legítima como sospechosa. Por eso el resultado se plantea como una señal más dentro de una verificación escalonada, no como una alarma que corta el acceso. Medir esa tasa a lo largo del tiempo forma parte del trabajo, igual que ajustar los umbrales sin sacrificar la detección real.
Alcance limitado y explícito No vendemos vigilancia masiva, no operamos como único factor de decisión y no prometemos detección absoluta. Lo que ofrecemos es una lectura conductual complementaria, con límites definidos y verificables, que se apoya en lo que la aplicación ya registra. Cualquier expectativa por encima de ese marco queda fuera de lo que este método puede sostener.

Etapas del método, en orden

Revisión de eventos disponibles

Definición del patrón de referencia

Integración como capa complementaria

Calibración de umbrales

Seguimiento y lectura conjunta