Resumen
Los litigios por fraude bancario digital suelen plantearse como una disputa binaria: la institución afirma que la operación fue autenticada y el cliente sostiene que no la realizó. Técnicamente, sin embargo, la autenticación de una sesión o la validación de un factor no equivale automáticamente a identificar de manera inequívoca a la persona que ejecutó el acto. Una pericia robusta debe reconstruir el evento como una cadena: identidad registrada, dispositivo, contexto de autenticación, sesión, transacción, controles antifraude, registros de red, eventos de seguridad y preservación de la evidencia. Este artículo propone un modelo técnico para ese análisis, discute los límites probatorios de IP, biometría y tokens y explica por qué la fuerza de la evidencia depende tanto del método de recolección y correlación como de la existencia de registros.
Palabras clave: fraude bancario; autenticación; pagos instantáneos; logs; evidencia digital; pericia.
1. El error de comenzar por la conclusión
En una controversia bancaria digital, la pregunta técnicamente útil rara vez es solo “¿la operación fue autenticada?”. Una respuesta positiva puede significar que se introdujo una contraseña correcta, que un OTP fue aceptado, que una sesión ya autenticada continuaba vigente, que un dispositivo registrado emitió una solicitud, que una biometría local liberó una clave criptográfica o que un flujo de recuperación de cuenta concedió nuevo acceso.
Estos eventos tienen distinto peso probatorio. Las Digital Identity Guidelines del NIST separan identidad, autenticación, autenticadores, gestión de credenciales y niveles de garantía.[1][2]
Por ello, la pericia debe evitar el razonamiento circular: “la operación fue autenticada, luego fue realizada por el titular”. Debe determinar qué mecanismo se utilizó, cómo fue vinculado a la cuenta, qué amenazas resiste, qué eventos precedieron a la operación y si la traza técnica es coherente con las hipótesis en conflicto.
2. La transacción como secuencia de eventos
Una reconstrucción útil puede dividirse en siete capas:
Identidad y registro:
cómo se creó la cuenta y qué datos se validaron;
Dispositivo:
equipo, aplicación, versión e identificadores;
Autenticación:
factores exigidos y aceptados;
Sesión:
inicio, duración y cambios durante su vigencia;
Transacción:
importe, beneficiario, canal, hora e identificadores;
Controles de riesgo:
alertas, score antifraude, cambios de patrón, límites y bloqueos;
Respuesta posterior:
reclamación, notificaciones, bloqueos, devolución y preservación de registros.
Los sistemas modernos de pagos instantáneos y banca móvil suelen combinar sesiones autenticadas, gestión del ciclo de vida de autenticadores, vinculación de dispositivos, análisis de riesgo y autorización reforzada. Las directrices internacionales de identidad digital distinguen niveles de garantía y requisitos de gestión de autenticadores relevantes para la reconstrucción pericial.[3][4] Estos controles aportan contexto, pero no sustituyen la reconstrucción técnica del evento controvertido.
3. Registros que suelen ser relevantes
Dependiendo de la arquitectura, pueden importar:
identificador único de transacción;
timestamps, huso horario y precisión;
logs de login y autenticación;
alta o cambio de dispositivo;
reset de contraseña, PIN o credenciales;
activación/migración de token;
eventos biométricos cuando proceda;
versión de app y sistema operativo;
IP, puerto de origen y datos de red;
identificadores de sesión;
cambios de límites;
alta de beneficiario;
alertas antifraude;
notificaciones push, SMS y e-mail;
recuperación de cuenta;
auditoría de backend;
registros de soporte y reclamación;
metadatos de exportación/preservación.
Lo decisivo no es acumular datos, sino correlacionarlos temporal y lógicamente.
4. Autenticación no equivale a autoría
La autenticación demuestra que un mecanismo fue aceptado conforme a las reglas del sistema. La autoría humana exige una inferencia adicional.
NIST SP 800-63B-4, publicado en 2025, trata autenticadores, niveles de garantía y resistencia a amenazas actuales.[2] En 2026, W3C publicó WebAuthn Level 3, con credenciales de clave pública vinculadas a un relying party y pruebas criptográficas generadas por autenticadores.[5]
Esto mejora la seguridad y la calidad de los registros, pero una firma criptográfica demuestra participación de una credencial; la atribución humana depende de posesión, desbloqueo, compromiso, coacción, ingeniería social y gestión de la cuenta.
La pericia debe separar:
¿el sistema autenticó correctamente una credencial?
¿la evidencia permite atribuir el acto a la persona discutida y con qué grado de soporte?
5. Biometría: evidencia fuerte, no infalible
La comparación biométrica es probabilística y la arquitectura importa. En muchos móviles, la aplicación bancaria no recibe la huella o imagen facial; el sistema operativo verifica localmente y solo libera una operación criptográfica o informa éxito.
Preguntas relevantes:
modalidad biométrica;
lugar donde se realiza el matching;
almacenamiento del template;
fallback por PIN/contraseña;
cambios de biometría o dispositivo;
mecanismos de liveness;
operación liberada tras la verificación.
NIST actualizó en 2025 sus consideraciones sobre biometría, identidad y fraude.[1][2]
6. IP y ubicación: contexto, no identidad civil
En NAT y Carrier-Grade NAT, muchos abonados pueden compartir un mismo IPv4 público. Los RFC de IETF explican que la atribución puede requerir IP + puerto de origen + timestamp preciso, correlacionados con registros del proveedor.[6][7]
Incluso si se identifica correctamente a un abonado, eso no demuestra quién operaba el terminal. Redes compartidas, VPN, acceso remoto y dispositivos comprometidos deben considerarse.
La ubicación también depende de su fuente: GNSS/GPS, red móvil, Wi-Fi o geolocalización por IP tienen propiedades distintas de precisión.
7. Sistemas antifraude y comportamiento
Los sistemas modernos combinan señales de dispositivo, hora, geografía, velocidad transaccional, beneficiarios, límites y comportamiento de sesión.
En un litigio conviene conocer señales disponibles, controles activados, score generado, reglas aplicadas, desviaciones de perfil y auditabilidad de decisiones automáticas.
Un resultado “bajo riesgo” es una salida operativa, no prueba autónoma de autoría.
8. Integridad y cadena de custodia
Una traza rica pierde valor si no se demuestra su procedencia e integridad.
ISO/IEC 27037 ofrece directrices para identificación, recolección, adquisición y preservación de evidencia digital.[8] NIST SP 800-86 estructura recolección, examen, análisis y reporte.[9] ISO/IEC 27042 añade requisitos de documentación del análisis y la interpretación para evaluar validez, reproducibilidad y repetibilidad.[10]
Siempre que sea posible, deben conocerse sistema de origen, procedimiento de extracción, responsable, filtros, formatos, hashes, fecha/hora, transformaciones, retención del original y reproducibilidad.
9. Cómo formular el objeto pericial
En vez de preguntar simplemente “¿hubo fraude?”, resulta más útil preguntar:
¿qué mecanismos de autenticación se utilizaron?
¿hubo cambios de credencial o dispositivo antes del evento?
¿qué registros identifican sesión y dispositivo?
¿son coherentes los timestamps entre fuentes?
¿hubo nuevo beneficiario o cambio de límite?
¿qué alertas de riesgo se generaron?
¿pueden correlacionarse sesión, autenticación y transacción?
¿cómo se preservaron y extrajeron los logs?
¿qué conclusiones son técnicamente sostenibles y cuáles permanecen indeterminadas?
10. Conclusión
El fraude bancario digital no debe analizarse mediante un solo indicador. Contraseña correcta, biometría aceptada, token válido, IP conocida o dispositivo registrado son piezas de una reconstrucción, no conclusiones autosuficientes.
La fuerza probatoria surge de la correlación de fuentes independientes, la coherencia temporal, la comprensión de la arquitectura de autenticación y el tratamiento forense de los registros.
En controversias digitales, la pregunta decisiva suele ser menos “¿existe un log?” y más: ¿qué mide exactamente, cómo se produjo, con qué registros se correlaciona y hasta dónde puede interpretarse responsablemente?
10A. Actualización metodológica 2026
La reconstrucción pericial debe distinguir registro del dispositivo, autenticación de la sesión y autorización de la transacción. La cronología de alta, vinculación, recuperación y revinculación de autenticadores resulta especialmente relevante cuando aparece un dispositivo nuevo o modificado cerca del evento controvertido. La preservación también debe alcanzar el proceso analítico: ISO/IEC 27042:2015 enfatiza validez, reproducibilidad, repetibilidad y registro suficiente para escrutinio independiente.
Referencias
NIST.
SP 800-63-4: Digital Identity Guidelines
. 2025. https://csrc.nist.gov/pubs/sp/800/63/4/final
NIST.
SP 800-63B-4
. 2025. https://csrc.nist.gov/pubs/sp/800/63/b/4/final
NIST. SP 800-63-4: Digital Identity Guidelines. 2025. https://csrc.nist.gov/pubs/sp/800/63/4/final
NIST. SP 800-63B-4: Digital Identity Guidelines — Authentication and Authenticator Management. 2025. https://csrc.nist.gov/pubs/sp/800/63/b/4/final
W3C.
Web Authentication Level 3
. 2026. https://www.w3.org/TR/webauthn/
IETF.
RFC 6888
. https://www.rfc-editor.org/rfc/rfc6888
IETF.
RFC 6302
. https://www.rfc-editor.org/rfc/rfc6302
ISO/IEC.
ISO/IEC 27037:2012
. https://www.iso.org/standard/44381.html
NIST.
SP 800-86
. https://doi.org/10.6028/NIST.SP.800-86
ISO/IEC. ISO/IEC 27042:2015 — Guidelines for the analysis and interpretation of digital evidence. https://www.iso.org/standard/44406.html
ISO/IEC. ISO/IEC 27043:2015 — Incident investigation principles and processes. https://www.iso.org/standard/44407.html
Nota editorial: contenido técnico-informativo; un caso concreto exige examinar la arquitectura real, los registros originales y el objeto pericial delimitado.