DORA
La EBA despeja el perímetro del FRTB, pero el problema ya no es jurídico: es de datos, controles y resiliencia
22 min lectura
Imagen generada por IALa EBA ha hecho algo poco glamuroso y muy útil: el 3 de agosto de 2026 publicó una no-action letter sobre la frontera entre banking book y trading book y añadió aclaraciones técnicas sobre el acto delegado de la Comisión que modifica el cálculo de requerimientos de fondos propios por riesgo de mercado bajo el FRTB. Traducido al castellano de comité: menos margen para interpretaciones creativas, menos riesgo de implementaciones nacionales dispares y, sobre el papel, menos ansiedad regulatoria para la banca europea.
Pero conviene no confundir claridad normativa con sencillez operativa. La parte jurídica de la discusión se ha afinado. La parte difícil sigue intacta. Cuando una entidad reconfigura la frontera entre carteras, no está tocando solo una etiqueta contable o prudencial. Está tocando motores de cálculo, taxonomías de datos, reconciliaciones entre front office y finanzas, flujos de aprobación, inventarios de modelos, controles de cambio y dependencias tecnológicas que, si fallan, ya no son un simple problema de mercado. Bajo DORA, pueden convertirse en un problema de resiliencia operativa. Bajo NIS2, en un problema de gestión de riesgos y gobernanza. Bajo GDPR, en un problema secundario si ciertos datasets o registros operativos contienen datos personales. Y bajo el creciente apetito supervisor por la IA en finanzas, también en un problema de explicabilidad y validación si parte de la clasificación, vigilancia o detección de anomalías se automatiza.
Aquí está el quid: la EBA ha reducido la incertidumbre regulatoria sobre el perímetro. Ahora sube la presión sobre la ejecución. Y esa ejecución no la resuelve un memo legal. La resuelven datos buenos, controles que de verdad funcionan y una arquitectura operativa que no se venga abajo cuando cambias una regla de clasificación y el impacto corre por veinte sistemas a la vez.
Tesis editorial
La clarificación de la EBA es una buena noticia, pero también elimina la coartada favorita de muchas entidades: “estábamos esperando más certezas regulatorias”. Ya las tienen, al menos en una parte material del problema. A partir de aquí, el riesgo pasa de ser interpretativo a ser industrial.
Y eso importa porque el FRTB nunca ha sido solo una reforma de capital. Es una reforma de datos, de procesos y de disciplina operativa. La frontera entre banking book y trading book afecta a la asignación de posiciones, al tratamiento de instrumentos, al modelo de cálculo y a la trazabilidad de decisiones. Si la entidad no puede demostrar por qué una posición está donde está, quién aprobó ese encaje, qué reglas se aplicaron, qué excepciones existen y qué controles evitan arbitrajes internos, no tiene un problema académico. Tiene un problema supervisor, de auditoría y potencialmente de resiliencia.
La ironía es bastante evidente. Durante años, el debate se presentó como una discusión técnica para especialistas en riesgo de mercado. En 2026 ya no cuela. La implantación del FRTB, especialmente en lo relativo a perímetros y criterios de clasificación, se ha convertido en un caso de manual sobre cómo una exigencia prudencial termina chocando con DORA, con el gobierno del dato y con la necesidad de controlar automatizaciones cada vez más complejas. No porque la norma lo diga en un titular, sino porque la realidad operacional de un banco funciona así.
Qué ha dicho exactamente la EBA y por qué sí cambia el tablero
La pieza relevante salió el 3 de agosto de 2026. La EBA anunció una carta de no actuación y consideraciones técnicas para apoyar la implantación del marco de riesgo de mercado en bancos de la UE. El foco estaba en la frontera entre banking book y trading book y en cuestiones vinculadas al acto delegado de la Comisión Europea que modifica el cálculo de los requerimientos de fondos propios por riesgo de mercado con base en el FRTB.
La clave de una no-action letter no está en el dramatismo del nombre, sino en su función práctica. El supervisor europeo está diciendo a autoridades y entidades que, ante determinadas fricciones de implementación, no va a forzar de inmediato una aplicación rígida que genere más incoherencia que seguridad jurídica. Es un instrumento de transición y coordinación. No sustituye la ley, no reescribe el CRR, pero sí orienta la supervisión y reduce el riesgo de que cada jurisdicción o cada equipo supervisor improvise una lectura distinta.
En la práctica, esto importa por tres razones.
La primera es la comparabilidad. Si dos bancos con posiciones parecidas acaban tratándolas de forma distinta por diferencias interpretativas, el marco prudencial pierde legitimidad y los ejercicios de benchmarking se vuelven mucho menos útiles. No es casualidad que la propia EBA mantenga abierta desde el 17 de julio hasta el 3 de septiembre de 2026 una consulta para modificar las ITS del ejercicio de benchmarking de riesgo de mercado de 2027. Si quieres comparar modelos y resultados, primero necesitas que el perímetro sea razonablemente consistente.
La segunda es la planificación de capital. El FRTB no es una reforma ornamental. Cambia sensibilidades, metodologías y potencialmente el consumo de capital de determinadas carteras. Una zona gris prolongada sobre qué va a trading y qué va a banking complica presupuestos, hedging, apetito de riesgo y estrategia comercial. La banca puede vivir con una regla dura. Lo que gestiona mucho peor es una regla incierta.
La tercera es menos visible y más decisiva: la clarificación normativa baja el margen para justificar fallos internos de implementación. Cuando el regulador no había terminado de aterrizar los detalles, muchas ineficiencias podían presentarse como prudencia. En 2026, con la EBA emitiendo guía técnica y con la presión supervisora creciendo, esa defensa pierde fuerza. Si tus datos están mal reconciliados o tus controles de clasificación siguen dependiendo de correos y hojas de cálculo, el problema ya no es Bruselas. El problema eres tú.
El perímetro es una decisión prudencial, pero se ejecuta como un problema de datos
La frontera entre banking book y trading book parece una cuestión doctrinal hasta que aterriza en sistemas. Entonces aparece la factura real. Cada posición necesita atributos completos y coherentes: naturaleza del instrumento, intención de tenencia, uso de cobertura, liquidez, desk owner, tratamiento contable, fuente de precios, modelo aplicable, reglas de elegibilidad y evidencias de aprobación. Si cualquiera de esos campos falla, la clasificación se resiente. Si fallan varios, el banco deja de tener un proceso y pasa a tener una colección de parches.
Esto no es una exageración periodística para darle picante al asunto. Es la consecuencia natural de cualquier reforma prudencial que dependa de taxonomías de datos distribuidas en múltiples plataformas. En una entidad mediana o grande, la información relevante para esta frontera rara vez vive en un solo sitio. Está fragmentada entre sistemas de front office, repositorios de operaciones, herramientas de medición de riesgo, motores de capital, libro mayor, plataformas de colateral y repositorios históricos. Añade filiales, adquisiciones heredadas y proveedores externos, y la promesa de “implementación armonizada” adquiere un tono casi cómico.
Por eso la reacción inteligente a la carta de la EBA no es celebrar que ya hay más claridad. Es preguntarse algo bastante más incómodo: ¿puedo demostrar de extremo a extremo cómo una posición entra en una cartera, qué regla la clasifica, qué control detecta una anomalía y qué evidencia queda para auditoría y supervisor?
Si la respuesta es “más o menos”, hay trabajo serio pendiente. Y no solo en riesgo de mercado. También en gobierno del dato.
Las entidades que mejor van a absorber esta fase no son necesariamente las que tienen los modelos más sofisticados, sino las que han resuelto cuatro cosas muy concretas:
Un diccionario de datos común entre riesgo, finanzas, tesorería y tecnología, con campos críticos definidos de forma unívoca.
Reglas de clasificación versionadas, con trazabilidad de cambios y aprobación formal.
Controles preventivos y detectivos sobre entradas incompletas, inconsistencias de mapeo y reclasificaciones excepcionales.
Capacidad de reconciliar resultados entre sistemas fuente y cálculo regulatorio sin depender de intervención manual masiva.
No hay misterio. Tampoco atajos elegantes.
Donde entra DORA: el FRTB ya no puede implantarse como un silo de riesgo
DORA aplica desde el 17 de enero de 2025. En 2026 ya no es un proyecto; es una obligación viva para entidades financieras sujetas al Reglamento (UE) 2022/2554. Y eso cambia la conversación. Un cambio material en procesos de clasificación, cálculo y reporting que depende de sistemas críticos, reglas automatizadas, flujos de datos y terceros TIC no puede tratarse como si fuese solo un entregable de regulación prudencial.
Hay varios artículos de DORA que importan aquí de forma muy directa.
El artículo 5 exige un marco de gestión del riesgo TIC gobernado por el órgano de dirección. Si la implantación de la frontera FRTB requiere cambios en sistemas críticos de riesgo y reporting, esos cambios deben entrar en el perímetro de gobierno y supervisión interna, no quedarse enterrados en un programa técnico opaco para el consejo.
El artículo 8 obliga a identificar, clasificar y documentar adecuadamente las funciones empresariales, los activos de información y las dependencias TIC. Si una entidad no sabe qué aplicaciones, interfaces, procesos manuales y proveedores participan en la clasificación de carteras y en el cálculo asociado, su mapa de dependencias está incompleto. Y un mapa incompleto, en DORA, no es una incomodidad metodológica. Es una debilidad de control.
El artículo 9 trata de protección y prevención; el 10, de detección; el 11, de respuesta y recuperación; y el 12, de copia de seguridad y restauración. ¿Qué tiene que ver esto con riesgo de mercado? Más de lo que parece. Si el banco automatiza reglas de clasificación o integraciones de datos para cumplir FRTB y no asegura monitorización, gestión de incidencias, capacidad de reversión y pruebas de restauración, cualquier fallo en producción puede alterar cálculos regulatorios, afectar reporting y generar una cascada de correcciones manuales. El riesgo no es solo de disponibilidad. También de integridad.
Y luego está el artículo 28, probablemente el más incómodo para muchas entidades porque se refiere a la gestión del riesgo derivado de terceros proveedores de servicios TIC. Si parte de la arquitectura de cálculo, almacenamiento, reconciliación o monitorización descansa en proveedores cloud, plataformas de datos o software especializado, la entidad debe tener inventario contractual, evaluación de criticidad, derechos de acceso y auditoría, y capacidad de salida. El FRTB no te exime de eso. Al contrario: lo vuelve más urgente porque multiplica la criticidad de ciertas piezas tecnológicas.
La conclusión es bastante simple. El supervisor prudencial te está diciendo cómo quiere que interpretes una frontera regulatoria. DORA te exige que demuestres que la maquinaria que ejecuta esa interpretación es gobernable, resiliente y controlable. Una cosa sin la otra ya no basta.
NIS2 no aplica por simpatía, pero su lógica de gobernanza sí está empujando el mercado
NIS2, la Directiva (UE) 2022/2555, no se superpone mecánicamente con DORA porque esta última actúa como régimen sectorial específico para servicios financieros. Aun así, pensar que NIS2 no importa a la banca porque “ya tenemos DORA” es una lectura perezosa.
El artículo 21 de NIS2 fija medidas de gestión de riesgos de ciberseguridad que incluyen análisis de riesgos, gestión de incidentes, continuidad de negocio, seguridad de la cadena de suministro, seguridad en adquisición y desarrollo de sistemas, políticas para evaluar la efectividad de las medidas y prácticas básicas de ciberhigiene. Ese catálogo no desaparece porque una entidad financiera esté principalmente bajo DORA; marca el tono regulatorio general europeo y afecta especialmente a grupos con entidades no financieras, proveedores tecnológicos y cadenas de suministro compartidas.
Si un grupo bancario usa centros de servicios comunes o proveedores que también caen bajo NIS2, las exigencias de seguridad, registro de incidentes, cadena de suministro y validación de controles se contagian operativamente. No por ósmosis legal, sino por simple arquitectura corporativa. Lo que pasa en una filial tecnológica o en un proveedor crítico termina impactando en la calidad y disponibilidad de datos regulatorios.
Además, NIS2 ha reforzado la responsabilidad de la alta dirección y la necesidad de formación específica. DORA hace algo parecido. El mensaje combinado para 2026 es bastante claro: ya no vale delegar todos estos cambios en segunda línea y esperar que salgan bien solos. Si el consejo aprueba programas regulatorios sin entender dependencias tecnológicas, calidad del dato y exposición a terceros, el regulador va a asumir que el problema es de gobierno, no solo de ejecución.
El riesgo más subestimado: controles manuales que siguen vivos donde nadie quiere mirarlos
La banca europea ha avanzado mucho en automatización de riesgo y reporting. También sigue conviviendo con un zoológico de soluciones manuales que aparecen justo en los puntos más delicados: excepciones, ajustes de fin de mes, mapeos históricos, validaciones ad hoc y “controles compensatorios” que sobreviven porque nadie se atreve a quitarlos sin romper otra cosa.
La clarificación de la EBA sobre la frontera banking book/trading book presiona precisamente esos puntos. Cuando cambias criterios, afloran las excepciones. Cuando afloran las excepciones, reaparecen los ficheros paralelos. Y cuando reaparecen los ficheros paralelos, el banco descubre que parte de su cumplimiento depende todavía de una combinación explosiva de conocimiento tácito, macros antiguas y aprobaciones por correo.
No hace falta dramatizar. Tampoco conviene blanquearlo. Ese patrón genera al menos cinco riesgos operativos muy concretos:
Reclasificaciones inconsistentes entre líneas de negocio o geografías.
Pérdida de trazabilidad sobre quién cambió qué y con qué fundamento.
Errores de integridad al mover datos entre hojas de cálculo, herramientas de reconciliación y motores regulatorios.
Dependencia de personas clave que concentran conocimiento no documentado.
Retrasos en cierres y reporting si las validaciones manuales escalan con el volumen.
Si esto te suena a un problema clásico de control interno, acertaste. Pero en 2026 ya no basta con llamarlo “riesgo operacional residual” y pasar página. DORA exige monitorización, respuesta y pruebas. Los revisores internos y externos van a pedir evidencias. Y la EBA, cuando publica simplificaciones y aclaraciones, no lo hace para que las entidades respondan con más artesanalidad, precisamente.
IA en la clasificación, validación y vigilancia: útil, sí; dejarla sin correa, no
El 31 de julio de 2026, la EBA, EIOPA y ESMA pidieron reforzar la gobernanza y la supervisión coherente para mitigar riesgos TIC derivados de la IA de frontera. Ese mensaje no venía de un seminario filosófico. Venía de reguladores que ya están viendo cómo la automatización basada en IA entra en procesos críticos de entidades financieras y proveedores.
En el caso del FRTB y de la frontera entre banking book y trading book, la IA puede aparecer en varios puntos: clasificación asistida de instrumentos, detección de anomalías en asignaciones, vigilancia de inconsistencias, priorización de alertas, reconciliaciones complejas o análisis de impacto de cambios normativos sobre reglas de negocio. Usarla no es una herejía. Hacerlo sin controles, sí.
El riesgo más evidente es la opacidad. Si un modelo de aprendizaje automático sugiere clasificaciones o detecta excepciones, la entidad debe poder explicar con suficiente detalle qué variables usa, cómo se valida su rendimiento, qué sesgos o límites se conocen y cuándo interviene una revisión humana. Si ese modelo influye en decisiones con impacto prudencial, la trazabilidad no es opcional.
Aquí convergen varias piezas regulatorias. DORA exige gestión del riesgo TIC, pruebas y gobernanza. El AI Act europeo, aplicable de forma progresiva según los tipos de sistemas y obligaciones, añade capas de exigencia para sistemas de alto riesgo y prácticas de gobierno del modelo cuando proceda. NIS2 empuja sobre seguridad del ciclo de vida. Y la propia lógica prudencial exige validación independiente cuando una herramienta automatizada afecta al tratamiento regulatorio de posiciones o al control de calidad de datos.
Mi lectura es bastante sencilla: si una entidad quiere meter IA en estos procesos, debería como mínimo imponer cinco controles no negociables.
Registro formal del caso de uso, propietario, objetivo y sistemas afectados.
Validación previa al despliegue con métricas de precisión, falsos positivos y falsos negativos por tipo de instrumento o regla.
Umbrales de intervención humana obligatoria en reclasificaciones sensibles o fuera de patrón.
Versionado del modelo, de los datos de entrenamiento y de las reglas de negocio asociadas.
Pruebas periódicas de deriva, explicabilidad operativa e impacto en reporting regulatorio.
No suena futurista. Suena aburrido. Esa es una buena señal. En banca, la IA útil rara vez es la que impresiona en la demo; suele ser la que aguanta auditoría.
Impacto regulatorio cruzado
La noticia nace en el terreno prudencial, pero sus consecuencias prácticas se mueven por varias normas a la vez. Si una entidad se queda en la lectura “esto es FRTB y nada más”, se estará perdiendo la mitad del problema.
DORA: de la norma al sistema que la ejecuta
Ya citado, pero conviene aterrizarlo. DORA no te pide calcular capital; te pide que los sistemas, procesos y terceros que soportan funciones críticas sean resilientes. Si el FRTB depende de plataformas críticas, la entidad tiene que demostrar inventario, pruebas, gestión de cambios, monitorización y recuperación. Artículos 5, 8, 9, 10, 11, 12 y 28 son especialmente relevantes.
NIS2: gobernanza y cadena de suministro
El artículo 21 de NIS2 no sustituye DORA en finanzas, pero refuerza la expectativa europea sobre seguridad del desarrollo, gestión de riesgos, continuidad y cadena de suministro. Esto pesa mucho cuando el programa FRTB usa proveedores comunes, servicios compartidos o piezas tecnológicas fuera del perímetro bancario estricto.
GDPR: no es el eje, pero puede aparecer donde menos se espera
Muchos datos de posiciones y riesgo de mercado no son personales. Aun así, en la implantación real aparecen registros de usuario, trazas de aprobación, correos, incidencias, identificadores de empleados, incluso datos de clientes en ciertas investigaciones operativas o muestras de validación. Si una incidencia de integridad o una fuga afecta a esos elementos, entran en juego el artículo 5 del GDPR sobre principios de tratamiento, el artículo 25 sobre protección de datos desde el diseño y por defecto, el artículo 32 sobre seguridad del tratamiento y, si hay violación de seguridad de datos personales, los artículos 33 y 34 sobre notificación.
La trampa habitual es pensar que un programa de riesgo regulatorio vive fuera del radar de privacidad. No siempre. Y basta con una mala práctica de extracción de datos a entornos no controlados para que el problema aparezca.
AI Act: si automatizas decisiones o controles, prepárate para gobernarlos
No toda herramienta analítica usada en finanzas cae automáticamente en la categoría más exigente del AI Act, pero la dirección regulatoria es inequívoca: más transparencia, más documentación, más control humano y más responsabilidad sobre calidad de datos y rendimiento. Si la IA participa en clasificación, alertado, validación o priorización con efecto material sobre procesos prudenciales, el equipo de compliance debería mapear ya el caso de uso frente al régimen aplicable. Esperar a que llegue la pregunta del supervisor no es una estrategia sofisticada; es dejar que te pillen sin deberes.
NIST CSF 2.0: una brújula útil para ordenar el caos
NIST CSF 2.0 no es derecho europeo, pero sí una estructura muy útil para ordenar la respuesta operativa. Sus funciones de Govern, Identify, Protect, Detect, Respond y Recover encajan sorprendentemente bien con los retos de esta implantación. No por moda anglosajona, sino porque obliga a conectar gobierno, activos, controles, detección y recuperación. Justo lo que suele romperse cuando el FRTB se gestiona como un proyecto de cálculo y no como un cambio empresarial de extremo a extremo.
Lo que deberían hacer ahora riesgo, compliance, CISO y auditoría interna
No hace falta inventarse una gran transformación teórica. Hace falta ejecutar cuatro líneas de trabajo con bastante disciplina y poca retórica.
La primera es rehacer el mapa de proceso completo desde la clasificación inicial hasta el reporting final. No un PowerPoint amable para el comité, sino un mapa operativo con sistemas fuente, reglas aplicadas, puntos de control, excepciones, dependencias manuales, interfaces y terceros implicados. Si la entidad ya lo tiene, mejor. Si no lo tiene, va tarde.
La segunda es identificar qué controles son realmente preventivos y cuáles solo descubren el desastre cuando ya ha ocurrido. En muchos bancos, la respuesta incómoda es que la prevención está sobreestimada y la detective depende de conciliaciones tardías. Bajo un marco tan sensible al dato como el FRTB, eso es una invitación al retrabajo y a los hallazgos de auditoría.
La tercera es revisar la gobernanza de cambios. Cada ajuste de regla sobre frontera, elegibilidad o tratamiento de instrumentos debería dejar huella: justificación, versión, fecha, aprobador, pruebas ejecutadas, impacto esperado, plan de reversión y evidencia de despliegue. Si el banco no puede reconstruir el historial, la discusión con supervisión se vuelve desagradablemente corta.
La cuarta es someter el proceso a pruebas operativas serias. No solo pruebas funcionales del motor de cálculo. También pruebas de resiliencia: caída de interfaz, corrupción de campo crítico, retraso de proveedor, error de mapeo, regla mal desplegada, recuperación desde respaldo y validación post-restauración. Si suena a DORA, es porque lo es.
El reparto de papeles también debe madurar. Riesgo de mercado no puede cargar con todo. Compliance debe mapear implicaciones normativas cruzadas. El CISO y el equipo de resiliencia deben entender qué activos y procesos son críticos. Tecnología tiene que garantizar integridad y trazabilidad. Auditoría interna, por su parte, haría bien en anticiparse: esta es una zona perfecta para revisar diseño y eficacia de controles antes de que lo haga el supervisor.
Implicaciones para entidades financieras españolas
Para bancos españoles y grupos con presencia relevante en la UE, la señal de la EBA tiene un doble efecto. Por un lado, reduce el espacio de interpretación local sobre una cuestión que afecta a comparabilidad europea. Por otro, aumenta la presión sobre la coordinación interna entre funciones que históricamente no siempre han trabajado con el mismo reloj: riesgo prudencial, finanzas, tecnología, seguridad y cumplimiento.
El Banco de España y el ecosistema supervisor español llevan tiempo elevando el tono sobre gobernanza del dato, externalización tecnológica y resiliencia operativa. En ese contexto, la carta de la EBA no debería leerse como una nota técnica lejana de París o Bruselas, sino como una señal bastante concreta para revisar cómo se está aterrizando el cambio en cada entidad.
En España hay además un factor práctico que pesa mucho: la coexistencia de infraestructuras heredadas con programas ambiciosos de modernización y migración a cloud. Esa mezcla puede ser eficiente, pero también crea zonas de fricción precisamente donde el FRTB exige coherencia de extremo a extremo. Si parte del dato nace en sistemas antiguos, se transforma en plataformas intermedias y acaba en motores regulatorios más modernos, el banco necesita disciplina de integración, no fe.
También hay que mirar a aseguradoras y a grupos mixtos con prudencia. Aunque la noticia es bancaria y el FRTB es un asunto de banca, la lógica operativa de gobernanza de datos, terceros TIC e IA afecta al conjunto de servicios financieros. El error más común en grupos diversificados es dejar que cada vertical resuelva sola problemas que en realidad comparten raíz tecnológica.
Lo que esta clarificación no resuelve, y por qué conviene decirlo sin adornos
La carta de la EBA ayuda. No hace magia.
No arregla por sí sola la calidad del dato. No elimina las debilidades de legado. No reduce automáticamente el coste de cumplimiento. No garantiza que todas las autoridades nacionales lean igual cada borde del marco. Tampoco convierte un modelo de gobierno deficiente en uno robusto por el simple hecho de haber recibido más guía técnica.
Hay además un riesgo de lectura complaciente: asumir que una no-action letter significa relajación supervisora prolongada. Sería una mala apuesta. Normalmente estos instrumentos buscan facilitar una transición ordenada, no institucionalizar ambigüedad ni regalar años extra de improvisación. A medida que las aclaraciones maduren y el marco se estabilice, la tolerancia hacia implementaciones débiles tenderá a bajar, no a subir.
Otro punto delicado es el sesgo de foco. Cuando se publica una aclaración sobre perímetro, muchas entidades concentran energía en el criterio jurídico y dejan para más adelante la ingeniería del control. Error clásico. El supervisor puede aceptar temporalmente ciertas fricciones interpretativas; lo que suele aceptar peor son fallos de gobernanza, evidencia insuficiente o dependencia excesiva de procesos manuales sin compensaciones reales.
Y luego está el pequeño detalle de la carga acumulada. En 2026, las entidades financieras europeas no están implantando una sola gran pieza regulatoria cada vez. Están gestionando DORA en régimen vivo, NIS2 en ecosistema, exigencias de IA cada vez más tangibles, agenda ESG y simplificaciones prudenciales de la EBA, incluidas las revisadas guías SREP anunciadas el 26 de junio de 2026 y otras iniciativas de eficiencia del marco de capital comunicadas el 16 de junio de 2026. La prioridad no puede ser tratar cada norma como un proyecto aislado. Ese modelo ya no escala.
La pregunta que deberían hacerse los consejos
Los consejos de administración suelen recibir este tipo de temas en formato higienizado: “actualización sobre implementación regulatoria”, dos semáforos verdes, tres riesgos moderados y un cierre optimista. En 2026 eso es insuficiente.
La pregunta útil para un consejo no es si la entidad “está siguiendo” las aclaraciones de la EBA. La pregunta útil es esta: si mañana el supervisor nos pide evidencias sobre clasificación de carteras, calidad del dato, cambios de reglas, dependencia de terceros y resiliencia del proceso, ¿podemos enseñarlas sin montar una operación de rescate interna?
Si la respuesta es no, el programa necesita atención ejecutiva real. No por miedo escénico, sino porque el cruce entre regulación prudencial y resiliencia tecnológica ya se ha convertido en una expectativa de gestión ordinaria. Esa es la novedad de fondo. No tanto la frontera entre libros, sino la frontera entre disciplinas internas. Antes se podían gestionar por separado. Ahora no.
La conclusión incómoda: se acabó esconder un problema operativo detrás de una duda normativa
La EBA ha hecho su parte al reducir incertidumbre sobre la frontera entre banking book y trading book en el despliegue del FRTB. Y eso, visto el historial europeo de ambigüedades útiles pero agotadoras, no es menor. Aporta coherencia, facilita comparabilidad y permite planificar mejor.
Pero también deja al descubierto algo menos cómodo. Muchas entidades ya no pueden atribuir sus retrasos o debilidades a una falta de señal regulatoria suficiente. La señal existe. Lo que falta en varios casos es musculatura de datos, control y resiliencia.
Ése es el verdadero ángulo de 2026. El debate relevante ya no es solo dónde acaba el banking book y empieza el trading book. El debate relevante es si tu banco puede ejecutar esa frontera con sistemas fiables, reglas trazables, controles resistentes y gobierno capaz de soportar escrutinio supervisor. Si no puede, la clarificación de la EBA no es un alivio. Es un espejo.