ESMA designa a Etrading Software para la cinta consolidada de derivados OTC: El verdadero reto está por venir

El supervisor europeo quiere que las entidades financieras dejen de notificar incidentes como si cada una viviera en su propio planeta. Ese es el mensaje real del movimiento más reciente de ESMA: poner en consulta los borradores de directrices sobre el intercambio de información entre autoridades competentes dentro del marco de DORA. Suena técnico. Lo es. Pero también toca un nervio bastante terrenal: qué datos se comparten, cuándo, con qué formato y para qué demonios sirven una vez salen de la entidad.

La consulta no cambia todavía las obligaciones materiales de notificación para las entidades. Lo que hace es intentar ordenar la trastienda supervisora. Y no es un detalle menor. Si una firma reporta un incidente grave y la información acaba circulando entre supervisores nacionales, autoridades europeas y, en determinados casos, otras autoridades relevantes, la utilidad del sistema depende menos del titular regulatorio y más de algo mucho menos glamuroso: que todos entiendan lo mismo cuando leen el mismo reporte.

Aquí está el quid. DORA ha vendido —con razón— la idea de una disciplina más uniforme sobre resiliencia operativa digital. Pero la uniformidad no se logra aprobando un reglamento y esperando un milagro administrativo. Se logra afinando los mecanismos de intercambio, los formatos, la clasificación y el uso posterior de la información. Justo el tipo de trabajo que nunca genera aplausos y casi siempre determina si una norma funciona o se queda en una presentación de PowerPoint.

Qué ha puesto ESMA sobre la mesa

ESMA ha lanzado una consulta sobre el borrador de directrices para la cooperación y el intercambio de información entre autoridades competentes en relación con incidentes graves relacionados con las TIC y, cuando proceda, ciberamenazas significativas notificadas por entidades financieras bajo DORA. La base jurídica no está improvisada: DORA prevé el régimen de notificación de incidentes en sus disposiciones sobre gestión, clasificación y reporte de incidentes, y encomienda el desarrollo de estándares y marcos de cooperación supervisora.

El punto regulatorio relevante para el lector no es solo que exista una consulta. Es que el foco está en la circulación de la información una vez la entidad ya ha cumplido con su obligación de reportar. En otras palabras: menos teoría sobre si hay que notificar y más detalle sobre cómo se mueve esa notificación por el ecosistema supervisor. Ese matiz importa porque cambia la conversación interna en las entidades. Ya no basta con “cumplir y enviar”; hay que asumir que la calidad, estructura y consistencia del reporte condicionan cómo será interpretado por varias autoridades, no por una sola.

Si gestionas compliance, ciberseguridad o riesgos operacionales en una entidad financiera, esto te afecta por una razón simple: el reporte de incidentes deja de ser una pieza aislada y pasa a integrarse en una red de lectura supervisora más amplia. Lo que escribas en una notificación inicial puede ser reutilizado, contrastado o compartido más allá de la relación bilateral con tu supervisor nacional.

Por qué esto importa más de lo que parece

La regulación europea tiene una vieja afición por anunciar armonización y descubrir después que cada autoridad, cada sector y cada entidad arrastran definiciones, umbrales y prácticas heredadas. DORA intenta corregir parte de eso con un marco directamente aplicable. Pero incluso un reglamento necesita instrucciones de funcionamiento cuando entran en juego múltiples supervisores.

En este caso, la cuestión delicada no es solo la notificación del incidente, sino la gobernanza del dato regulatorio sobre el incidente. Quién lo recibe. Quién puede reutilizarlo. En qué circunstancias se comparte. Y cómo se evita que la cadena de transmisión convierta un incidente técnico en un ejercicio de interpretación creativa.

ESMA no está descubriendo América. Está intentando cerrar una de las grietas habituales del diseño regulatorio europeo: la distancia entre obligación formal y ejecución coordinada. Si una autoridad nacional recibe una notificación sobre un incidente grave con posible impacto transfronterizo, el valor de esa información depende de que otras autoridades la reciban a tiempo y de forma utilizable. Parece obvio. A veces lo obvio necesita veinte páginas de directrices para empezar a comportarse como tal.

También hay una derivada política. Cuando Bruselas habla de resiliencia digital, no está pensando solo en la estabilidad de una entidad concreta, sino en el riesgo sistémico, la supervisión convergente y la capacidad de respuesta coordinada. Un incidente TIC serio en una entidad relevante puede interesar al supervisor prudencial, al de mercados, al banco central o a otras autoridades con mandato sectorial. DORA, precisamente, se diseñó para reducir la fragmentación que convertía esos flujos en algo demasiado dependiente de la costumbre local.

