Conozco el playbook de los bancos de memoria.
Lo conozco porque lo he enfrentado en juicio más veces de las que puedo contar. Lo conozco porque lo he leído en dictámenes periciales de los cinco bancos más grandes de México. Lo conozco porque lo he escuchado en audiencias, lo he desmenuzado en contraperitajes, lo he demolido pieza por pieza frente a jueces que, una vez que ven la evidencia técnica, entienden que el argumento del banco es un edificio construido sobre una base que no soporta el peso de la realidad.
Llevo 17 años en informática forense. He formado a más de 1,300 peritos en 10 países. Y en casos donde Duriva ha presentado peritaje informático contra un banco por transferencia no reconocida, el récord es invicto. Cero derrotas. No una. Cero.
Ese dato no es soberbia. Es el dato más relevante que puedo darle al abogado que está leyendo esto buscando cómo enfrentar al banco de su cliente. Es el dato que debería preocupar al perito del banco que va a leer esto porque le toca la contraparte. Y es el dato que debería darle esperanza al empresario que siente que el banco le está ganando la partida.
Este artículo es un desmontaje técnico, punto por punto, del argumento legal y pericial que los bancos presentan en juicios por transferencias no reconocidas. Voy a tomar cada pieza de su playbook, voy a explicar por qué suena convincente, y voy a demostrar dónde falla técnicamente. Porque falla. En cada caso. En cada pieza. En cada argumento.
Abogado del empresario que está preparando la demanda contra el banco: este artículo es su manual de contraataque. Cada sección identifica una pieza del argumento del banco y le da la herramienta técnica para destruirla. Úselo. Compártalo con su perito. Construya su estrategia sobre estas líneas.
Perito del banco que va a leer esto porque le toca enfrentar a Duriva en audiencia: se lo digo con el respeto profesional que merece cualquier colega, pero con la franqueza que exige la situación: si su dictamen se limita a los logs del portal bancario, lo que va a leer aquí es exactamente lo que va a escuchar en la contrapericial. Tiene tiempo de ampliar su análisis. Le conviene.
Empresario al que le vaciaron la cuenta: lo que sigue es técnico. Partes pueden ser densas. Pero cada sección demuestra por qué el argumento del banco — ese argumento que lo tiene desvelado, que lo hace sentir impotente, que suena tan definitivo en la carta de rechazo — tiene fisuras que un peritaje forense explota hasta que el argumento se derrumba.
Juez que eventualmente verá este tipo de caso: con todo respeto al tribunal, lo que presento aquí es lo que la comunidad de informática forense sabe y lo que los bancos prefieren que no se discuta en audiencia. Cada punto está sustentado en la realidad técnica de cómo operan los sistemas bancarios y cómo se ejecutan los fraudes electrónicos.
Pieza 1 del playbook: «La operación fue ejecutada con las credenciales correctas del usuario»
El argumento suena sólido. Las credenciales eran correctas. Usuario, contraseña, token. Todo cuadraba. Si las credenciales eran las del titular, el titular hizo la operación. Lógica impecable.
Excepto que no lo es. Y no lo es por una razón tan fundamental que debería ser obvia para cualquier persona con formación en seguridad informática: las credenciales correctas no demuestran identidad. Demuestran posesión de las credenciales.
Si yo tengo la llave de tu carro, puedo abrirlo. Puedo encenderlo. Puedo manejarlo. El carro va a funcionar exactamente igual que si lo estuvieras manejando tú. Todos los sistemas del carro van a registrar que «se usó la llave correcta.» Pero eso no significa que tú lo estuvieras manejando. Significa que alguien tenía tu llave.
En el mundo digital, las «llaves» — usuario, contraseña, token — se pueden robar. Se roban todos los días. Se roban mediante troyanos que registran cada tecla que presionas. Se roban mediante páginas clonadas que capturan tus datos cuando piensas que estás en el sitio real del banco. Se roban mediante SIM swapping que redirige los códigos SMS a otro teléfono. Se roban mediante keyloggers que operan en silencio dentro de tu navegador. Se roban mediante ingeniería social dirigida con datos reales de tu empresa.
Las credenciales correctas prueban que el atacante las tenía. No prueban que el titular las usó. Y esa distinción — entre posesión y uso voluntario — es la que destruye el primer argumento del banco.
Cuando presento esto en audiencia, le pido al juez que considere una analogía: si alguien roba la tarjeta de acceso de un empleado a un edificio y entra con ella, el sistema de seguridad del edificio va a registrar que «la tarjeta del empleado fue utilizada a las 3:47 AM.» Nadie, en ningún tribunal del mundo, aceptaría eso como prueba de que el empleado fue quien entró. Porque la tarjeta no es la persona. La tarjeta es un objeto que puede ser robado.
Las credenciales bancarias son exactamente lo mismo. Son objetos digitales que pueden ser robados. Y el hecho de que el banco las registre como «correctas» no dice absolutamente nada sobre quién las usó.
Pieza 2 del playbook: «La operación se ejecutó desde la IP registrada del usuario»
El segundo argumento favorito del banco: la IP coincide. La transferencia salió de la misma IP que el usuario tenía registrada. Si salió de tu IP, saliste tú.
Voy a explicar por qué este argumento es técnicamente absurdo. Y necesito que el abogado y el juez entiendan esto porque es el punto donde la ignorancia técnica del argumento del banco queda más expuesta.
Una IP pública no identifica a una persona. Identifica a una red.
Cuando el banco dice «la transferencia salió de la IP 187.xxx.xxx.xxx,» lo que está diciendo es que salió de la conexión a internet de la empresa. Es como decir que «la llamada se hizo desde el edificio de Insurgentes 500.» Eso te dice de qué edificio salió la llamada. No te dice quién la hizo. No te dice desde qué oficina. No te dice desde qué teléfono.
Detrás de una IP pública puede haber docenas de dispositivos. Computadoras, laptops, teléfonos, tablets, impresoras, cámaras de seguridad, dispositivos IoT. Todos comparten la misma IP pública. Y si el router de la empresa está comprometido — que es trivial de lograr cuando tiene contraseña de fábrica y administración remota habilitada –, un atacante puede conectarse a la red de la empresa desde afuera y usar la misma IP pública que el banco tiene registrada.
En uno de los casos que ha investigado Duriva — un caso tipo que ilustra un patrón recurrente –, una organización perdió millones por transferencias fraudulentas. El banco presentó como evidencia que la IP coincidía con la registrada. Nosotros demostramos que el router de la organización había sido comprometido mediante envenenamiento DNS, que los atacantes habían accedido a la red a través del router con contraseña de fábrica, y que las transferencias se ejecutaron desde un dispositivo del atacante conectado a la red de la organización — por eso la IP coincidía.
Usamos una analogía en audiencia que el juez entendió perfectamente: la IP pública es la dirección del edificio. La IP privada es el «Interior 1234.» El banco solo registró la dirección del edificio. Nunca verificó quién estaba en qué interior. En un edificio con 200 oficinas y 500 dispositivos, saber que la operación «salió del edificio» no prueba absolutamente nada sobre quién la ejecutó.
El perito del banco que argumente que «la IP coincide, por lo tanto fue el usuario» está cometiendo un error técnico básico. Un error que en cualquier certificación seria de informática forense sería calificado como falta grave. Porque confundir identidad de red con identidad de usuario es como confundir la matrícula de un avión con la identidad del piloto.
Pieza 3 del playbook: «No se identificaron anomalías en los sistemas del banco»
Este es el argumento más sutil y, en cierto sentido, el más deshonesto del playbook. Porque es técnicamente verdadero y estratégicamente engañoso.
El banco dice: «Nuestros sistemas funcionaron correctamente. No hubo vulneración de la plataforma de banca en línea. No hubo acceso no autorizado a nuestros servidores. No hubo anomalía en el procesamiento de la operación.»
Y es verdad. Los sistemas del banco funcionaron correctamente. La banca en línea procesó la operación como procesa cualquier otra. El servidor del banco no fue hackeado. La base de datos del banco no fue comprometida. Los firewalls del banco no fueron vulnerados.
Pero nadie dijo que el ataque hubiera sido al banco.
El fraude electrónico moderno no ataca al banco. Ataca al usuario. Ataca su computadora. Ataca su teléfono. Ataca su red. Ataca su router. Ataca la interfaz entre el usuario y el banco, no al banco mismo.
Decir «nuestros sistemas no presentaron anomalías» como argumento de que no hubo fraude es como decir «la cerradura de nuestra puerta funciona correctamente» después de que alguien entró con una llave clonada. La cerradura funcionó. La cerradura siempre funciona cuando le metes la llave correcta. El problema no es la cerradura. El problema es quién tenía la llave y cómo la obtuvo.
La ausencia de anomalías en los sistemas del banco no prueba la ausencia de fraude. Prueba la ausencia de un ataque al banco. Que es una cosa completamente diferente.
Y aquí está la parte que debería preocupar al juez: el banco usa «no hay anomalías en nuestros sistemas» como sinónimo de «no hubo fraude.» Pero esas dos afirmaciones no son equivalentes. La primera es una observación técnica sobre sus propios servidores. La segunda es una conclusión sobre lo que pasó en el otro extremo de la conexión. Y esa conclusión no la puede hacer sin investigar el otro extremo.
Que no investigó. Nunca investiga.
Pieza 4 del playbook: «El usuario es responsable de la custodia de sus credenciales»
Este argumento aparece en todos los contratos bancarios. El usuario se compromete a mantener la confidencialidad de sus credenciales. Si las credenciales son comprometidas, la responsabilidad es del usuario.
Suena razonable en abstracto. Pero tiene una falla fundamental en la práctica: asume que el usuario puede proteger sus credenciales contra ataques que ni siquiera puede detectar.
Pongamos un ejemplo concreto. Un empresario accede a la banca en línea de su empresa todos los días. Usa una contraseña de 12 caracteres con números y símbolos. Usa el token que el banco le dio. Accede desde la computadora de su oficina. No comparte su contraseña con nadie. No la anota en un post-it. No la envía por correo. Hace todo lo que el banco le pide.
Pero un troyano bancario tipo man-in-the-browser se instaló en su navegador hace tres semanas. El troyano no generó alertas. El antivirus no lo detectó porque usa una variante de día cero que todavía no está en las bases de firmas. El troyano intercepta la comunicación entre el navegador y el portal del banco en tiempo real. Captura las credenciales. Modifica las operaciones en vuelo. El usuario ve una cosa en su pantalla y el banco recibe otra.
El usuario no puede detectar ese ataque. Físicamente no puede. No hay indicador visual. No hay alerta del sistema. No hay comportamiento anómalo del navegador. El candadito SSL está verde. La URL es correcta. El certificado es válido. Todo parece normal. Porque el troyano opera por debajo de la capa visible del navegador.
Decir que el usuario «no custodió adecuadamente sus credenciales» cuando fue víctima de un man-in-the-browser es como decir que el dueño de una casa «no custodió adecuadamente sus llaves» cuando un cerrajero profesional las replicó mientras estaban dentro de la cerradura. Es una atribución de responsabilidad que ignora la realidad técnica de cómo opera el ataque.
Y aquí entra un concepto jurídico que los tribunales han empezado a reconocer: la asimetría tecnológica. El banco tiene equipos de ciberseguridad. Tiene firewalls de última generación. Tiene sistemas de detección de intrusos. Tiene SOCs (Security Operations Centers) monitoreando 24/7. Tiene presupuestos de millones de dólares en seguridad informática. El banco es un profesional de la seguridad financiera digital.
El usuario es un empresario que vende tornillos, o una ONG que administra fondos, o un contador que hace conciliaciones. El usuario no tiene equipo de ciberseguridad. No tiene SOC. No tiene analistas de amenazas. No tiene la capacidad técnica de detectar un man-in-the-browser ni de protegerse contra un SIM swapping.
Exigirle al usuario el mismo nivel de protección de credenciales que tiene el banco es jurídicamente inequitativo y técnicamente absurdo. La asimetría de capacidades entre el banco y el usuario hace que la cláusula de «custodia de credenciales» sea un escudo contractual, no una asignación justa de responsabilidad.
Pieza 5 del playbook: «Nuestro sistema de autenticación cumple con los estándares regulatorios»
Los bancos argumentan que su sistema de autenticación — usuario, contraseña, token — cumple con los estándares que exige la regulación bancaria. Y que si el regulador aprueba el sistema, el sistema es seguro.
Este argumento tiene dos fallas:
Primera: cumplimiento regulatorio no es equivalente a seguridad. Cumplir con la norma mínima del regulador significa que el banco tiene los controles que la norma exige. No significa que esos controles sean suficientes para prevenir todos los ataques. Las normas regulatorias siempre van detrás de la evolución del crimen. El regulador establece requisitos basados en amenazas conocidas. Los atacantes desarrollan técnicas nuevas que las normas todavía no contemplan. Cumplir con la norma es el piso, no el techo.
Segunda: el man-in-the-browser bypassea la autenticación sin romperla. Este es el punto técnico más importante de este artículo y necesito que el abogado y el juez lo entiendan con absoluta claridad.
El man-in-the-browser no rompe el sistema de autenticación del banco. No vulnera el token. No descifra la contraseña. No bypassea ningún control del banco. Lo que hace es interponerse entre el usuario y el banco, por debajo de todos los controles, y modificar la comunicación en tiempo real.
El usuario se autentica correctamente. El banco valida la autenticación correctamente. Todo el proceso de autenticación es impecable. El sistema «infalible» del banco funciona perfectamente. Y el fraude ocurre de todas formas.
Porque el fraude no ocurre en la autenticación. Ocurre en la transacción. El usuario está autenticado — genuinamente autenticado, con sus credenciales reales, desde su dispositivo real. Pero la instrucción que sale de su navegador hacia el banco no es la instrucción que el usuario dio. El troyano la modificó en el camino.
El banco recibe una instrucción de transferencia de un usuario autenticado correctamente. Desde la perspectiva del banco, no hay razón para sospechar. La autenticación fue válida. La instrucción llegó por el canal correcto. El banco la ejecuta.
Y cuando el empresario reclama, el banco dice: «La operación fue autenticada correctamente. Nuestro sistema funcionó como debe. El sistema es seguro.»
El sistema es seguro contra ataques al sistema. No es seguro contra ataques al usuario que bypassean el sistema sin tocarlo. Y pretender que un sistema que puede ser bypasseado sin ser vulnerado es «infalible» es o ignorancia técnica o deshonestidad estratégica.
En audiencia, cuando presento este argumento con la demostración técnica de cómo opera un man-in-the-browser, la reacción del juez siempre es la misma: entiende que el banco tenía razón en que su autenticación funcionó, pero entiende que eso no significa que el usuario haya dado la instrucción que se ejecutó. Y cuando entiende eso, el argumento del banco se derrumba.
Pieza 6 del playbook: el dictamen pericial del banco
Los bancos presentan dictámenes periciales elaborados por peritos propios o contratados. Esos dictámenes, en mi experiencia de 17 años, siguen un patrón idéntico:
- Se revisan los logs del portal de banca en línea.
- Se confirma que las credenciales utilizadas fueron las del titular.
- Se confirma que la IP de origen coincide con la registrada.
- Se confirma que el token de autenticación fue validado correctamente.
- Se concluye que «la operación fue ejecutada por el titular o por alguien con acceso a las credenciales del titular, sin que se detecte vulneración a los sistemas del banco.»
Y eso es todo.
Ese dictamen tiene un problema fundamental: analiza la mitad de la ecuación. Analiza el extremo del banco. No analiza el extremo del usuario.
Es como si un perito en un caso de robo de vehículo analizara exclusivamente la cerradura del carro y concluyera: «La cerradura no fue forzada. Se utilizó la llave correcta. Por lo tanto, no hubo robo.» Sin verificar si la llave fue clonada. Sin verificar si el sistema keyless fue interceptado. Sin verificar si alguien obtuvo un duplicado de la llave por otro medio. Solo miró la cerradura, vio que funcionó correctamente, y concluyó que no pasó nada.
Un dictamen pericial que analiza solo los logs del banco y concluye que «no hubo vulneración a los sistemas del banco» no está incorrecto — está incompleto. Y un dictamen incompleto que se presenta como conclusivo es peor que no presentar dictamen. Porque crea la ilusión de un análisis exhaustivo cuando en realidad es un análisis parcial que convenientemente ignora el único lugar donde se encuentra la evidencia del fraude: el dispositivo, la red y las comunicaciones del usuario.
Cuando en audiencia le pregunto al perito del banco:
«¿Analizó usted la computadora desde la que se accedió a la banca en línea?»
«No.»
«¿Buscó evidencia de troyanos bancarios en el equipo del usuario?»
«No.»
«¿Auditó la configuración DNS del router de la red del usuario?»
«No.»
«¿Verificó con la compañía telefónica si hubo un cambio de SIM en la línea del titular en las fechas cercanas a las operaciones?»
«No.»
«¿Analizó los headers de los correos recibidos por el usuario en busca de phishing dirigido?»
«No.»
«Entonces, ¿cómo puede concluir que el titular fue quien ejecutó la operación si no investigó ningún vector de compromiso de credenciales?»
Silencio.
Ese silencio es el momento en que el caso se gana. No por retórica. Por evidencia. Porque frente al silencio del perito del banco, está el dictamen de Duriva que sí analizó la computadora, que sí buscó el troyano, que sí auditó el router, que sí verificó la compañía telefónica, que sí analizó los correos. Y que encontró la evidencia del fraude exactamente donde el perito del banco no buscó.
La respuesta copiar-pegar: por qué la defensa del banco es idéntica en todos los casos
Voy a compartir algo que los abogados que litigan contra bancos saben pero que los empresarios y contadores desconocen: la defensa del banco es un template. Un formato. Un copiar-pegar con variaciones menores.
He enfrentado a los cinco bancos más grandes de México. Las contestaciones de demanda, los dictámenes periciales y los argumentos en audiencia son estructuralmente idénticos entre bancos. Porque todos usan la misma estrategia: defender la integridad de sus sistemas y trasladar la responsabilidad al usuario.
No es que los bancos se pongan de acuerdo. Es que la estrategia es obvia cuando tienes una sola línea de defensa: «nuestros sistemas funcionaron correctamente.» Todos llegan a la misma conclusión porque todos parten de la misma premisa limitada.
Y esa estandarización de la defensa es, paradójicamente, una debilidad. Porque cuando conoces el playbook, puedes preparar el contraataque antes de que el banco lo ejecute. Cada pieza del argumento del banco tiene una contrapieza técnica. Y cuando el abogado del empresario tiene un peritaje forense que anticipa cada argumento del banco y lo refuta con evidencia antes de que el banco lo presente, la dinámica del juicio cambia radicalmente.
El banco ya no está presentando una defensa. Está repitiendo un script que la contraparte conoce, anticipaba, y ya refutó con evidencia.
He visto abogados del banco visiblemente desconcertados en audiencia cuando la contrapericial ya había respondido punto por punto cada argumento de su dictamen antes de que lo presentaran. Porque están acostumbrados a que nadie cuestione técnicamente su peritaje. Están acostumbrados a que el abogado del empresario no tenga las herramientas para hacerlo. Están acostumbrados a ganar por incomparecencia técnica de la contraparte.
Cuando la contraparte tiene peritaje forense real, el playbook del banco ya no funciona.
El sistema «infalible» que falla: la contradicción que el banco no puede resolver
Hay una contradicción lógica en el argumento del banco que, una vez que se expone, es devastadora.
El banco dice: «Nuestro sistema de autenticación es seguro. Las credenciales eran correctas. La operación fue válida.»
Si el sistema es seguro y las credenciales son la única forma de acceder, entonces solo el titular puede ejecutar operaciones. Hasta ahí, el argumento del banco suena coherente.
Pero si el titular no ejecutó la operación — que es lo que el titular está reclamando –, entonces hay solo dos posibilidades lógicas:
Posibilidad 1: El titular miente. El titular sí ejecutó la operación y ahora quiere recuperar el dinero fraudulentamente.
Posibilidad 2: Las credenciales fueron obtenidas por un tercero y el sistema, por seguro que sea, no puede distinguir entre el titular y un atacante que tiene las credenciales del titular.
Si es la posibilidad 1, el banco necesita demostrarlo. No asumirlo. Demostrarlo.
Si es la posibilidad 2, el sistema del banco tiene una limitación inherente: autentica credenciales, no identidades. Y esa limitación no es culpa del usuario. Es una limitación arquitectónica del sistema que el banco diseñó, implementó y comercializó como «seguro.»
El banco no puede tener las dos cosas. No puede decir «nuestro sistema es infalible» y al mismo tiempo no poder explicar cómo alguien que no es el titular ejecutó operaciones con las credenciales del titular. Si el sistema es infalible, la operación fraudulenta no debería haber ocurrido. Y si ocurrió, el sistema falló. No en su mecánica interna — los logs están limpios. Falló en su propósito fundamental: asegurar que solo el titular pueda ejecutar operaciones.
Esa contradicción es la que presento en audiencia. Y es la que los jueces entienden cuando la ven: el banco diseñó un sistema que autentica credenciales pero no identidades. Un sistema que funciona correctamente cuando las credenciales son correctas, sin importar quién las presente. Un sistema que, por diseño, no puede distinguir entre uso legítimo y uso fraudulento si las credenciales son las mismas.
Ese defecto de diseño no es responsabilidad del usuario. Es responsabilidad del banco. Y cuando el peritaje forense demuestra cómo las credenciales fueron robadas — por malware, por SIM swapping, por phishing, por DNS envenenado –, la conclusión es ineludible: el sistema del banco falló en proteger al usuario, no el usuario en custodiar sus credenciales.
El artículo 210-A y el peso del peritaje forense
Todo lo que he descrito tiene valor probatorio únicamente si se presenta bajo el marco legal correcto.
El artículo 210-A del Código Federal de Procedimientos Civiles establece que la información generada por medios electrónicos tiene valor probatorio cuando cumple tres requisitos: fiabilidad del método en que fue generada, atribuibilidad del contenido a su autor, y accesibilidad para consulta posterior.
Un dictamen pericial de Duriva cumple los tres:
Fiabilidad del método. La evidencia se recolecta mediante imagen forense bit a bit del dispositivo, se preserva con cadena de custodia documentada en video, se analiza con metodologías estandarizadas de informática forense. Cada pieza de evidencia tiene hash SHA-256 calculado al momento de la adquisición y verificado al momento del análisis.
Atribuibilidad. La evidencia se vincula al caso mediante la cadena de custodia que documenta de dónde vino el dispositivo, quién lo entregó, cuándo se entregó, quién lo analizó, qué se encontró y cómo. La atribución es directa y verificable.
Accesibilidad. La imagen forense se preserva en medios de almacenamiento sellados y custodiados. Puede ser consultada, verificada y reanalizada por cualquier perito, incluido el perito del banco, en cualquier momento.
El dictamen del banco que presenta solo logs sin imagen forense, sin hash, sin cadena de custodia del dispositivo del usuario, sin análisis del endpoint, no cumple con el mismo rigor. Y cuando se ponen los dos dictámenes frente al juez, la diferencia en profundidad, rigor y alcance es evidente.
El argumento jurídico dice «no fue mi cliente.» El peritaje forense dice «aquí está la evidencia de quién fue, cómo lo hizo y cuándo lo hizo.» La diferencia entre uno y otro es la diferencia entre una afirmación y una demostración. Y en un juicio, la demostración gana.
Lo que necesita saber cada persona que lee esto
Abogado del empresario:
El playbook del banco es predecible. Conocerlo es la mitad de la batalla. La otra mitad es tener el peritaje forense que lo refute punto por punto con evidencia. No argumente contra los logs del banco con retórica. Argumente con un peritaje que muestre lo que los logs del banco no muestran: el lado del usuario, donde está la evidencia del fraude.
Pida el peritaje desde el día uno. No después de CONDUSEF. No después de la primera audiencia. Desde el día uno. Porque la evidencia se degrada cada día que pasa.
Perito del banco que va a enfrentar este tipo de contrapericial:
Con todo respeto profesional: amplíe su análisis. Si su dictamen se limita a los logs del portal y su conclusión es que «las credenciales eran correctas y la IP coincidía,» está presentando la mitad de la historia. Y cuando la otra mitad se presente en la contrapericial, su dictamen va a quedar evidenciado como incompleto. No porque sea falso — lo que dice es cierto. Sino porque lo que omite es donde está la verdad del caso.
Un perito que solo confirma la narrativa de su cliente sin investigar la narrativa alternativa no está haciendo peritaje. Está haciendo certificación de la versión del banco. Y hay un abismo de diferencia.
Empresario al que le vaciaron la cuenta:
El argumento del banco suena aplastante cuando lo lees en la carta de rechazo. «Credenciales correctas, IP registrada, sin anomalías.» Suena como si no hubiera nada que hacer.
Pero cada pieza de ese argumento tiene una falla técnica que un peritaje forense explota. Las credenciales correctas no prueban que fuiste tú — prueban que alguien las tenía. La IP registrada no identifica a la persona — identifica a la red. La ausencia de anomalías en el banco no prueba que no hubo fraude — prueba que el fraude no fue al banco.
El camino es técnico. Es legal. Es más largo que aceptar la carta de rechazo. Pero funciona. Y funciona porque la evidencia no miente.
Juez que verá un caso de transferencia no reconocida:
Lo que el banco le presenta son los logs de su propio sistema. Esos logs le dicen que el sistema del banco funcionó correctamente. Nadie lo disputa.
La pregunta que el peritaje forense del usuario responde es otra: ¿qué pasó en el dispositivo del usuario antes de que la conexión llegara al banco? ¿Fue el usuario quien dio la instrucción o fue un troyano que la modificó? ¿Fue el usuario quien proporcionó sus credenciales o fueron capturadas por un ataque? ¿Fue el usuario quien recibió el token SMS o fue un atacante que secuestró su línea telefónica?
Las dos preguntas — qué pasó en el banco y qué pasó en el dispositivo del usuario — son complementarias. Y una sin la otra da una imagen incompleta. El dictamen que analice ambas es el que refleja la realidad. El dictamen que analice solo una es el que refleja una versión.
El playbook de los bancos funciona cuando nadie lo cuestiona. Funciona cuando el empresario acepta la carta de rechazo. Funciona cuando el abogado va a CONDUSEF y recibe la resolución genérica. Funciona cuando nadie tiene la capacidad técnica de desmontar cada pieza del argumento.
Deja de funcionar cuando entra el peritaje forense.
Deja de funcionar cuando alguien analiza la computadora del usuario y encuentra el troyano. Cuando alguien audita el router y encuentra los DNS envenenados. Cuando alguien obtiene el registro de la compañía telefónica y documenta el SIM swapping. Cuando alguien reconstruye el ataque paso a paso, con evidencia técnica, con cadena de custodia, con hash SHA-256, con el rigor que exige el artículo 210-A.
Cuando eso pasa, el playbook del banco se convierte en lo que siempre fue: una respuesta copiar-pegar que asume que nadie va a verificar.
En Duriva, verificamos. Caso tras caso. Banco tras banco. Y el resultado habla por sí mismo: récord invicto. No porque los bancos sean débiles. Son instituciones con recursos enormes. Sino porque su argumento descansa sobre una base técnica que no soporta el escrutinio forense.
Las credenciales correctas no son identidad. La IP registrada no es autorización. La ausencia de anomalías en el banco no es ausencia de fraude. Y cuando un peritaje demuestra eso con evidencia, el argumento del banco se derrumba.
Siempre se derrumba.