Lo que DORA exige revisar tras el robo a Crédit Mutuel Arkéa a través de un proveedor

El dinero que se llevaron de Crédit Mutuel Arkéa no salió de las cuentas de sus clientes, sino de una cuenta del propio banco. Según las respuestas que publicó la entidad el 4 de noviembre, los atacantes llegaron al grupo bancario a través de la plataforma de uno de sus proveedores y, desde ahí, ordenaron transferencias a otros bancos. Al día siguiente, la entidad cifró la pérdida en unos 100 millones de euros, según Reuters; hasta entonces solo había validado «el orden de magnitud» de la cifra de 118 millones de euros (133 millones de dólares) publicada en la prensa.

Ese detalle cambia el lugar donde hay que mirar. Los controles antifraude de un banco, igual que los de toda empresa con una tesorería relevante, suelen vigilar sobre todo los canales de los clientes: inicios de sesión extraños, beneficiarios nuevos, importes atípicos. Los pagos que emite la entidad como ordenante, por canales que un proveedor opera o conecta, parten de una presunción de confianza. Y DORA, el reglamento europeo de resiliencia operativa digital, no admite que esa confianza quede sin revisar.

Este artículo resume lo que se sabe del caso, lo que DORA exige cuando la vía de entrada es un tercero y los controles que una entidad española sujeta al reglamento puede comprobar ya, sin esperar al informe forense de Arkéa.

¿Qué se sabe y qué no del ataque a Crédit Mutuel Arkéa?

Crédit Mutuel Arkéa es un grupo bancario cooperativo con sede en Bretaña, con más de 5,8 millones de clientes y 211.500 millones de euros en activos, según Help Net Security. En sus respuestas a preguntas frecuentes el banco explica que los atacantes usaron una cuenta del grupo para enviar transferencias a otros bancos, donde el dinero pudo convertirse en criptoactivos. Las cuentas de los clientes de sus federaciones y filiales no intervinieron, y el banco sostiene que sus saldos no se han visto afectados.

La entidad describe el incidente como un ataque sofisticado venido del exterior y descarta un error humano interno. Sus sistemas detectaron rápido la actividad sospechosa, activó sus procedimientos de crisis y suspendió de forma temporal algunas operaciones, lo que retrasó transferencias de clientes. Ha informado al Banco Central Europeo, a los supervisores bancarios franceses y a la fiscalía, según Reuters. La unidad de cibercrimen de la fiscalía de París abrió una investigación tras recibir la denuncia, y la ACPR, el supervisor bancario francés, declinó hacer comentarios.

La alerta inicial no la dio el banco. El investigador de cadenas de bloques ZachXBT avisó en su canal de Telegram del robo a una entidad europea, sin nombrarla, y después identificó a Arkéa. Según su rastreo, recogido por Help Net Security, el 1 de noviembre salieron más de 106 millones de dólares de varias cuentas en plataformas de intercambio de criptomonedas, y el 3 de noviembre informó de otros 27 millones. Los fondos salieron como USDC y USDT, se cambiaron por ether y una parte acabó en Monero. ZachXBT descarta, por los indicadores de blanqueo, que sea obra de Lazarus. El banco no ha confirmado esas cifras al detalle.

Queda mucho por saber. Arkéa no ha dicho quién es el proveedor ni qué servicio presta, y la prensa francesa que apuntó a otra vía de entrada recibió un desmentido del banco, como recoge The Record. Tampoco se sabe cómo se obtuvo el acceso a la plataforma del proveedor ni cuánto tiempo estuvo abierto. Lo que sigue no especula sobre esos puntos: parte de los hechos que el banco ha confirmado.

¿Qué exige DORA cuando la vía de entrada es un proveedor?

DORA (Reglamento (UE) 2022/2554) se aplica desde el 17 de enero de 2025 a bancos, aseguradoras, empresas de inversión, entidades de pago y otros actores financieros. Su capítulo sobre riesgo de terceros parte de una idea sencilla: externalizar el servicio no externaliza la responsabilidad. El artículo 28.1 dice que la entidad financiera sigue siendo plenamente responsable del cumplimiento de todas sus obligaciones aunque use servicios TIC de terceros.

El artículo 30 baja esa idea al contrato. Todo acuerdo con un proveedor TIC debe incluir, entre otras cosas, la obligación del proveedor de prestar asistencia a la entidad sin coste adicional, o con un coste fijado de antemano, cuando sufra un incidente relacionado con el servicio, y la de cooperar plenamente con las autoridades competentes. Si el servicio sostiene una función esencial o importante, el contrato debe fijar además plazos de aviso y obligaciones de información del proveedor hacia la entidad, y derechos de acceso, inspección y auditoría.

