La carta llegó un martes. O un jueves. O un lunes a las tres de la tarde. No importa el día. Lo que importa es que la estoy viendo ahora mismo en la pantalla del empresario que me la enseña con las manos temblando, sentado frente a mí en la sala de juntas de Duriva, con la corbata floja, la mandíbula apretada y esa mirada que ya conozco de memoria — la mirada del que acaba de entender que el sistema no está de su lado.
La carta dice algo así:
«En atención a su reclamación con número de folio XXX-XXXXX, le informamos que, tras realizar la investigación correspondiente, se determinó que la operación objeto de su inconformidad fue ejecutada con las credenciales de acceso correctas (usuario, contraseña y dispositivo de autenticación) desde la dirección IP registrada para su cuenta. No se identificaron anomalías en los sistemas de la institución. Por lo anterior, la operación se considera válida y no procede la devolución del monto reclamado.»
Esa carta. Esas palabras. Ese mismo párrafo copiar-pegar que he leído cientos de veces. Con distintos logos arriba — los cinco bancos más grandes de México usan variaciones de ese mismo texto — pero con el mismo contenido, la misma lógica, la misma conclusión: fue usted. Sus credenciales. Su IP. Su culpa.
Y el empresario, que está sentado frente a mí con los ojos rojos porque lleva tres noches sin dormir, me pregunta lo que me preguntan todos:
«¿Y ahora qué hago?»
Llevo 17 años respondiendo esa pregunta. He formado a más de 1,300 peritos en informática forense en 10 países. He enfrentado a los cinco bancos más grandes de México en juicios por transferencias no reconocidas. Y tengo un dato que no digo por soberbia sino porque es lo único que le sirve al empresario que está leyendo esto a las cuatro de la mañana buscando respuestas: en casos donde Duriva ha presentado peritaje informático contra un banco, no hemos perdido. Ni uno.
Este artículo es para usted. Para el que recibió la carta. Para el que está en CONDUSEF esperando una resolución que no va a servir. Para el que siente que el banco le está ganando la partida. No le está ganando. Lo que pasa es que usted está jugando su juego. Y hay otro juego — uno técnico, uno forense, uno que se juega con evidencia digital y no con cartas de rechazo — donde el banco pierde. Siempre pierde. Porque la evidencia no miente.
Empresario al que le vaciaron la cuenta y recibió la carta de rechazo del banco: lo que sigue en estas páginas es el mapa completo de por qué esa carta no tiene el peso que el banco quiere que tenga, qué hay detrás de esa respuesta genérica, y qué puede hacer para demostrar lo que usted ya sabe — que no fue usted.
Esposa del empresario que está leyendo esto porque su marido no puede más: lo entiendo. Lo he visto más veces de las que puedo contar. El estrés financiero de perder millones de la noche a la mañana no se queda en la oficina — se mete en la casa, en la mesa, en las conversaciones a medianoche. Lo que necesita saber es que hay un camino técnico y legal que puede recuperar ese dinero. No es rápido. No es sencillo. Pero existe. Y funciona.
Abogado del empresario que está armando la estrategia: la carta de rechazo del banco no es una sentencia. Es la primera jugada de un playbook predecible que conozco de memoria. Lo que necesita usted no es impugnar esa carta con argumentos jurídicos genéricos. Lo que necesita es un peritaje informático forense que destruya la premisa técnica sobre la que descansa todo el argumento del banco. Ese peritaje es lo que va a leer aquí.
Contador de la empresa que detectó el faltante en la conciliación: usted no tiene la culpa. Si las credenciales fueron comprometidas por malware, SIM swapping o cualquier otro vector de ataque, usted fue víctima, no cómplice. Lo que sigue le va a dar el contexto técnico para entender qué pasó y, más importante, para dejar de cargarse con una responsabilidad que no es suya.
La carta de rechazo: anatomía de una respuesta diseñada para que te rindas
Voy a ser absolutamente directo sobre algo que el empresario necesita entender antes de perder un solo minuto más de sueño: la carta de rechazo del banco no es el resultado de una investigación. Es el resultado de un template.
He visto esas cartas de todos los bancos. De los grandes. De los medianos. De los que se presumen «digitales.» Y en el 95% de los casos, el contenido es idéntico con variaciones cosméticas. El párrafo central dice lo mismo: credenciales correctas, IP registrada, sin anomalías en nuestros sistemas, la operación es válida.
Y es verdad. Desde la perspectiva del banco, todo eso es verdad. Las credenciales fueron correctas. La IP coincide. Los sistemas del banco funcionaron como debían funcionar. El banco no fue hackeado.
Pero esa verdad parcial es, en la práctica, una mentira estratégica. Porque omite la única pregunta que importa: ¿quién usó esas credenciales?
Es como si un hotel te dijera: «La llave magnética que abrió la habitación era la suya. La puerta del hotel funcionó correctamente. Nuestros sistemas no presentaron anomalías. Por lo tanto, usted es responsable de lo que desapareció de la habitación.»
Señor, alguien clonó la llave. ¿Eso no lo investigó? No. No lo investigó. No le corresponde. No le conviene.
El banco verifica que las credenciales fueron correctas y que sus sistemas operaron normalmente. Eso es todo lo que hace. No investiga cómo se obtuvieron esas credenciales. No analiza si la computadora del usuario tenía malware. No revisa si el teléfono del usuario fue comprometido. No audita la red desde donde se realizó la operación. No busca el origen del compromiso.
El banco mira el final del túnel — la conexión exitosa al portal de banca en línea — y concluye que todo está bien. Lo que pasó antes de ese momento, en el dispositivo del usuario, en su red, en su teléfono, en su SIM card, no le interesa. No porque no sea relevante. Es extremadamente relevante. No le interesa porque la respuesta podría demostrar que el banco tiene una responsabilidad que no quiere asumir.
CONDUSEF: el callejón sin salida que parece una puerta
Después de recibir la carta de rechazo, la reacción natural del empresario es ir a CONDUSEF. Es lo que le dice su abogado. Es lo que le dice Google. Es lo que le dice el artículo de periódico que encontró buscando «fraude bancario qué hago.» Es lo que parece lógico: hay una comisión del gobierno que protege a los usuarios de servicios financieros, voy a acudir a ella.
Le soy franco: CONDUSEF, para efectos de un fraude informático, es un callejón sin salida que parece una puerta.
Y no lo digo con desprecio hacia la institución. CONDUSEF cumple funciones útiles en otro tipo de reclamaciones. Pero en fraude electrónico, CONDUSEF enfrenta una limitación estructural que ninguna buena voluntad puede compensar: no tiene la capacidad técnica para investigar una intrusión informática.
El proceso en CONDUSEF es el siguiente: usted presenta su reclamación. CONDUSEF le pide al banco la información de la operación. El banco presenta sus logs — los mismos logs que ya le mostró a usted en la carta de rechazo. CONDUSEF revisa los logs. Los logs dicen que las credenciales eran correctas y que la IP coincidía. CONDUSEF concluye que «no se acredita la responsabilidad de la institución bancaria.»
Es un proceso circular. CONDUSEF evalúa la única evidencia que el banco quiere presentar. Y esa evidencia, por diseño, siempre favorece al banco. Porque la evidencia del banco solo muestra que sus sistemas funcionaron correctamente. No muestra — porque el banco no la busca y no la presenta — la evidencia de cómo las credenciales fueron comprometidas en primer lugar.
CONDUSEF no tiene peritos forenses. No tiene laboratorio de informática forense. No puede ordenar una auditoría de la red del usuario. No puede analizar el teléfono del usuario en busca de SIM swapping. No puede examinar la computadora en busca de troyanos bancarios. No tiene la infraestructura técnica para hacer nada de eso.
Y sin esa infraestructura, la resolución de CONDUSEF es, en los hechos, una lectura de los logs del banco con un sello oficial encima.
Eso no le va a devolver sus millones. Lo que le va a devolver sus millones es un juicio con peritaje forense. CONDUSEF puede servir como un paso administrativo — genera un expediente, genera una constancia de reclamación. Úselo para eso. Pero no lo trate como la solución. La solución viene después.
El banco solo ve el final del túnel: por qué su evidencia es estructuralmente incompleta
Necesito que el abogado, el empresario y el contador entiendan esto con absoluta claridad porque es la base de todo el caso:
El banco registra la conexión al portal de banca en línea. Registra la IP desde donde se conectó. Registra el usuario y contraseña que se ingresaron. Registra que el token de autenticación fue validado. Registra la instrucción de transferencia. Registra la confirmación.
Todo eso es el final del túnel.
Pero el fraude no ocurrió en el portal del banco. El fraude ocurrió antes. En el dispositivo del usuario. En su red. En su teléfono. En su SIM card. En algún punto entre el usuario y la pantalla del banco, las credenciales fueron capturadas por un tercero. Y ese tercero las usó para conectarse al portal como si fuera el titular.
Para cuando el banco «ve» la conexión, el ataque ya terminó. Lo que el banco registra es al atacante usando credenciales robadas. Y desde la perspectiva de los logs del banco, esa conexión es idéntica a una conexión legítima. Porque las credenciales eran correctas. Porque el atacante las tenía.
La pregunta no es si las credenciales eran correctas. Claro que eran correctas — por eso el atacante pudo usarlas. La pregunta es cómo las obtuvo. Y esa pregunta no se responde en los logs del banco. Se responde en la investigación forense del dispositivo, la red y las comunicaciones del usuario.
El banco mira su pequeño rectángulo de realidad — la conexión al portal — y dice «todo normal.» Pero esa es una fracción ínfima de lo que pasó. Es como si un médico mirara una radiografía del dedo meñique del paciente y dijera «está sano» mientras el paciente tiene una fractura en la columna. La radiografía del dedo no miente. Pero la conclusión es absurda porque ignora dónde está el problema real.
Los vectores de ataque: cómo se roban las credenciales bancarias
El empresario que recibió la carta de rechazo necesita entender qué pasó. No en términos vagos de «me hackearon.» En términos precisos. Porque la precisión es lo que convierte un reclamo en un caso ganador.
Estos son los vectores de ataque más frecuentes que hemos documentado en el laboratorio de Duriva en casos de transferencias no reconocidas:
Malware bancario (troyanos)
Los troyanos bancarios son software malicioso diseñado específicamente para robar credenciales de banca en línea. No son virus genéricos. No son el malware que te llena la pantalla de publicidad. Son programas sofisticados, frecuentemente desarrollados por organizaciones criminales especializadas, que operan en silencio dentro de la computadora de la víctima.
Un troyano bancario puede hacer lo siguiente sin que el usuario note absolutamente nada:
Keylogging. Registra cada tecla que presionas. Cada una. Usuario, contraseña, CLABE destino, monto. Todo. El troyano guarda esa información y la envía al atacante. Tu antivirus puede no detectarlo porque los troyanos bancarios modernos se actualizan más rápido que las bases de firmas de los antivirus.
Man-in-the-browser. El troyano se inyecta en el navegador — Chrome, Firefox, Edge — y modifica lo que ves en la pantalla. Entras a la página real del banco. Es la página real. El certificado SSL es válido. El candadito está verde. Todo es genuino. Pero el troyano intercepta la comunicación entre tu navegador y el servidor del banco. Puedes ver en tu pantalla «Transferencia a Proveedor ABC, $150,000» y confirmar con tu token. Pero lo que el banco recibe es «Transferencia a Cuenta XYZ, $1,500,000.» El usuario confirmó una operación que no es la que se ejecutó. Y el banco registró que «las credenciales eran correctas y la operación fue confirmada por el usuario.» Técnicamente cierto. Prácticamente un fraude.
Screen capture. Algunos troyanos toman capturas de pantalla cada vez que detectan que el usuario está en un sitio bancario. Capturan el saldo, la CLABE, los movimientos. Esa información le permite al atacante planificar el monto exacto del fraude.
Certificate theft. En banca empresarial, algunos bancos usan certificados digitales para autenticación adicional. Los troyanos especializados pueden extraer esos certificados del equipo del usuario. Con el certificado robado, el atacante puede autenticarse ante el banco como si estuviera usando la computadora autorizada.
La evidencia del troyano está en la computadora. En la memoria RAM. En los procesos activos. En los archivos temporales del navegador. En los registros del sistema operativo. Si alguien sabe dónde buscar, la evidencia habla. Pero si la computadora se formatea, se reinicia, se «limpia» con un antivirus o se apaga incorrectamente, esa evidencia se destruye. Volveremos a este punto.
SIM swapping
Este es el vector que ha explotado en México en los últimos tres años. Y es particularmente devastador porque ataca el teléfono del usuario, no su computadora.
El SIM swapping funciona así: el atacante contacta a la compañía telefónica de la víctima — Telcel, AT&T, Movistar — y, mediante ingeniería social, convence al operador de que le emita una nueva SIM card con el número de la víctima. En algunos casos, el atacante tiene un cómplice dentro de la compañía telefónica. En otros, simplemente se presenta en una sucursal con una identificación falsa.
Una vez que el atacante tiene la SIM card con tu número, tu teléfono pierde señal. El teléfono del atacante la gana. Y todos los mensajes SMS que iban a tu número — incluyendo los códigos de autenticación del banco, los tokens SMS, las notificaciones de operación — ahora llegan al atacante.
Si tu banco usa SMS como segundo factor de autenticación — y muchos bancos en México todavía lo usan como única opción –, el atacante ya tiene todo lo que necesita: tu usuario (que probablemente obtuvo por phishing o filtración), tu contraseña (mismo vector), y ahora tu código SMS. Puede entrar a tu banca en línea, ejecutar la transferencia y confirmarla con el código que recibió en tu número.
Y el banco registró que «se validó el segundo factor de autenticación correctamente.» Porque se validó. El código SMS llegó al número correcto. Solo que ese número ya no estaba en tu teléfono. Estaba en el teléfono del atacante.
La evidencia del SIM swapping está en los registros de la compañía telefónica. En el registro del cambio de SIM. En la hora exacta en que tu teléfono perdió señal y el del atacante la ganó. Esa hora, contrastada con la hora de la transferencia fraudulenta, es demoledora. Porque demuestra que en el momento de la transferencia, el segundo factor de autenticación no estaba en poder del titular.
Envenenamiento DNS del router
He escrito extensamente sobre este vector en otro artículo de Duriva, pero necesito mencionarlo aquí para completar el panorama. El envenenamiento DNS del router compromete la red de la empresa alterando la configuración del aparato que conecta toda la oficina a internet. Cuando los DNS del router se cambian para apuntar a servidores controlados por los atacantes, toda la red queda comprometida. El usuario escribe la dirección del banco en su navegador y el router lo manda a una réplica exacta controlada por los atacantes. Las credenciales se capturan en tiempo real.
La diferencia con el malware es que en este caso la computadora del usuario está limpia. No hay troyano. No hay keylogger. No hay nada anormal en la máquina. El compromiso está en el router. Y si nadie revisa el router — y nadie lo revisa, porque nadie piensa que el router sea relevante para la seguridad bancaria –, el ataque es invisible.
Phishing dirigido (spear phishing)
El phishing dirigido no es el correo genérico de «actualice su contraseña.» Es un correo personalizado, escrito con datos reales del empresario, con referencias a operaciones reales, con el formato exacto de los correos del banco. Un correo que dice, por ejemplo: «Estimado [nombre real del empresario], debido a una actualización de seguridad en su cuenta empresarial terminada en [últimos cuatro dígitos reales], es necesario que valide sus credenciales de acceso. Haga clic aquí para continuar.»
El enlace lleva a una página idéntica a la del banco. El empresario ingresa sus datos. Los atacantes los capturan. Fin.
La sofisticación de estos ataques ha llegado a un punto donde incluso usuarios experimentados caen. Porque los atacantes tienen información privilegiada — obtenida de filtraciones de datos, de reconocimiento en redes sociales, de correos interceptados — que les permite construir un engaño casi perfecto.
El onus probandi: quién debe demostrar qué
Aquí entra el argumento jurídico que el abogado del empresario necesita manejar con precisión.
En materia de servicios financieros, existe un principio de asimetría tecnológica que los tribunales han reconocido progresivamente: el banco tiene la infraestructura, el conocimiento técnico y los recursos para implementar medidas de seguridad. El usuario no. El banco es el profesional del servicio financiero. El usuario es el consumidor.
Cuando el banco dice «las credenciales eran correctas, la culpa es del usuario,» está imponiendo la carga de la prueba al usuario. Está diciendo: tú demuéstrame que no fuiste tú.
Pero el onus probandi, en un caso de fraude electrónico, no puede recaer exclusivamente en el usuario. Porque el usuario no tiene acceso a los logs del banco. No tiene acceso a la configuración de seguridad del banco. No tiene acceso a los registros de sus propios dispositivos si no sabe que existen. No tiene la capacidad técnica para investigar una intrusión informática.
El banco, en cambio, tiene acceso a todo lo suyo. Y podría — si quisiera — colaborar en la investigación del compromiso del lado del usuario. Podría proporcionar los logs completos de la sesión, no solo el resumen. Podría analizar patrones de comportamiento anómalo en la cuenta. Podría verificar si la IP de origen tiene histórico de actividad fraudulenta en otras cuentas. Podría cruzar la hora de la operación con el historial de acceso del usuario para detectar inconsistencias.
Pero no lo hace. Porque el resultado de esa investigación podría obligarlo a pagar.
El peritaje informático forense equilibra esa asimetría. El peritaje le dice al juez: «El banco presentó los logs de su portal. Nosotros investigamos qué pasó en el otro extremo de la conexión. Y esto es lo que encontramos.» Y lo que se encuentra — el troyano, el SIM swap, el DNS envenenado, el phishing dirigido — demuestra que las credenciales fueron comprometidas por un ataque, no utilizadas voluntariamente por el titular.
Eso es lo que cambia el caso. No un argumento. Una demostración.
Lo que el banco no quiere que hagas (y que deberías estar haciendo ahora mismo)
El banco quiere que aceptes la carta de rechazo. Quiere que vayas a CONDUSEF y recibas la resolución genérica. Quiere que te canses. Quiere que calcules que el juicio va a costar más que lo que perdiste. Quiere que te rindas.
Porque cuando te rindes, el banco gana sin gastar un peso en litigio. Y cuando demandas sin peritaje, el banco gana gastando poco en un litigio que tiene controlado. El banco solo pierde cuando lo enfrentas con evidencia técnica que destruye su única defensa: «las credenciales eran correctas.»
Lo que deberías estar haciendo ahora mismo:
Preservar toda la evidencia. La computadora desde la que se accedía a la banca en línea no se toca. No se formatea. No se reinicia. No se «limpia» con antivirus. Si el troyano está ahí, necesitas que un perito lo encuentre. No que un antivirus lo borre. El antivirus borra la prueba. El perito la documenta. Hay una diferencia abismal entre las dos cosas.
Documentar el timeline. ¿Cuándo fue la última vez que accediste legítimamente a la banca en línea? ¿A qué hora? ¿Desde qué dispositivo? ¿Qué operaciones realizaste? ¿Cuándo descubriste las transferencias no reconocidas? ¿Cómo las descubriste? ¿Quién más tenía acceso a las credenciales? Escribe todo. Con fechas, horas y detalles. Esa declaración, contrastada con el peritaje forense, construye la narrativa cronológica del ataque.
Verificar tu teléfono. Si tu banco usa SMS como segundo factor de autenticación, verifica con tu compañía telefónica si hubo un cambio de SIM en las fechas cercanas a las transferencias fraudulentas. Si hubo un cambio de SIM que tú no solicitaste, tienes evidencia de SIM swapping. Solicita a la compañía telefónica un reporte formal por escrito del evento. Ese documento es prueba.
No borrar correos. Si recibiste algún correo sospechoso en las semanas previas al fraude — una supuesta comunicación del banco, una solicitud de actualización de datos, un enlace para «verificar tu cuenta» — no lo borres. Ese correo es evidencia del vector de ataque. Reenvíalo a tu abogado y presérvalo.
Contactar a un perito informático forense. No a un consultor de ciberseguridad que te va a vender un firewall. No a un «experto» que te va a decir que instales antivirus. A un perito forense que sepa hacer una imagen forense del disco duro, analizar la memoria RAM, buscar troyanos bancarios, auditar la configuración del router, documentar la intrusión con cadena de custodia y generar un dictamen pericial con valor probatorio ante un juez bajo el artículo 210-A del Código Federal de Procedimientos Civiles.
Hablar con un abogado con experiencia real en litigio bancario. No un abogado que «también lleva mercantil.» Un abogado que haya enfrentado a un banco en juicio y que entienda que la batalla no se gana con alegatos bonitos sino con peritaje técnico. El abogado que no pide peritaje forense en un caso de transferencia no reconocida está peleando con las manos atadas. Y va a perder.
Lo que encontramos cuando investigamos: patrones de un récord invicto
Voy a compartir algo que normalmente no comparto en un artículo público. Pero el empresario que está leyendo esto necesita entender por qué afirmo que en casos donde Duriva ha presentado peritaje contra un banco, no hemos perdido.
No es porque los bancos sean incompetentes. Los bancos tienen equipos jurídicos formidables. Tienen presupuestos de litigio que exceden lo que cualquier PYME puede invertir. Tienen peritos propios. Tienen estrategias de defensa pulidas durante décadas.
Es porque su defensa tiene un punto ciego estructural. Y ese punto ciego es siempre el mismo: el banco solo analiza sus propios sistemas. Y sus propios sistemas funcionaron correctamente. Lo que no analiza es el lado del usuario. Y el lado del usuario es donde está la evidencia del fraude.
Cuando Duriva presenta un peritaje en un caso de transferencia no reconocida, lo que presentamos es exactamente lo que el banco no investigó:
Si hay troyano, lo encontramos. Lo identificamos por nombre, familia, variante. Documentamos su fecha de instalación, su método de operación, su objetivo específico. Demostramos que estaba activo en la fecha de las transferencias fraudulentas. Demostramos que tenía la capacidad técnica de capturar credenciales bancarias. Y presentamos esa evidencia con hash SHA-256, cadena de custodia y todos los requisitos del 210-A.
Si hay SIM swapping, obtenemos el registro de la compañía telefónica que documenta el cambio de SIM no autorizado. Contrastamos la hora del cambio de SIM con la hora de las transferencias. Demostramos que en el momento de la operación, el segundo factor de autenticación estaba en posesión del atacante, no del titular.
Si hay envenenamiento DNS, auditamos el router. Documentamos la configuración alterada. Identificamos los servidores DNS maliciosos. Verificamos que esos servidores están asociados a actividad fraudulenta en bases de datos de amenazas. Demostramos que toda la red de la empresa estaba comprometida.
Si hay phishing dirigido, analizamos el correo. Rastreamos los headers. Identificamos el servidor de origen. Documentamos la página clonada. Demostramos que las credenciales fueron capturadas a través de un engaño que el usuario promedio no podía detectar.
Y en cada caso, la conclusión del peritaje es la misma: las credenciales del titular fueron comprometidas por un ataque informático. La persona que ejecutó las transferencias no era el titular. Las credenciales eran correctas porque fueron robadas, no porque el titular las proporcionara voluntariamente.
Esa conclusión, sustentada con evidencia técnica verificable, le dice al juez algo que la carta de rechazo del banco nunca va a decir: el banco tiene razón en que las credenciales eran correctas. Pero está equivocado en que eso significa que el titular autorizó la operación.
Las credenciales correctas no prueban autorización. Prueban posesión de las credenciales. Y la posesión se puede obtener por robo.
El momento de la audiencia: lo que pasa cuando el perito del banco enfrenta evidencia real
Voy a ser franco con algo que he visto repetirse en cada audiencia donde hemos enfrentado al perito de un banco: el perito del banco no está preparado para una contrapericial que va más allá de los logs del portal.
Lo digo con respeto profesional. Lo digo porque es la realidad que he documentado caso tras caso, año tras año. El perito del banco hace un trabajo competente dentro del alcance que le asigna el banco: verificar que las credenciales eran correctas, que la IP coincidía, que el token fue validado. Eso está bien hecho. No lo cuestiono.
Lo que cuestiono — y lo que cuestiona el juez cuando ve la evidencia comparada — es que eso sea suficiente para concluir que el titular autorizó la operación.
Cuando en audiencia se presenta el peritaje de Duriva documentando el troyano bancario que estaba activo en la computadora del usuario, el perito del banco no tiene respuesta. Porque nunca analizó esa computadora. Cuando se presenta la evidencia del SIM swapping con la hora exacta del cambio de SIM, el perito del banco no tiene respuesta. Porque nunca verificó el estatus de la línea telefónica del usuario. Cuando se presenta la auditoría del router mostrando los DNS envenenados, el perito del banco no tiene respuesta. Porque nunca examinó el router.
Y cuando el juez le pregunta al perito del banco: «¿Usted verificó si la computadora del usuario tenía malware?» y la respuesta es «no.» Y le pregunta: «¿Usted verificó si hubo un cambio de SIM card en la línea telefónica del usuario?» y la respuesta es «no.» Y le pregunta: «¿Usted auditó la red del usuario?» y la respuesta es «no.» El juez entiende algo fundamental: el banco investigó solo lo que le convenía investigar. Y lo que no investigó es precisamente donde estaba la evidencia del fraude.
Un dictamen incompleto que se presenta como conclusivo no solo es insuficiente — es contraproducente para el banco. Porque demuestra que el banco no buscó la verdad. Buscó confirmar su propia narrativa.
Preguntas frecuentes
Recibí la carta de rechazo del banco. ¿Tengo que ir a CONDUSEF primero o puedo demandar directamente?
Puede demandar directamente. CONDUSEF no es un requisito previo para iniciar un juicio. Sin embargo, muchos abogados recomiendan pasar por CONDUSEF primero porque genera un expediente administrativo que documenta que usted reclamó y el banco se negó. Ese expediente puede fortalecer la narrativa de que usted actuó con diligencia. Pero no pierda meses esperando una resolución de CONDUSEF mientras la evidencia en su computadora y su router se degrada. Preserve la evidencia desde el día uno. CONDUSEF puede correr en paralelo.
El banco dice que la operación fue confirmada con mi token. ¿Eso no demuestra que fui yo?
No. El token demuestra que alguien ingresó el código correcto. No demuestra quién lo ingresó. Si hubo SIM swapping, el código llegó al atacante. Si hubo man-in-the-browser, el usuario confirmó una operación diferente a la que se ejecutó. Si hubo pharming, el usuario ingresó el token en una página falsa y el atacante lo usó en la real. En los tres escenarios, el token fue «validado correctamente» según los logs del banco. Y en los tres escenarios, fue un fraude.
Ya formateé la computadora. ¿Perdí el caso?
No necesariamente, pero sí se debilitó significativamente. La evidencia más contundente — el troyano, los procesos en memoria, los registros del navegador — probablemente se perdió. Sin embargo, no todo está perdido: los logs del router pueden preservarse independientemente, los registros de la compañía telefónica siguen disponibles, los correos de phishing pueden estar en el servidor de correo, y los logs del banco pueden solicitarse judicialmente para análisis más detallado. Cada caso es diferente. Lo que no debe hacer es asumir que ya no tiene caso sin consultar a un perito.
¿Cuánto cuesta el peritaje forense? ¿Vale la pena si me robaron menos de un millón?
El costo del peritaje es una fracción de lo que está en juego. Piénselo así: si el banco le debe millones y el peritaje cuesta una fracción de eso, la matemática se hace sola. Y si le robaron menos de un millón, el cálculo sigue siendo el mismo: ¿qué porcentaje de ese monto representa el peritaje? En la mayoría de los casos, es un porcentaje menor. Lo que no puede cuantificar es el costo de no hacerlo: el banco se queda con su dinero y usted se queda con la carta de rechazo.
El banco me ofrece devolver un porcentaje si firmo un convenio. ¿Debo aceptar?
Esa decisión es jurídica y debe tomarla con su abogado. Lo que puedo decirle desde la perspectiva técnica es lo siguiente: si el banco le ofrece un convenio, es porque su departamento jurídico evaluó que hay riesgo de perder el juicio. Los bancos no devuelven dinero por generosidad. Devuelven dinero cuando el costo de perder el juicio es mayor que el costo del convenio. Si le están ofreciendo pagar, es porque saben algo que usted todavía no sabe: que la evidencia probablemente no los favorece.
El banco dice que usted autorizó la transferencia. Su única evidencia es que las credenciales eran correctas y la IP coincidía. Eso prueba que alguien usó sus credenciales desde su red. No prueba que ese alguien fuera usted.
La carta de rechazo no es un veredicto. Es la primera jugada del banco. Y es una jugada predecible, repetitiva, diseñada para que usted se rinda. Funciona en la mayoría de los casos porque la mayoría de los empresarios no saben que hay un camino técnico para demostrar lo contrario.
Ahora usted lo sabe.
La evidencia está en su computadora, en su router, en los registros de su compañía telefónica, en los correos que recibió, en la configuración de su red. Esa evidencia demuestra que sus credenciales fueron robadas por un ataque informático y que la persona que ejecutó las transferencias no era usted.
Pero esa evidencia tiene fecha de vencimiento. Cada día que pasa, cada reinicio de la computadora, cada formateo del disco, cada cambio de router, destruye una pieza del rompecabezas que puede ganarle el juicio al banco.
En Duriva, llevamos 17 años armando ese rompecabezas. Más de 1,300 peritos formados. Récord invicto contra bancos en casos de transferencias no reconocidas. No porque tengamos suerte. Porque sabemos dónde buscar lo que el banco no quiere que encuentres.
La carta de rechazo dice que fue usted. La evidencia forense dice que no. Y cuando las dos versiones se presentan frente a un juez, la evidencia gana.
Siempre gana.