contacto@duriva.com
+52 (55) 8852 7509

El banco invoca contraseña, token y equipo: por qué no prueba autorización por sí solo

El banco invoca contraseña, token y equipo: por qué no prueba autorización por sí solo


Que el banco afirme que se utilizaron tu contraseña, token y equipo no demuestra por sí solo que autorizaste personalmente la operación. Esos elementos pueden describir una autenticación registrada, pero deben revisarse junto con dispositivo, sesión, beneficiarios, alertas, ubicación aproximada y circunstancias del acceso.

el banco dice que usaron mi contraseña token y equipo

Pregunta qué significa equipo: identificador, navegador, modelo o dispositivo físico. Revisa alta de token, recuperación de contraseña, beneficiarios y cambios de seguridad. Una contraseña puede ser robada y un código puede haberse entregado por engaño o generado bajo control remoto, por lo que la autenticación no equivale automáticamente a consentimiento.

En casos reales de transferencias no reconocidas, el banco ha señalado contraseña, token y equipo como si esos tres datos cerraran la investigación. Al revisar altas y sesiones, el teléfono registrado podía tener el mismo modelo del titular y ser otro objeto dado de alta recientemente. El identificador correcto no equivalía al dispositivo físico conocido ni al consentimiento de su dueño.

La secuencia previa puede incluir phishing, recuperación de contraseña, beneficiario nuevo o cambios de límites. Una contraseña puede robarse, un token entregarse mediante engaño y un equipo registrarse después de otro compromiso. Los registros completos permiten explicar esas posibilidades sin negar que los eventos de autenticación ocurrieron.

Conserva teléfonos, correos y notificaciones sin formatear, y solicita por reclamación fecha, sesión, dispositivo, método de alta, IP, beneficiarios y alertas. El abogado formula las peticiones; el peritaje contrasta cronología y controles sin prometer devolución ni identidad inmediata. La defensa se fortalece con preguntas concretas, no con repetir la tríada bancaria como si fuera una confesión ni con afirmar que todo acceso autenticado es falso.

Una contraseña correcta puede haber sido robada. Un token puede haber sido entregado mediante engaño o generado en un ambiente comprometido. Un equipo registrado puede haber sido dado de alta después de otro fraude. La conclusión exige registros completos.

Solicita el detalle técnico

Pide la fecha y hora de cada operación, identificador de sesión, dispositivo, método de alta, autenticación, IP y registros relacionados mediante los canales de reclamación. Solicita también cuándo se agregó el beneficiario y qué alertas se enviaron.

Conserva la respuesta del banco donde utiliza esas tres palabras como explicación. No discutas solo con atención telefónica: busca que la postura y los datos queden documentados.

Entrega una cronología de lo que ocurrió, incluyendo llamadas, enlaces, pérdida del teléfono, cambios de SIM, acceso remoto o cualquier evento previo. No omitas hechos incómodos: pueden explicar técnicamente la vulneración.

Revisa tu equipo sin borrar evidencia

Conserva teléfonos y computadoras utilizados, mensajes, correos, notificaciones y aplicaciones instaladas. No formatees ni ejecutes limpiadores antes de preservar. Un análisis puede buscar phishing, malware, perfiles, accesibilidad o sesiones remotas según el caso.

Cambia contraseñas desde un equipo confiable y reporta nuevas operaciones. Si el banco ya bloqueó accesos, sigue sus indicaciones sin instalar herramientas sugeridas por desconocidos.

Si compartiste un código, documéntalo. Compartir bajo engaño no convierte automáticamente toda operación en voluntaria ni elimina la necesidad de revisar controles bancarios.

Qué significa mi equipo

Pregunta si se refiere a un identificador previamente registrado, un modelo coincidente, una huella de navegador o un dispositivo nuevo enrolado. Esas afirmaciones no son equivalentes. El nombre iPhone o Windows en un registro no identifica de manera única un objeto físico.

También debe revisarse si hubo restablecimiento de contraseña, cambio de SIM o alta del token antes del cargo. La secuencia puede mostrar que la supuesta validación fue consecuencia de una vulneración previa.

Un perito puede contrastar los registros bancarios con tus dispositivos y comunicaciones. La responsabilidad económica será valorada por los procedimientos correspondientes, no por una etiqueta técnica aislada.

Impugna con preguntas concretas

En lugar de decir únicamente no fui yo, pregunta qué evidencia vincula el acceso contigo, qué medidas de seguridad se aplicaron y por qué no se detuvo una operación atípica si existían alertas. Las preguntas deben adaptarse al expediente, no acusar sin fundamento.

Conserva estados de cuenta, reportes, folios, resoluciones y comprobantes de tus reclamaciones. La devolución no puede garantizarse, pero una revisión sólida necesita más que la repetición de contraseña, token y equipo.

Autenticación registrada no equivale necesariamente a consentimiento

Una operación con contraseña y token correctos o cargo desde equipo reconocido puede derivar de phishing, acceso remoto, SIM swap o enrolamiento previo fraudulento. Hay que preguntar qué significa equipo: identificador, navegador, modelo o dispositivo físico. El titular necesita preservar equipos y contar con precisión qué códigos compartió; el abogado necesita logs de alta, sesión, beneficiario y alertas. El peritaje busca inconsistencias sin prometer devolución ni considerar una etiqueta técnica como confesión.

Preguntas frecuentes


Solicita registros de dispositivo, sesión, alta de token, cambios de seguridad, beneficiario y operación. Después compara con tus equipos y comunicaciones para determinar cómo pudo producirse una autenticación sin tu consentimiento.


Con logs bancarios, alertas, teléfono, correo, registros de SIM, aplicaciones remotas, dispositivos y cronología de phishing. Cada elemento debe interpretarse dentro de la secuencia completa.


Las claves correctas acreditan un evento de autenticación, no necesariamente tu consentimiento ni identidad física. Deben analizarse origen y contexto.


Sesiones, dispositivos, altas, cambios de seguridad, beneficiarios, alertas, IP, fechas y operaciones. Su utilidad depende de la secuencia completa.


Documenta exactamente lo ocurrido. No mientas ni firmes una versión simplificada; el engaño y los controles aplicados también importan.


No. Puede identificar inconsistencias y aportar evidencia técnica; la decisión depende de la investigación y el marco aplicable.


Conserva la resolución, solicita los registros pertinentes y consulta los mecanismos de revisión o impugnación con asesoría especializada.


Para cerrar

Una autenticación correcta no es una confesión. Exige los registros, revisa tus dispositivos y demuestra la secuencia que permitió llegar a esa contraseña, token o equipo.

En Duriva podemos analizar los eventos y documentar las inconsistencias técnicas para sustentar tu reclamación con evidencia en lugar de frases genéricas.

Jocsan Laguna
Director de Duriva y presidente del ACCCF