Lo que no dice ESMA —y conviene no fingir que ha dicho

Aquí merece la pena limpiar el ruido. El comunicado y la documentación asociada sostienen que hace falta un marco de cooperación y de intercambio de información entre autoridades. Eso sí está. Lo que no conviene hacer es atribuir a ESMA afirmaciones categóricas que no aparecen expresamente en su comunicación pública.

Por eso hay que ser precisos. Puede inferirse que un modelo supervisor con múltiples receptores exige datos comparables y reportes operativamente útiles. Pero presentar como hecho establecido por ESMA diagnósticos cerrados sobre la calidad histórica de los campos, la consistencia de los formularios o la integridad de los reportes sería ir más allá de lo que la fuente permite afirmar de forma directa. En regulación financiera, ese salto entre “se deduce” y “el supervisor sostiene” es justo donde empiezan los problemas.

No es un tecnicismo periodístico. Es una diferencia material. Si el regulador denuncia una disfunción concreta, las entidades pueden anticipar presión supervisora inmediata sobre ese punto. Si solo articula un mecanismo de coordinación, la señal es más estructural: preparad procesos y gobierno del dato para un entorno de intercambio más exigente, aunque el comunicado no venga acompañado de una reprimenda explícita.

DORA no se juega solo en la notificación, sino en la trazabilidad del proceso

Buena parte del debate público sobre DORA se ha concentrado en pruebas de resiliencia, gestión de terceros TIC, gobernanza y reporting de incidentes. Normal: son los bloques más visibles. Pero la eficacia del régimen depende también de algo menos fotogénico, la trazabilidad del proceso de notificación y circulación de información.

DORA establece obligaciones sobre gestión, clasificación y notificación de incidentes relacionados con las TIC, incluyendo marcos para determinar cuándo un incidente es grave y cómo debe reportarse a las autoridades competentes. Ese diseño obliga a las entidades a tener criterios internos reproducibles, registros fiables y capacidad de escalar información desde equipos técnicos hasta funciones de compliance y dirección sin perder precisión por el camino.

Si el flujo supervisor se vuelve más estructurado, la exigencia práctica para las entidades también sube. No necesariamente porque el reglamento cambie hoy, sino porque se reduce el margen para reportar con ambigüedades internas que luego “ya se explicarán”. Cuando hay varias autoridades potencialmente leyendo o reutilizando la información, cada campo dudoso cuesta más. Y cada incoherencia entre la notificación inicial y las actualizaciones posteriores se vuelve más visible.

¿Tu entidad tiene ya resuelto ese punto? No hablo de tener una policy bonita. Hablo de algo bastante menos decorativo: taxonomías internas alineadas, ownership claro de cada dato del incidente, revisión legal antes de la remisión y capacidad para reconstruir por qué se clasificó como grave o no grave. Eso sí es resiliencia operativa. Lo demás es teatro corporativo con presupuesto.

El cruce con NIS2 y GDPR: el viejo problema de múltiples relojes regulatorios

Donde esta consulta se vuelve realmente interesante es en su roce con otros regímenes de notificación. Las entidades financieras no viven dentro de una urna llamada DORA. También pueden verse afectadas por obligaciones bajo GDPR cuando un incidente implique violación de datos personales y, en ciertos supuestos, por marcos nacionales que transpongan NIS2 para entidades alcanzadas por esa directiva.

La comparación útil aquí no consiste en mezclar artículos al azar para sonar contundente. Consiste en recordar que los relojes regulatorios no siempre miden lo mismo. GDPR art. 33 obliga a notificar a la autoridad de control las violaciones de seguridad de los datos personales sin dilación indebida y, de ser posible, a más tardar en 72 horas desde que el responsable tenga constancia de ellas. Ese reloj se activa por un criterio distinto al de un incidente TIC grave bajo DORA: no basta con que haya un fallo tecnológico; tiene que haber una brecha de seguridad de datos personales que cumpla el umbral aplicable.

Con NIS2 pasa algo parecido, pero con otro mapa conceptual. El art. 21 se centra en las medidas de gestión de riesgos de ciberseguridad. Las obligaciones de notificación de incidentes, con su esquema temporal específico, se recogen en el art. 23. Dicho de forma menos diplomática: citar el artículo 21 para hablar de plazos de notificación es mezclar el índice con el contenido. Y en un entorno donde los equipos de cumplimiento ya trabajan con calendarios simultáneos, esa confusión no es inocua.

