Nunca he perdido un caso contra un banco.
Necesito que eso quede claro desde la primera línea porque lo que viene en este artículo requiere que entiendas de dónde habla quien lo escribe. No hablo desde la teoría. No hablo desde un artículo académico que leí en una revista jurídica. Hablo desde el laboratorio. Desde la audiencia. Desde la cara del abogado del banco cuando le presentan la evidencia que su cliente le aseguró que no existía.
Llevo 17 años haciendo informática forense. He formado a más de 1,300 peritos en 10 países. Mi laboratorio, Duriva, ha enfrentado a los cinco bancos más grandes de México en sede judicial. Y el resultado es el mismo en todos los casos: cuando hay evidencia digital correctamente analizada, documentada y presentada, el banco pierde.
Siempre.
No porque los bancos sean incompetentes. No porque sus abogados sean malos. No porque sus peritos no sepan lo que hacen. Sino porque la narrativa del banco se sostiene sobre una premisa que la evidencia digital destruye: que sus sistemas son infalibles. Y los sistemas no son infalibles. Ninguno lo es. Lo que pasa es que nadie los cuestiona.
Hasta que alguien lo hace.
Empresario PYME al que le vaciaron la cuenta y el banco le dijo «la operación fue realizada con sus credenciales, no hay anomalía en nuestros sistemas»: sé exactamente qué sentiste cuando leíste esa respuesta. Frustración. Impotencia. La sensación de que el sistema está diseñado para proteger al banco, no a ti. Y les soy franco: en muchos aspectos, así es. Pero no es invencible. Es derrotable. Con la evidencia correcta.
Víctima de fraude que ya fue a CONDUSEF y recibió la resolución genérica de siempre: sé que CONDUSEF no te sirvió. Sé por qué no te sirvió. Y sé lo que tienes que hacer ahora.
Abogado del empresario que está armando la estrategia: lo que necesitas no es un argumento jurídico más sofisticado. Lo que necesitas es un peritaje que convierta la experiencia del cliente en evidencia. Porque sin el peritaje, el caso es la palabra de tu cliente contra la infraestructura legal del banco. Y en esa pelea, tu cliente pierde. Pero con el peritaje, el caso es ciencia contra narrativa. Y la ciencia gana.
Juez que va a evaluar este tipo de caso: lo que va a leer aquí es lo que presentamos en audiencia. Es la estructura que ha resultado en sentencias favorables al usuario bancario en cada caso donde la hemos desplegado. No lo escribo para convencerlo. Lo escribo para que entienda la mecánica técnica antes de que llegue a su sala.
La presunción de infalibilidad bancaria: el muro que hay que derribar
Voy a explicar algo que no aparece en ningún código, en ninguna ley, en ningún reglamento, pero que opera como si fuera la norma más sólida del sistema financiero mexicano: la presunción de infalibilidad bancaria.
No es una presunción legal. Es una presunción fáctica. Es lo que ocurre cuando el banco dice «nuestros sistemas funcionaron correctamente» y todo el mundo — CONDUSEF, el juez de primera instancia, el abogado del usuario, a veces hasta el propio usuario — lo acepta como verdad sin cuestionarlo.
La mecánica es simple: el banco presenta los logs de la operación. Los logs dicen que la transferencia se ejecutó con el usuario correcto, la contraseña correcta, el token correcto, desde la IP registrada. El banco concluye: «No hay evidencia de vulneración a nuestros sistemas.» Y esa conclusión — que es cierta en su alcance limitado — se interpreta como: «El usuario autorizó la operación.»
Pero esa interpretación es un salto lógico que no resiste análisis.
Que los sistemas del banco hayan funcionado correctamente no significa que el usuario haya autorizado la operación. Significa que alguien usó las credenciales del usuario para ejecutar la operación. Y la pregunta que el banco no contesta — porque no le conviene contestar — es: ¿cómo obtuvo esas credenciales el tercero que las usó?
Esa pregunta es la que el peritaje contesta. Y cuando se contesta con evidencia, la presunción de infalibilidad se derrumba.
Digo, pensémoslo con sentido común. Si alguien roba las llaves de tu casa, entra a tu casa, y se lleva tus cosas, el hecho de que la cerradura funcionó correctamente no significa que tú autorizaste el robo. Significa que las llaves funcionaron. La pregunta es quién las tenía. Y la respuesta a esa pregunta no la tiene la cerradura. La tiene la investigación de cómo se robaron las llaves.
Eso es exactamente lo que pasa con las credenciales bancarias. Funcionaron correctamente. La pregunta es quién las tenía cuando funcionaron. Y esa pregunta requiere análisis forense, no lectura de logs.
La estructura del caso: del peritaje a la sentencia
Voy a explicar cómo se construye un caso contra un banco desde cero. No la teoría. El procedimiento real. Lo que hacemos en Duriva caso tras caso.
Fase uno: preservación inmediata de la evidencia
El día que detectas la operación no reconocida es el día más importante del caso. No mañana. No la próxima semana. Ese día.
La primera instrucción que doy a todo empresario que me contacta es: no toques nada. No reinicies el router. No formatees la computadora. No cambies contraseñas todavía. No llames al banco para «reclamar» — primero documenta.
La evidencia tiene ventana de vida. Los logs del router se sobreescriben. La memoria del navegador se borra cuando se cierra. El malware puede tener mecanismos de autodestrucción. Si la computadora se reinicia, ciertos artefactos volátiles desaparecen para siempre. Si el router se resetea, la configuración comprometida se borra y con ella la prueba de la intrusión.
He visto casos donde el empresario, en su desesperación comprensible, lo primero que hizo fue cambiar todas las contraseñas y formatear la computadora «por seguridad.» Esa acción, bien intencionada, destruyó la evidencia que habría ganado el juicio. El malware que demostró cómo se robaron las credenciales se borró. La configuración DNS alterada del router se reinició a valores de fábrica. Las huellas del atacante desaparecieron.
Preservar la evidencia es lo primero. Todo lo demás viene después.
Fase dos: auditoría forense integral
Cuando Duriva entra al caso, no asumimos nada. No asumimos que fue el banco. No asumimos que fue el usuario. No asumimos que fue un ataque externo. Auditamos todo.
La auditoría cubre cuatro capas:
Capa uno: el dispositivo del usuario. La computadora o el celular desde donde se accedía a la banca en línea. Buscamos malware bancario — troyanos específicamente diseñados para interceptar sesiones de banca en línea. Buscamos keyloggers — programas que registran cada tecla que se presiona, incluyendo usuarios y contraseñas. Buscamos man-in-the-browser — malware que modifica en tiempo real lo que el usuario ve en su pantalla mientras interactúa con la página del banco. Buscamos artefactos de navegación — historial, cookies, certificados SSL, advertencias de seguridad ignoradas.
Capa dos: la red del usuario. El router. La configuración DNS. Las tablas ARP. El firmware. Los dispositivos conectados. Los registros de tráfico si existen. Buscamos envenenamiento DNS — la alteración de los servidores de nombres para redirigir al usuario a páginas clonadas del banco. Buscamos dispositivos no autorizados en la red — alguien que se haya conectado al WiFi de la empresa sin autorización. Buscamos vulnerabilidades del router — firmware desactualizado, contraseñas de fábrica, administración remota habilitada.
Capa tres: los registros del banco. Estos se obtienen mediante solicitud judicial o como parte del procedimiento de CONDUSEF. Los logs del banco contienen información que el banco interpreta a su favor pero que, leída con conocimiento técnico, puede revelar anomalías: sesiones simultáneas desde distintas IPs, tiempos de sesión que no coinciden con el comportamiento normal del usuario, patrones de transacción atípicos que los propios sistemas de detección de fraude del banco deberían haber detectado.
A ver, a ver, a ver. Este punto es crucial: los bancos tienen sistemas de detección de fraude. Algoritmos que analizan patrones de transacción y que deberían alertar cuando una operación es atípica. Si el usuario normalmente hace transferencias de $50,000 y de repente aparece una transferencia de $3,000,000 a las tres de la mañana a una cuenta que nunca ha recibido depósitos desde esa cuenta — el sistema de detección de fraude debería haberla flaggeado. Si no la flaggeó, la pregunta es por qué no. Y esa pregunta apunta a la responsabilidad del banco, no del usuario.
Capa cuatro: la trazabilidad del dinero. ¿A dónde fue el dinero? ¿Qué cuentas lo recibieron? ¿Fueron cuentas abiertas recientemente con documentación falsa? ¿Fueron cuentas «mula» — cuentas creadas específicamente para recibir fondos de fraude y dispersarlos rápidamente? Si el banco permitió la apertura de cuentas receptoras con documentación insuficiente, eso también es responsabilidad del banco. El fraude no solo ocurre en la salida del dinero. Ocurre también en la llegada.
Fase tres: el dictamen pericial
Con la auditoría completa, Duriva emite el dictamen pericial. No es un informe genérico. Es un documento técnico-jurídico que se construye para un propósito específico: ser presentado ante un juez como prueba pericial.
El dictamen contiene:
- Identificación del perito con cédula profesional, certificaciones y currículum
- Antecedentes del caso con los hechos relevantes
- Metodología aplicada, paso a paso, herramienta por herramienta
- Hallazgos técnicos documentados con evidencia verificable
- Hashes SHA-256 de cada pieza de evidencia analizada
- Cadena de custodia completa sin huecos
- Conclusiones derivadas exclusivamente de los datos analizados
- Fundamentación legal bajo el artículo 210-A del Código Federal de Procedimientos Civiles
El dictamen no opina. Demuestra. No dice «probablemente fue un ataque.» Dice «la configuración DNS del router fue alterada para apuntar a servidores maliciosos identificados con IP X.X.X.X, los cuales están documentados en las bases de datos de amenazas como asociados a ataques de pharming financiero. La alteración ocurrió en la fecha aproximada Y, según el análisis de los logs disponibles. Las credenciales del usuario fueron capturadas a través de la página clonada alojada en el servidor Z, cuyo código fuente fue preservado y certifica que los datos ingresados se enviaban a un servidor controlado por los atacantes, no al servidor del banco.»
Eso no es una opinión. Es una reconstrucción forense documentada. Y frente a eso, «la operación se realizó con las credenciales correctas» no es una defensa. Es una descripción incompleta del problema.
Fase cuatro: la estrategia procesal
El peritaje es el arma. Pero un arma sin estrategia es solo un objeto. La estrategia procesal define dónde y cómo se usa el peritaje para obtener el resultado.
Hay dos caminos principales:
Camino uno: juicio mercantil o civil. Demanda contra el banco por incumplimiento de contrato de servicios bancarios, negligencia en la implementación de medidas de seguridad, y responsabilidad por las pérdidas derivadas del fraude. El peritaje es la prueba central. El artículo 210-A es el fundamento probatorio.
Camino dos: negociación forzada. Esto es lo que pasa en la mayoría de los casos que maneja Duriva, y necesito explicarlo porque es la realidad práctica que el empresario necesita conocer.
Cuando el banco recibe la notificación de la demanda y ve que la parte actora tiene un peritaje informático forense que demuestra la vulneración de la red del cliente, el envenenamiento DNS o el malware bancario, y la responsabilidad del banco por no detectar la operación atípica — el banco calcula. Los bancos son instituciones que calculan. Calculan el costo de perder el juicio versus el costo de negociar. Calculan el precedente que se crea si un juez emite una sentencia en su contra basada en un peritaje informático. Calculan el riesgo reputacional.
Y en la mayoría de los casos, ofrecen un convenio. No porque quieran. Porque les sale más barato que perder.
Reitero: los bancos no regalan dinero. Si ofrecen pagar, es porque su propia evaluación de riesgo les dice que la evidencia no está a su favor. Esa evaluación de riesgo cambia radicalmente cuando hay un peritaje forense de por medio. Sin peritaje, el banco calcula que va a ganar. Con peritaje, el banco calcula que puede perder. Y cuando calcula que puede perder, negocia.
El empresario que llega a la mesa de negociación con peritaje no llega pidiendo. Llega exigiendo. Y la diferencia entre pedir y exigir es la diferencia entre irse con el 30% y irse con el 100%.
Lo que el banco no quiere que sepas
Voy a revelar algo que he aprendido en 17 años de litigar contra bancos y que el sistema financiero preferiría que no dijera en un artículo público.
Los bancos conocen las vulnerabilidades. No son ingenuos. Saben que el phishing existe. Saben que el pharming existe. Saben que los routers de las PYMES tienen contraseñas de fábrica. Saben que el man-in-the-browser opera en México. Saben que sus tokens de segundo factor no son invulnerables. Saben todo esto porque lo documentan internamente, porque tienen equipos de ciberseguridad, porque participan en foros de la industria donde se discuten estas amenazas.
Y a pesar de saberlo, su respuesta estándar cuando un cliente es víctima de fraude sigue siendo la misma: «La operación se realizó con sus credenciales. No hay anomalía en nuestros sistemas.»
Esa respuesta no es ignorancia. Es estrategia. Porque si el banco admitiera que sabe que los routers de sus clientes son vulnerables, tendría la obligación de implementar medidas de seguridad adicionales — autenticación biométrica, verificación de dispositivo, detección de anomalías de red, geolocation de la sesión. Medidas que cuestan dinero. Es más barato culpar al usuario que protegerlo.
Los sistemas de detección de fraude existen pero no se aplican correctamente. Los bancos tienen algoritmos de detección de operaciones atípicas. Pero esos algoritmos tienen umbrales. Y esos umbrales están calibrados para minimizar las falsas alarmas — es decir, para no molestar al usuario con verificaciones adicionales cada vez que hace una transferencia. El problema es que al calibrar para minimizar falsas alarmas, también minimizan las alarmas reales. La transferencia fraudulenta por tres millones a las tres de la mañana pasa sin alarma porque el umbral está puesto en cinco millones. O porque el algoritmo mide monto pero no mide hora. O porque mide hora pero no mide destino.
El banco dice que sus sistemas son sofisticados. Y lo son. Pero sofisticados no significa eficaces. Un sistema sofisticado mal calibrado es un sistema que no protege.
El contrato de adhesión te perjudica. Cuando abriste tu cuenta, firmaste un contrato de servicios bancarios. Ese contrato tiene cláusulas que el banco redactó unilateralmente — es un contrato de adhesión, tú no negociaste los términos — y que incluyen cláusulas de limitación de responsabilidad que dicen algo como: «El banco no será responsable por operaciones realizadas con las credenciales del usuario.» Esas cláusulas existen. Son reales.
Pero también son cuestionables. Un contrato de adhesión con cláusulas abusivas puede ser impugnado judicialmente. Y una cláusula que exonera al banco de toda responsabilidad por fraude electrónico — independientemente de las circunstancias, independientemente de si el banco tenía medidas de seguridad adecuadas, independientemente de si el banco detectó y no actuó ante operaciones atípicas — es una cláusula que un juez puede declarar abusiva bajo los principios de equidad contractual y buena fe.
El peritaje forense es la pieza que transforma esta discusión jurídica en una discusión técnica. Porque no es lo mismo argumentar «la cláusula es abusiva en abstracto» que argumentar «la cláusula es abusiva porque el banco conocía la vulnerabilidad, no implementó medidas adecuadas, no detectó la operación atípica, y pretende exonerarse de responsabilidad trasladándola al usuario que fue víctima de un ataque que el banco podría haber prevenido.»
CONDUSEF: el paso que hay que dar pero que no hay que esperar
Voy a ser honesto sobre CONDUSEF porque el empresario necesita esta información antes de invertir tres meses esperando una resolución que no le va a resolver nada.
CONDUSEF es un organismo de mediación. No es un tribunal. No puede obligar al banco a pagar. Puede mediar entre las partes, puede emitir dictámenes técnicos, puede sancionar con multas administrativas. Pero no puede emitir una sentencia que ordene al banco devolver el dinero.
El proceso ante CONDUSEF es predecible: el banco presenta sus logs, CONDUSEF evalúa los logs, los logs dicen que la operación fue «correcta,» CONDUSEF concluye que no se acredita responsabilidad del banco. Es un círculo donde la única evidencia evaluada es la que el banco presenta.
CONDUSEF no tiene peritos informáticos forenses que auditen la red del cliente. No tiene laboratorio para analizar routers comprometidos. No tiene la capacidad técnica para evaluar si hubo envenenamiento DNS o man-in-the-browser. Evalúa lo que el banco le da. Y el banco le da lo que le conviene.
Dicho esto, el paso ante CONDUSEF tiene utilidad estratégica. Genera un expediente formal. Genera constancia de la reclamación del usuario. Y en algunos casos, durante el proceso de CONDUSEF, se obtiene información del banco — logs, registros, políticas de seguridad — que después puede usarse en el juicio.
Trata CONDUSEF como un paso en la estrategia, no como la estrategia misma.
Preguntas que el empresario tiene en la cabeza
¿Cuánto cuesta pelear contra un banco?
Depende de la complejidad del caso, del monto en juego y de la estructura de la demanda. Lo que puedo decirte es la matemática básica: si te robaron tres millones y el peritaje cuesta una fracción de eso, la decisión se hace sola. El costo de no pelear es el monto completo que perdiste. El costo de pelear es una inversión con probabilidad alta de retorno cuando la evidencia existe.
¿Cuánto tarda?
La vía judicial en México no es rápida. Un juicio mercantil puede tardar meses. A veces más de un año. Pero la negociación — que es lo que suele ocurrir cuando el banco ve el peritaje — puede resolverse en semanas. Los bancos prefieren negociar rápido a litigar largo. Cada día que el juicio está abierto es un día de riesgo de precedente judicial negativo para el banco.
¿Y si ya pasó tiempo y formateé todo?
Es más difícil, pero no necesariamente imposible. Los logs del banco se pueden obtener judicialmente. Los registros del proveedor de internet pueden contener información sobre la configuración histórica del router. Los registros de tráfico de red, si existían, pueden tener respaldos. Cada caso es diferente. Lo que no debes hacer es asumir que ya no se puede sin consultar con un perito. He encontrado evidencia en lugares donde el cliente ya había dado el caso por perdido.
¿Puede el banco tomar represalias si lo demando?
Los bancos están regulados por la Comisión Nacional Bancaria y de Valores. Cerrar tu cuenta o modificar tus condiciones como represalia por ejercer tus derechos legales sería una violación regulatoria. Dicho esto, la relación con el banco después de un juicio es una consideración práctica que debes hablar con tu abogado. Pero no dejes que el miedo a la represalia te cueste millones.
Onus probandi: la ley que el banco ignora
Voy a cerrar con el principio legal que todo empresario víctima de fraude bancario necesita tatuar en la memoria de su abogado: onus probandi. El que lo afirma, lo prueba.
El banco afirma que la operación fue autorizada por el usuario. Bien. Que lo pruebe. Y probar que la operación fue autorizada no es lo mismo que probar que las credenciales fueron correctas. Las credenciales pueden ser correctas y la operación puede ser no autorizada — cuando un tercero roba las credenciales y las usa.
El banco dice: «Las credenciales funcionaron.» El peritaje dice: «Las credenciales fueron robadas a través de X mecanismo, documentado con Y evidencia, verificada con Z hash.» La carga de la prueba se invierte. Ya no es el empresario el que tiene que demostrar que no autorizó. Es el banco el que tiene que demostrar que la operación no fue resultado de una vulneración que debió prevenir.
Esa inversión de la carga probatoria es lo que gana los casos. Y esa inversión solo ocurre cuando hay peritaje.
Los bancos no son invencibles. Son instituciones con recursos enormes, equipos jurídicos formidables y una inercia institucional que los protege en la mayoría de los casos. Pero esa protección se sostiene sobre una premisa frágil: que nadie va a cuestionar sus sistemas. Que nadie va a auditar la red del cliente. Que nadie va a buscar el envenenamiento DNS, el malware bancario, la operación atípica que el sistema de detección no detectó.
Cuando alguien lo hace — cuando un perito informático forense entra al caso con la metodología correcta, las herramientas correctas, y la experiencia de haber enfrentado a estos mismos bancos decenas de veces –, la premisa se derrumba. Y con ella se derrumba la defensa del banco.
Nunca he perdido un caso contra ellos. No porque tenga suerte. Porque la evidencia digital no miente. Los logs del banco dicen lo que el banco quiere que digan. La evidencia forense dice lo que realmente pasó. Y cuando un juez ve ambas versiones, la realidad gana.
Siempre.