El segundo bloque afecta a la notificación. Un incidente es grave cuando afecta a servicios críticos y, además, hay un acceso malicioso no autorizado que puede causar pérdida de datos o se superan dos o más umbrales de los previstos en el Reglamento Delegado (UE) 2024/1772. Uno de ellos es el impacto económico, que se cumple cuando los costes y pérdidas superan o pueden superar los 100.000 euros.

Una vez clasificado como grave, el Reglamento Delegado (UE) 2025/301 da cuatro horas desde la clasificación para la notificación inicial, sin pasar nunca de 24 horas desde que la entidad tuvo conocimiento del incidente. El informe intermedio llega a las 72 horas de esa notificación, y el final, un mes después del último informe intermedio.

No consta públicamente si Arkéa ha clasificado el incidente como grave a efectos de DORA ni qué ha notificado. Para entender las obligaciones sirve la estructura. Si el proveedor por el que entró el atacante presta un servicio TIC en el sentido del artículo 3.21, forma parte del perímetro que la entidad debe gobernar. La notificación del incidente no depende de esa calificación, y su plazo máximo se cuenta desde que la entidad tiene conocimiento del incidente, no desde que sabe por dónde entró el atacante.

¿No vigila ya el antifraude esos pagos?

Solo en parte, aunque en muchas organizaciones el argumento suena sensato. El antifraude analiza las transferencias, el proveedor tiene certificaciones y auditorías, y el contrato ya incluye una cláusula de seguridad. Desde esa óptica, el capítulo de terceros de DORA se percibe como un ejercicio documental, centrado en el registro de información y en los contratos de nube.

El argumento tiene una parte cierta. Ningún banco puede auditar en profundidad a cada proveedor, y la mayoría de las certificaciones exigen controles efectivos. Además, el antifraude de clientes ha mejorado mucho, empujado por la autenticación reforzada de PSD2 y por la presión de las estafas de suplantación del directivo.

Lo que falla es el alcance. Esos sistemas se diseñaron para detectar a un tercero que se hace pasar por el cliente. Cuando la orden de pago nace dentro de la entidad, firmada por un canal que el banco considera interno, muchas de esas señales no existen: la orden procede de un emisor legítimo y circula por un canal habitual hacia beneficiarios con nombres coherentes.

¿Por qué el caso Arkéa desmonta esa confianza?

Porque el dinero se movió más deprisa que la respuesta y porque la pérdida recae en la entidad aunque falle el proveedor. El precedente más citado tiene diez años. En 2016 alguien envió, desde el sistema del banco central de Bangladés, órdenes que sacaron 81 millones de dólares de su cuenta en la Reserva Federal de Nueva York, un caso que Reuters recuerda al informar de Arkéa. Entonces el dinero acabó en casinos filipinos y tardó semanas en moverse. Según los análisis de cadena publicados, en Arkéa los fondos pasaron a monedas estables y de ahí a otros criptoactivos en cuestión de horas.

Esa velocidad reduce el margen de reacción. Una parte de lo robado está bloqueada, según el banco, pero la recuperación depende de lo que se haga en las primeras horas fuera de la entidad: los bancos que recibieron las transferencias, las plataformas de intercambio y los emisores de monedas estables, que pueden congelar saldos. A 5 de noviembre, según Cryptoast, Tether había congelado 1,14 millones de dólares en USDT y Circle no había bloqueado ninguno de los USDC identificados.

ZachXBT sostiene que más de 30 millones de dólares se blanquearon antes de que el incidente fuera público y que las fuerzas de seguridad europeas podrían haberlos inmovilizado con un aviso antes. Es su hipótesis, no un hecho confirmado, pero apunta a un punto débil que pocos planes de respuesta cubren.

La tercera evidencia es jurídica y ya se ha citado: el artículo 28.1. Si el proveedor tiene un fallo y el dinero sale de la cuenta de la entidad, la pérdida y la obligación de notificar son de la entidad. Las certificaciones del proveedor ayudan a elegirlo, pero no sustituyen a los controles de la entidad sobre lo que ese proveedor puede hacer en su nombre.

Este blog ya ha tratado el otro lado de la cadena, el de los proveedores que guardan copias de datos de sus clientes y el de las credenciales de aplicación de un proveedor reutilizadas contra los inquilinos de Microsoft 365 de sus clientes. Arkéa añade algo distinto: el proveedor con capacidad para mover dinero.

¿Qué controles y evidencias revisar?

Ninguna de estas medidas requiere conocer el vector exacto del ataque a Arkéa. Todas parten de una pregunta: qué terceros pueden originar, modificar o transmitir órdenes de pago desde las cuentas propias de la entidad.

¿Cómo se identifica a los proveedores que pueden mover dinero?

