Un artículo identificó el potencial conflicto entre los enfoques de modelado de XBRL y la Metodología de Puntos de Datos (DPM). Sin embargo, ningún análisis estaría completo sin examinar por qué la Autoridad Bancaria Europea (EBA) y la Autoridad Europea de Seguros y Pensiones de Jubilación (EIOPA) optaron por utilizar DPM y luego traducirla a una taxonomía XBRL, en lugar de comenzar directamente con XBRL.
Aún faltan algunas funcionalidades, muchas de las cuales están incluidas en el plan de trabajo del Modelo de Información Abierta (OIM) de XBRL International, pero algunas, como el control de versiones, aún no se han abordado.
Otra conclusión clave es que parece no haber incentivos para que los proveedores de software desarrollen el tipo de herramientas de modelado de datos que necesitan los grandes autores de taxonomías XBRL.
Analizar los requisitos clave de los grandes marcos de información, como los de EBA CRD y EIOPA Solvencia, y evaluar el estado de las especificaciones XBRL para cumplirlos y permitir que XBRL proporcione capacidades de gestión de datos maestros para los marcos de información.
Beneficios y problemas de XBRL
Las especificaciones XBRL están diseñadas para admitir una amplia gama de aplicaciones de informes de información empresarial en todo el mundo. Actualmente existen más de doscientos marcos de informes XBRL importantes basados en este estándar abierto, una gran comunidad de expertos y un número creciente de proveedores de software.
Una de las fortalezas de los estándares XBRL, además del núcleo común, es su independencia, lo que permite a los diseñadores de taxonomías XBRL elegir las especificaciones que deseen utilizar. Sin embargo, su debilidad radica en que el desarrollo como especificaciones independientes implica una escasa interoperabilidad entre ellas.
Esto resulta especialmente notorio para los desarrolladores de grandes marcos de informes. Para comprender mejor los problemas específicos, conviene revisar los comentarios de la EBA durante sus recientes presentaciones sobre DPM 2.0, también conocida como la «Renovación de DPM». La EBA defendió la profundización en el uso de DPM frente a un enfoque XBRL más estandarizado. La diapositiva siguiente muestra un ejemplo de cómo comparan DPM con XBRL.
Muchas de las observaciones de la EBA están sesgadas debido a su decisión de basar su sistema interno de almacenamiento de datos en DPM. En nombre de la comunidad XBRL, replicamos lo siguiente:
- La taxonomía XBRL generada por las herramientas DPM carece de una guía semántica clara para las definiciones, ya que se compone de pocos conceptos de alto nivel y se subdivide en numerosas dimensiones. Por ejemplo, existe un único concepto global para «activos», mientras que la taxonomía IFRS contempla muchos tipos de activos que son subconjuntos del concepto más amplio. La taxonomía de la Directiva sobre Riesgo de Crédito (CRD) de la EBA es un modelo de alta dimensionalidad. Si bien es útil para los sistemas informáticos, resulta deficiente para facilitar la comprensión del lector, lo cual es fundamental para la transmisión de requisitos en sistemas de información heterogéneos.
- El proceso DPM también genera numerosas reglas de bajo nivel para verificar la calidad de los datos, en lugar de una regla semántica de alto nivel, como «todos los totales deben sumar». Verificar la coherencia de un volumen tan grande de reglas DPM de bajo nivel (alrededor de 8000) de forma automatizada resulta bastante dudoso.
- Muchas de las diferencias citadas en la diapositiva de la EBA están relacionadas con la implementación específica, por lo que cuestiones como la integración y los identificadores invariantes solo existen en la percepción de cada uno.
El problema del control de versiones es real. XBRL incluye una versión básica y directrices de buenas prácticas para documentar las diferencias entre versiones, pero nada más. En contraposición, la afirmación de la EBA de que DPM admite el registro histórico de conceptos se basa en su implementación propietaria de DPM. Si XBRL pretende proporcionar algún tipo de gestión de datos maestros para grandes sistemas de informes, el control de versiones es fundamental. Sin embargo, cabe destacar que el intercambio de datos tiene requisitos de control de versiones diferentes a los de los sistemas de análisis de datos, como se explicará con más detalle más adelante, pero este requisito es importante para todos los sistemas XBRL.
La EBA también planea adoptar el nuevo Modelo de Información Abierta (OIM) de XBRL y, en particular, el formato xBRL-CSV para la presentación de informes, con el fin de reducir su tamaño. Sin embargo, en lugar de centrarse en mejorar el diseño y el rendimiento de XBRL, ha optado por utilizar una estructura CSV que emplea explícitamente el «DPM-ID», un componente del sistema de almacenamiento de datos de la EBA que, semánticamente, carece de utilidad y no contribuye a optimizar el procesamiento de XBRL. Para obtener más información sobre este enfoque y por qué consideramos que es una mala idea, consulte el artículo anterior » DPM vs XBRL».
Seguramente la EBA seguirá encontrando carencias en las herramientas de desarrollo de taxonomías necesarias para construir un modelo semántico adecuado y de fácil mantenimiento. Creemos que la iniciativa OIM representa un gran avance, pero las especificaciones XBRL independientes aún dificultan el proceso.
Por ahora, DPM funciona para la EBA y la EIOPA como un mecanismo útil para sus sistemas internos (… podrían usar XBRL mejor, pero eso es tema para más adelante). El verdadero problema que la EBA pone de manifiesto para la comunidad XBRL es que definir marcos de informes a gran escala en XBRL es un proceso en gran medida manual y complejo. Otros marcos de gran tamaño, como la taxonomía IFRS, presentan problemas similares.
Estándares OIM y Future xBRL
El Modelo de Información Abierta (o «OIM») es la iniciativa estratégica de XBRL International para simplificar y modernizar aspectos importantes del estándar XBRL, definiendo un modelo que representa su significado sin referencia a una sintaxis específica; es decir, elimina la dependencia de XML. OIM define múltiples formatos intercambiables, a los que se pueden añadir más con el tiempo.
- xBRL-CSV: condensa los datos en un formato tabular muy compacto para permitir la recopilación de grandes cantidades de datos.
- xBRL-JSON: proporciona datos XBRL en un formato más sencillo de procesar y presentar.
- xBRL-XML sigue siendo compatible con una amplia gama de requisitos de generación de informes.
Las habilidades y el esfuerzo necesarios para desarrollar reglas que permitan validar los datos (mediante fórmulas XBRL) han demostrado ser otro motivo de preocupación para los autores de taxonomías. El Consejo de Estándares XBRL (XSB) ha proporcionado recientemente una hoja de ruta para las fórmulas XBRL en un entorno OIM:
- Comenzando con la Fórmula 2.0, que eliminará la sintaxis XPath y formalizará la especificación de XF, o Fórmula basada en texto, que proporciona la misma funcionalidad que la Fórmula XBRL, pero es más rápida de escribir y más fácil de leer.
- En última instancia, el plan consiste en desarrollar una nueva especificación que abarque reglas tanto para la instancia XBRL como para la taxonomía, basándose en las nuevas especificaciones de la taxonomía OIM. Esto también implica un cambio de nombre a «Reglas XBRL 3.0» para reflejar su importancia.
Para algunos, puede resultar confuso que en XBRL exista otra forma de verificar relaciones simples entre los datos proporcionados mediante la especificación de Cálculo. Idealmente, esto debería ofrecer un mecanismo más sencillo para definir las principales comprobaciones de calidad presentes en los modelos de información financiera, como consolidaciones, proyecciones y agregaciones. La especificación de Cálculo se está actualizando y la versión 2.0 incluye capacidades de agregación dimensional. En ese caso, la fórmula XBRL se utilizaría únicamente para reglas más complejas y validaciones estructurales.
OIM mantendrá esta flexibilidad para los autores de taxonomías, pero aún deja preguntas como «¿Debería usar fórmulas o cálculos XBRL?».
- La EBA desarrolla la fórmula XBRL a partir de su notación DPM, que los usuarios empresariales definen como parte de sus plantillas de hojas de cálculo, pero que no describe las relaciones inherentes en las tablas ni utiliza cálculos para sumar jerarquías básicas.
- La taxonomía de las NIIF en la que se basa el ESEF de la Autoridad Europea de Gestión de Valores (ESMA) utiliza cálculos y fórmulas, pero no tablas. En los marcos de «información abierta» como el ESEF, el emisor desarrolla sus propias estructuras de tablas. Un modelado deficiente de estas estructuras implica que, con frecuencia, se omiten cálculos o que estos solo se incluyen parcialmente en la taxonomía, lo que genera numerosos problemas de calidad de los datos.
Entonces, ¿es suficiente OIM? Creemos firmemente que la comunidad XBRL debe reflexionar más a fondo sobre cómo los hipercubos, las tablas, los cálculos y las fórmulas pueden trabajar juntos para ayudar a crear mejores modelos XBRL.
Gestión de grandes marcos de informes
Si se va a utilizar XBRL para modelar sistemas de recopilación de datos a gran escala, entonces debemos retomar algunas de las cuestiones fundamentales planteadas por la EBA, la EIOPA y las autoridades nacionales competentes europeas, que no solo implementan la recopilación de informes de la EBA y la EIOPA de miles de bancos y compañías de seguros europeas, sino que también los extienden a los requisitos de información locales.
Desarrollo y mantenimiento de la taxonomía
El modelado de datos es, sin duda, la decisión más importante para un equipo de informes de datos. Determina la arquitectura y el rumbo que seguirá el proyecto. Modelar conjuntos de datos grandes y complejos siempre ha planteado decisiones y desafíos a los diseñadores.
Las grandes taxonomías XBRL (diccionarios de datos) pueden hacer referencia a otras taxonomías XBRL (extensibles) como bloques de construcción y pueden separarse en numerosos puntos de entrada, cada uno con múltiples definiciones de tabla o ELR, lo que facilita el modelado de las partes individuales. Esto ayuda, pero no es suficiente para ayudar realmente a los diseñadores a desarrollar un modelo semántico «bueno» y de alto rendimiento y gestionarlo a lo largo del tiempo, ni incentiva a los desarrolladores a crear el tipo de herramientas que apoyarían a los diseñadores en este proceso, como, por ejemplo:
- La especificación de dimensiones XBRL se utiliza para definir hipercubos, mientras que las bases de enlace de tabla pueden usar las dimensiones y vincularse a hipercubos. Sin embargo, cada base de enlace de tabla debe especificarse de forma independiente, es decir, codificarse. Más código implica más desarrollo y mantenimiento. ¿Por qué no es posible generar una especificación de base de enlace de tabla directamente desde el hipercubo de informes? Esto incentivaría a los diseñadores de taxonomías a reflexionar detenidamente sobre la estructura del hipercubo y las tablas.
- La especificación Table Linkbase define una capa de presentación tabular para la representación. Sin embargo, no proporciona aritmética tabular sencilla, como totales de filas, totales de columnas o subtotales. Esta idea de «agregación dimensional» ya se había propuesto anteriormente y ha resurgido en Calculations 2.0. El diseñador podría usar código de fórmulas hoy en día, como muestra EBA, pero si el proceso se automatiza y forma parte del modelo subyacente, se reduce el código y los diseñadores de taxonomías serán más estructurados en sus diseños de tablas.
- Los diseñadores están claramente interesados en los formatos xBRL-CSV y xBRL-JSON. La incorporación de algunas ideas sencillas para facilitar la creación y gestión de definiciones a lo largo del tiempo reduce el código y centra la atención en el modelo:
o Método para la generación directa de xBRL-CSV a partir de definiciones de tablas e hipercubos.
o Vinculación bidireccional de definiciones de Table Linkbase y xBRL-CSV.
o Representación directa de datos xBRL-CSV en tablas definidas en Table Linkbase.
Creemos que la incorporación de estas funciones sencillas garantiza que las especificaciones XBRL se vinculen de forma más coherente y eficaz, lo que permite «reunificar» los módulos de especificación individuales. Podríamos denominarlo «gestión maestra de informes», lo que sugiere una manera más estructurada y metódica de desarrollar una taxonomía, en lugar de utilizar una amalgama de herramientas diferentes.
Control de versiones
Con el tiempo, todos los marcos de informes evolucionarán y cambiarán a medida que sea necesario actualizar los elementos, la arquitectura, las reglas y las especificaciones utilizadas.
Para la mayoría de los proyectos XBRL que implican el intercambio de información empresarial, esto es suficiente. Sin embargo, no existe una especificación técnica que permita que el software actualice automáticamente los sistemas de la versión antigua a la nueva de la taxonomía.
La visión de la EBA sobre el control de versiones es mucho más profunda. Buscan revisar cuándo se hizo referencia por primera vez a un concepto (punto de datos), cuándo se modificó y cuándo se dejó de usar, además de registrar quién realizó el cambio y por qué. Por lo tanto, su visión se asemeja mucho más a la gestión de datos maestros, donde se recopilan metadatos del modelo para poder revisarlo.
- Cabe señalar que la EBA genera confusión al afirmar que «…(XBRL) no puede manejar la evolución de un punto de datos entre versiones, lo que los hace inadecuados para análisis de series temporales. Creemos que esto confunde los sistemas de recopilación con los sistemas de análisis. Los sistemas de análisis requieren un enfoque diferente, ya que los datos de origen llegan a través de múltiples flujos de datos, deben transformarse y almacenarse de una manera específica para que sean eficientes para el análisis, como el de series temporales. En los sistemas de recopilación, el problema radica en cómo facilitar a los remitentes la identificación de los datos que deben recopilar, cómo verificar su validez y cómo optimizar el proceso de transferencia. Estos dos objetivos pueden entrar en conflicto, razón por la cual la mayoría de las organizaciones separan ambos sistemas.
Las ventajas que ofrece XBRL de un modelo de taxonomía más detallado y del versionado de elementos son:
- Proporcionar un método estandarizado para que los proveedores de XBRL actualicen los materiales asociados con una versión más reciente de la taxonomía ayudaría significativamente a reducir los costos para los proveedores y, por lo tanto, para los usuarios.
- Comprender cómo han cambiado las definiciones y reglas de los datos a lo largo del tiempo proporciona información de fondo importante para el análisis y la toma de decisiones operativas.
La importancia de esto para la mayoría de los proyectos XBRL es cuestionable, pero para marcos de informes complejos y de mayor envergadura, sin duda facilitaría su gestión. Cabe mencionar que añadir el control de versiones a XBRL es una tarea compleja que requeriría un caso práctico real como guía.
Rendimiento de validación de grandes conjuntos de datos
Siempre ha existido preocupación por el tiempo de procesamiento de informes extensos; simplemente, el tamaño de lo que se considera un archivo de datos «grande» ha aumentado exponencialmente. Cualquier prueba de rendimiento dependerá del entorno en el que se ejecute; es decir, si se le proporciona a un programa más memoria y mayor rendimiento de CPU, debería ejecutarse más rápido. Por lo tanto, la pregunta debería reformularse como «¿Está funcionando de manera eficiente?» para que sea escalable.
Al analizar el rendimiento en marcos de informes extensos, como la Directiva CRD de la EBA y la Solvencia de la EIOPA, los problemas suelen presentarse con conjuntos de datos basados en registros, expresados como tablas abiertas. Una tabla abierta es aquella que contiene un número ilimitado de filas, columnas u hojas. El formato de registro o los datos transaccionales suelen organizarse en una fila por registro; es decir, varios datos relacionados se agrupan en una fila. En otras tablas, que contienen relativamente pocos puntos de datos agregados, el rendimiento siempre ha sido bueno para la mayoría de los procesadores XBRL.
La especificación xBRL-CSV se desarrolló específicamente para abordar los problemas derivados de grandes conjuntos de datos basados en registros. En primer lugar, comprime los datos, lo que reduce el tamaño de los archivos de informe y facilita su transmisión. En segundo lugar, si la estructura CSV sigue el formato de tabla, es decir, según su formato de registro, los datos se pueden leer como filas, lo que proporciona una agrupación natural de los datos asociados y mejora significativamente el rendimiento de las fórmulas XBRL en tablas abiertas de gran tamaño.
Esto supone una enorme mejora del rendimiento con respecto a xBRL-XML, donde dichas tablas se expresan como un único hecho por fila y un procesador XBRL debe «reagrupar» las filas individuales, lo que obliga a procesadores como XPE de UBPartner a emplear un «optimizador» para determinar la mejor manera de agrupar y filtrar los datos para una fórmula determinada.
Tenga en cuenta que, al combinar grandes conjuntos de datos con numerosas comprobaciones de calidad de datos de bajo nivel, como las creadas con el DPM de la EBA, se observa un aumento en los tiempos de procesamiento. Lamentablemente, el enfoque propuesto por la EBA para la recopilación de datos CRD en xBRL-CSV no resulta útil, ya que ha decidido, por primera vez, introducir completamente la notación DPM directamente en el modelo XBRL mediante el siguiente formato fijo xBRL-CSV:
DPM_ID, Valor, Unidad.
Esto es similar al modelo xBRL-XML, donde un hecho por línea se añade una búsqueda adicional utilizando el «DPM-ID» semánticamente vacío como clave en el archivo CSV. Esta indirección, desde el punto de vista de las autoridades nacionales competentes y los remitentes locales, no ofrece ninguna ventaja. En cambio, limita el rendimiento de la validación y dificulta la conversión entre otros formatos.
La incorporación de capacidades semánticas, como la aritmética tabular, al modelo subyacente ayuda a los procesadores XBRL a comprender la estructura de los datos con los que trabajan, y luego se pueden formalizar los «optimizadores» para mejorar el rendimiento en función de los datos y su estructura.
Lo anterior también debe vincularse con la especificación del Indicador de Archivo XBRL, que proporciona un mecanismo para ayudar a dividir grandes conjuntos de datos en secciones lógicas más pequeñas. Estas secciones lógicas pueden vincularse tanto a tablas como a conjuntos de fórmulas. Poder identificar las subsecciones apropiadas de los datos y sus construcciones taxonómicas asociadas permite a los procesadores XBRL:
- Reducción del alcance de las fórmulas y los cálculos, que actualmente se dirigen al conjunto completo de datos.
- Oportunidad de dividir el procesamiento en operaciones más pequeñas, que utilizan un subconjunto del modelo y los datos, y que tienen el potencial de procesarse de forma independiente.
Mejoras en la fórmula XBRL
La capacidad de integrar reglas de validación en una taxonomía es una de las características más potentes de XBRL para el intercambio de datos y la clave para mejorar su calidad. Actualmente, como ya se ha comentado, disponemos de dos métodos: Cálculos y Fórmulas XBRL. El primero es sencillo y fácil de implementar, pero limitado, mientras que las Fórmulas XBRL ofrecen muchas más funcionalidades, pero son difíciles de desarrollar, ya que están vinculadas a XML. Además, un diseñador de una taxonomía «abierta», como ESMA ESEF o US GAAP, no puede actualmente escribir reglas para verificar la extensión de la taxonomía creada por el emisor.
En respuesta al problema anterior, XBRL US ha desarrollado su propio sistema de reglas (DQR) con una tecnología diferente, XULE. Si bien esto ofrece una solución inmediata, no contribuye a la estandarización en toda la comunidad XBRL.
Como se mencionó anteriormente, XSB anunció recientemente la Fórmula 2.0, eliminando la dependencia de XML y formalizando el uso de XF (fórmulas basadas en texto). XBRL Rules 3.0 planea romper definitivamente con las especificaciones existentes y se espera que se base en gran medida en la experiencia adquirida con XBRL US. Esto debería ser de gran ayuda para los diseñadores de taxonomías y facilitar la definición de reglas de negocio de calidad para verificar el documento de instancia y cualquier extensión de taxonomía.
Además, XBRL Europe ha reconocido que la arquitectura DPM de la EBA y la EIOPA presenta ciertas características específicas con tres modelos en uno: puntos de datos, plantillas y dimensiones semánticas, que requieren un puente para facilitar la transición a las nuevas funcionalidades de XBRL. Por ello, ha creado un grupo de trabajo para revisar «XF-DPM», que ayudaría a traducir las reglas DPM a fórmulas XBRL y, posiblemente, mejoraría el rendimiento de las fórmulas XBRL resultantes. Sin embargo, seguiría presentando el inconveniente de definir «controles de calidad de datos» a nivel de punto de datos, lo que generaría muchos de ellos, en lugar de utilizar la semántica integrada en un modelo XBRL dimensional.
Conclusiones
XBRL continúa creciendo y admitiendo una gama cada vez más amplia de marcos de informes. OIM es un paso crucial para garantizar el futuro al admitir formatos alternativos; sin embargo, el XSB también debe centrarse en recomendaciones que simplifiquen y reduzcan el consumo de recursos para diseñar y desarrollar una taxonomía XBRL coherente y de alto rendimiento.
Cuando la EBA y la EIOPA iniciaron su andadura con XBRL, este sistema les proporcionó un método estandarizado para recopilar los datos necesarios para supervisar su mercado. Sin embargo, XBRL carecía de las funcionalidades necesarias para modelar los datos, por lo que utilizaron DPM como herramienta de modelado. Actualmente, existen pocos incentivos para modificar esta configuración y, de hecho, la propuesta de la EBA para la modernización de DPM consiste en orientar el marco de presentación de informes hacia la arquitectura de DPM.
La comunidad XBRL debe ofrecer este incentivo. El XSB ha proporcionado OIM y el formato XBRL-CSV, además de presentar propuestas importantes para la actualización de las fórmulas. Sin embargo, esto no satisface la necesidad de que XBRL sirva de base para un sistema de gestión de informes maestros. Asimismo, implica que los proveedores tienen pocos incentivos para ofrecer las herramientas que ayuden a las autoridades nacionales competentes, del mismo modo que la EBA y la EIOPA están desarrollando sus propios sistemas de gestión de datos utilizando DPM.
La visión de OIM debe ampliarse a:
- Reunificar el conjunto de especificaciones.
- Armonización de dimensiones/tablas/especificaciones de la colección.
- Agregar funcionalidad de control de versiones.
Lamentablemente, la definición de estándares requiere tiempo para alcanzar un consenso y, posteriormente, para desarrollar las especificaciones. La comunidad XBRL se basa en la colaboración de voluntarios, por lo que es fundamental que el trabajo sea relevante y priorizado para obtener beneficios tangibles en un plazo realista. Los autores sugieren comenzar por ampliar la hoja de ruta de OIM para que usuarios y desarrolladores tengan una visión más clara de los desarrollos futuros y sirva de guía a organismos como la EBA y la EIOPA.