La consecuencia operativa es evidente. Una misma crisis técnica puede obligarte a responder preguntas distintas bajo marcos distintos: si el incidente es grave a efectos de DORA, si afecta a datos personales a efectos de GDPR art. 33 y 34, y si encaja en obligaciones de notificación de ciberincidentes bajo el régimen nacional derivado de NIS2, según el tipo de entidad y el ámbito subjetivo aplicable. No es duplicidad pura; es solapamiento con lógicas diferentes. Y ese solapamiento castiga a las organizaciones que siguen separando ciberseguridad, privacidad y cumplimiento regulatorio como si no se hablaran entre sí.

Qué deberían hacer ahora las entidades financieras

La reacción sensata a esta consulta no es entrar en pánico ni archivarla en la carpeta de “cosas que ya verá Regulatory Affairs”. Hay cuatro tareas bastante concretas que merecen atención inmediata.

• Revisar el modelo de datos del incidente. Si tu organización reporta con información repartida entre tickets técnicos, correos, hojas de cálculo y narrativas manuales, ya vas tarde. El supervisor no necesita tu épica interna; necesita datos coherentes y trazables.
• Alinear clasificación jurídica y técnica. El incidente que SecOps describe de una forma y compliance traduce de otra acaba generando fricción, retrasos y rectificaciones. DORA exige disciplina en la clasificación y esa disciplina no aparece por generación espontánea.
• Mapear obligaciones paralelas. Cruza DORA con GDPR art. 33 y 34, y con las obligaciones de notificación que resulten aplicables bajo la transposición nacional de NIS2, en particular el art. 23 sobre reporte de incidentes. Si no tienes una matriz clara de detonantes, destinatarios y tiempos, el día del incidente improvisarás. Y casi siempre se improvisa peor de lo que se presume.
• Ensayar el circuito de escalado. No solo el técnico. También el decisorio. Quién valida la gravedad, quién aprueba la notificación, quién consolida actualizaciones, quién gestiona inconsistencias entre versiones y quién responde cuando la autoridad pide aclaraciones.

Esto tiene una lectura menos obvia, pero más útil: la consulta de ESMA refuerza la idea de que la notificación regulatoria es ya un proceso de producción de información supervisora, no un mero trámite de cumplimiento. Cambia la exigencia cultural. Y obliga a tratar el dato del incidente con el mismo cuidado que el dato financiero que termina en manos del supervisor.

La tentación de leer esto como burocracia sería un error

Siempre aparece el mismo comentario cuando salen directrices de cooperación o intercambio de información: más procedimiento, más papel, más Bruselas afinando tornillos. A veces esa crítica acierta. Otras veces confunde el síntoma con la enfermedad.

En resiliencia operativa, la coordinación entre autoridades no es un capricho administrativo. Es la condición mínima para que una notificación sirva para algo más que llenar un repositorio. Si un incidente relevante queda encapsulado en una sola relación supervisor-entidad, el sistema aprende poco y reacciona tarde. Si la información circula sin criterios comunes, aprende mal. La consulta de ESMA intenta moverse entre esos dos fracasos bastante europeos: el silo y el caos.

La pregunta útil no es si habrá más trabajo. Claro que lo habrá. La pregunta es si ese trabajo mejora la capacidad real de detección, comparación y respuesta supervisora. Y la respuesta probable es sí, siempre que las directrices terminen aterrizando en prácticas consistentes y no en una nueva capa de formulismos mal integrados con las obligaciones ya existentes.

La lectura de fondo: menos margen para la ambigüedad

Si hubiera que resumir la señal regulatoria en una frase, sería esta: el ecosistema supervisor europeo quiere menos ambigüedad en cómo se comparte la información sobre incidentes TIC relevantes. No porque adore la pulcritud documental, sino porque la resiliencia operativa sin información comparable es una promesa vacía.

Para las entidades, eso significa algo bastante concreto. El listón ya no está solo en detectar el incidente y cumplir el plazo. Está en poder explicar, sostener y actualizar el contenido del reporte en un entorno donde varias autoridades pueden depender de esa misma información. La era del “ya lo aclararemos después” nunca fue una gran estrategia. Bajo DORA, cada vez lo parece menos.

ESMA no ha lanzado una bomba política. Ha hecho algo más serio: trabajar sobre la fontanería del sistema. Y cualquiera que haya visto cómo fallan de verdad los marcos regulatorios sabe que, al final, casi todo depende de la fontanería.