Con un inventario ordenado por esa capacidad. El registro de información de DORA lista los proveedores TIC y las funciones que sostienen, pero a menudo le falta una columna: qué puede hacer cada uno con los pagos que emite la entidad. Plataformas de conexión bancaria, centros de mensajería financiera, ERP integrados con la banca, servicios de conciliación con permisos de escritura. Los que pueden emitir o alterar una orden sostienen la función de pagos, que una entidad de crédito suele calificar como esencial o importante; en ese caso, su contrato debe recoger lo que exige el artículo 30.3, aunque se firmara como un servicio de software corriente.

¿Dónde deben aplicarse los límites de pago?

En un punto que el proveedor no controle, porque si queda comprometido, todo control que dependa de él también lo está. Los límites acumulados por día y por beneficiario, la retención de pagos a beneficiarios nuevos y la doble aprobación de importes altos deben quedar fuera de su alcance. La conciliación casi en tiempo real entre lo que el proveedor dice haber enviado y lo que la cuenta registra es la segunda línea: acorta el tiempo entre la primera orden anómala y su detección.

¿Cómo deben vigilarse las sesiones del proveedor?

Con la misma atención que las de un administrador interno: origen, horario, volumen y tipo de operación de cada conexión a los sistemas de la entidad. Un análisis de comportamiento de usuarios y entidades sobre esas cuentas técnicas detecta lotes de pagos fuera de patrón, inicios de sesión desde ubicaciones nuevas o cambios en las tablas de beneficiarios. Si esa telemetría la genera el proveedor, el contrato debe asegurar el acceso a ella y su conservación.

¿Cuáles son las cláusulas del contrato que hay que probar?

Son tres, y hay que leerlas con un incidente simulado delante: el plazo en que el proveedor debe avisar de un incidente que afecte al servicio, la asistencia sin coste o con coste predefinido del artículo 30.2 y el acceso a registros y forense. Un contrato que remite a «los mejores esfuerzos» del proveedor no aguanta la primera llamada de madrugada.

¿Cubre el plan de respuesta las primeras horas fuera de la entidad?

El plan de respuesta a incidentes suele cubrir el aislamiento de sistemas y la notificación al supervisor, pero no lo que pasa fuera de la entidad en las primeras horas. En un fraude de pagos tiene que incluir también la petición de retrocesión a los bancos receptores, el contacto con las plataformas de intercambio y los emisores de monedas estables, y la denuncia temprana, con los datos de las transacciones preparados. Ensayar ese circuito en un ejercicio de mesa cuesta poco; improvisarlo puede costar parte de lo que todavía se podía congelar.

¿Cuánto cuesta no hacerlo?

La cifra que dio Arkéa marca la escala: unos 100 millones de euros, en una entidad que afirma que la pérdida no compromete su solvencia. Para una entidad mediana o una entidad de pago, una cantidad de ese orden sería un problema de supervivencia.

DORA añade la responsabilidad de la dirección. El artículo 5.2 atribuye al órgano de dirección la responsabilidad última de gestionar el riesgo TIC de la entidad, lo que incluye aprobar la política de terceros y revisarla. Cuando el supervisor pregunte por qué un proveedor con capacidad para mover dinero no tenía el nivel contractual del artículo 30.3, la respuesta no puede ser que el contrato se clasificó así hace años.

Queda la reputación. Arkéa tuvo que confirmar el ataque después de que un investigador externo lo hiciera público y desmentir informaciones sobre la vía de entrada mientras atendía la crisis. Tener preparado qué se dice, quién lo dice y cuándo forma parte del mismo trabajo, como contamos al hablar de cómo recibir un aviso externo de intrusión.

¿Cuál es la decisión que corresponde al comité?

Es una decisión de gobierno, no de herramientas: si los proveedores que pueden mover el dinero de la entidad se gobiernan con el nivel del artículo 30.3, con límites, telemetría y contrato a la altura, o siguen catalogados como software de oficina con acceso privilegiado. En Hard2bit lo trabajamos dentro de los proyectos de cumplimiento de DORA y de gestión del riesgo de terceros, y lo ensayamos con los equipos de respuesta a incidentes. El caso de Binance mostró a finales de octubre lo que pasa cuando falla el sistema que firma las salidas. Arkéa muestra lo que pasa cuando quien ordena el pago no es quien parece.

Fuentes y atribución: el caso se basa en las divulgaciones públicas de Crédit Mutuel Arkéa y en la información de medios disponible a 10 de noviembre de 2026. Las cifras de ZachXBT son estimaciones de un investigador externo que el banco no ha confirmado. La mención de la entidad no implica un fallo de seguridad en productos o servicios determinados, y el proveedor implicado no se ha identificado. Las atribuciones y cifras pueden cambiar a medida que avance la investigación judicial.

Aviso: este artículo analiza obligaciones de DORA y sus reglamentos delegados a partir de un caso público, con fines informativos. No constituye asesoramiento jurídico: la clasificación de incidentes y la calificación de las funciones dependen de cada entidad y de su supervisor.