Cuando un banco utiliza capturas de pantalla para afirmar que autorizaste una operación, no necesitas demostrar inmediatamente que son falsas. Necesitas revisar qué permiten comprobar y qué no.
Una captura puede mostrar información real. El problema es que no identifica por sí sola el sistema original, la integridad de los registros ni la forma en que fueron obtenidos.
La defensa comienza con preguntas técnicas, no con una acusación de mentira.
Lo que una captura no demuestra por sí sola
Una imagen de registros no responde necesariamente:
Pregunta de qué servidor salieron los datos y si la base estaba completa cuando se capturó la pantalla. Una imagen puede incluir filtros, selección o campos omitidos que cambian el sentido de la operación, sin que el observador pueda saberlo. También debe identificarse quién administra el sistema y qué posibilidad existe de modificar o exportar registros sin dejar traza.
Después revisa fechas, zonas horarias y la relación entre registro y autorización. Una captura puede mostrar que una contraseña fue aceptada, pero no demostrar quién la introdujo ni si el dispositivo ya estaba bajo control de otra persona. La autenticación es un evento técnico; la autoría y el consentimiento requieren más elementos.
En una revisión bancaria real, la institución ofreció mostrar en un escritorio la información con la que pretendía sustentar su versión. La pantalla podía ser útil para orientarse, pero no identificaba por sí misma el servidor original, la ubicación de la base de datos ni el procedimiento con el que se habían obtenido los registros. Ver datos en un monitor no equivalía a revisar el sistema que supuestamente los produjo.
Esa diferencia cambió el objeto de la discusión. No se trataba de afirmar que la computadora era falsa, sino de saber si lo exhibido permitía comprobar las operaciones discutidas. La exportación, los campos, las fechas y la relación con otros registros eran necesarios para pasar de una demostración visual a una evidencia verificable.
Tu abogado puede solicitar constancia de qué se mostró, qué se negó y qué archivos faltan, sin pedir información ajena al caso. Como titular, conserva tus comprobantes y no confíes tu defensa a otra captura. El análisis pericial delimita qué afirmaciones pueden sostenerse con lo entregado y cuáles requieren acceso controlado a las fuentes originales.
Tu defensa debe pedir sistema, ubicación de la base, método de acceso y exportación, sin exigir datos de otros clientes. La objeción útil no es acusar a la institución de mentir por usar una computadora común, sino demostrar qué afirmaciones no pueden validarse con el material ofrecido y qué registros serían necesarios para resolverlas.
Mostrar información en una pantalla no equivale a poner el sistema original a disposición para revisión.
Solicita identificar el sistema, no solo la imagen
La inspección debe precisar:
- Nombre y función del sistema.
- Ubicación de la base de datos.
- Equipo o servidor donde se aloja.
- Procedimiento de acceso.
- Forma de exportación.
- Registros de administración y trazabilidad.
- Archivos nativos disponibles para revisión.
En una diligencia bancaria, se mostró un equipo de escritorio con registros de una base de datos y, al preguntar dónde estaba almacenada, no se precisó su ubicación. Lo exhibido no permitió validar que se tratara del sistema original.
La conclusión no fue “todo estaba fabricado”, sino que la exhibición no aportaba la trazabilidad necesaria para validarla.
Bitácoras impresas: el mismo problema en otro formato
Si las capturas fueron impresas, la dificultad aumenta. El papel no conserva metadatos, historial ni posibilidad de verificar alteraciones.
Solicita los archivos originales y revisa:
- Identificadores de sesión.
- Usuario y dispositivo.
- Dirección de red.
- Método de autenticación.
- Fechas y zona horaria.
- Factores de seguridad.
- Notificaciones al cuentahabiente.
- Altas de beneficiarios y cambios de límites.
- Registros anteriores y posteriores.
Una lista de operaciones no demuestra por sí sola quién las realizó.
Qué debe constar en una inspección
Cuando el banco permite una revisión, cada condición debe quedar documentada:
- Qué sistema y equipo fueron exhibidos.
- Qué acceso permitieron y cuál limitaron.
- Qué archivos fueron exportados.
- Quién participó en la extracción.
- Qué valores hash fueron calculados.
- Qué medios se utilizaron.
- Qué negativas o restricciones ocurrieron.
Si el banco no permite revisar los sistemas, esa negativa también debe quedar asentada. No la conviertas en una suposición: documéntala como un hecho dentro de la diligencia.
No conviertas las restricciones en una prueba automática de culpabilidad
Que el banco no permita ver algo no demuestra por sí solo que haya alterado registros. Pero sí limita lo que puede afirmar con esa evidencia.
La conclusión precisa puede ser que no existe base técnica suficiente para validar ciertas afirmaciones, no necesariamente que la institución falsificó documentos.
La diferencia importa. Una defensa sólida no necesita exagerar.
Qué puedes conservar por tu parte
Reúne tus propios elementos:
- Estados de cuenta.
- Comprobantes de operaciones.
- Notificaciones recibidas.
- Folios de reclamación.
- Evidencia de ubicación, si es pertinente.
- Dispositivos y registros disponibles.
- Contratos y métodos de autenticación pactados.
- Comunicaciones con el banco.
No alteres tus archivos originales y no dependas de una sola fuente.
La defensa se formula con preguntas verificables
Unas imágenes bancarias o capturas de sistemas pueden mostrar una interfaz sin acreditar el registro subyacente. Conviene pedir qué operación, campo y bitácora sostienen cada afirmación, y comparar fechas, dispositivos y referencias. El titular aporta su cronología; el abogado delimita la exhibición sin pedir datos ajenos innecesarios. El peritaje revisa consistencia y origen, no enseña a manipular pantallas ni presume alteración porque el banco utilice una computadora común.
