XBRL Europe promotes standardization for all data collection systems, and that a digital data item should be described only once and then re-used across all reporting frameworks and data platforms. Therefore, we think that any regulatory reporting framework being considered by the EBA should be included within the scope of the integrated reporting review, and should include all organisations from which the EBA expects to receive regulatory data from, e.g., Credit Institutions, Investments Firms, Financial conglomerate and local country Authorities. In addition, financial and non-financial data, such as ESG, qualitative data, etc., should be in the scope of the review.
However, the above does not stop proportionality of the measures to be considered in terms of systems and costs.
In our opinion, Integrated Reporting cannot be called “integrated” If some parallel reporting for additional or specific data is not included in the standardised reporting framework, as this suggests a non-optimisation of value and cost reductions.. Hence, we believe that any reporting specific to the banking industry (EBA and ECB mandates) should be considered in the scope. This includes statistical, prudential, accounting, resolution, and compliance data, at an aggregated or a granular level, at either a European and national level. We consider that the list given in the Discussion Paper §42, is relevant, together with the review of national and ad-hoc requirements. Anti-money-laundering data collections and reports could be additionally considered.
An evolutionary approach to implementation will probably be needed, but the feasibility study must consider the full scope. Also, proportionality measures can be organised within the common scope.
The Discussion Paper covers the broad landscape for Integrated Reporting for the banking sector in Europe. Where relevant, we have provided some additional ideas or comments to complete the landscape.
In terms of the overall European Supervisory framework, we believe that the responses to this review should be shared with EIOPA and the ECB, so as to develop a shared long-term approach to regulatory collection systems across European Financial institutions.
Training / additional staff (skills)
Changes in processes
Changes needed in the context of other counterparties / third-party providers
Time required to find new solutions
Other (please specify)
We confirm the global overview.
Data Dictionary - Semantic level
Data Dictionary - Syntactic level
Data Dictionary - Infrastructure level
Data collection - Semantic level
Data collection - Syntactic level
Data collection - Infrastructure level
Data transformation - Semantic level
Data transformation - Syntactic level
Data transformation - Infrastructure level
Data exploration - Semantic level
Data exploration - Syntactic level
Data exploration - Infrastructure level
A semantic DATA DICTIONNARY allows harmonisation of definitions, gives a common meaning to uniquely named and defined business concepts, describes relationships between them and highlights interconnection of reporting requirements.
Currently, a same business concept may have various definitions according to the report it belongs to, and sometimes even in a same reporting framework. When multiple definitions are presented, they may have a different or a similar meaning. Having a common definition process and a single method of describing this at both the semantic level and for the collection system requirements is therefore a major need for all the industry involved in the data collection process.
In the past, some statistical/accounting reporting frameworks were using as their backbone a standardised group chart of account, making it easier to understand as they were based on a common “public good” with limited interpretation. As reporting requirements have proliferated, reporting concepts are often defined in silos, across a collection of various regulations, directives, or guidelines. This makes the understanding more difficult for reporting firms, and a common dictionary or taxonomy will strongly help to define common concepts. This means that existing technical XBRL taxonomies for EBA reporting should be reviewed and unified in a global semantic XBRL taxonomy.
To be fully operative, the semantic level of the Data Dictionary should respect the following conditions.
1- Have a clear and shared governance which should be defined before starting the construction of the dictionary itself. Without a semantic level coordination by a taxonomy moderator, the global benefits of an integrated reporting will be limited, as it means a functional concept may remain required extracted and processed as many times as there are various reporting frameworks.
2- Engage with all stakeholders at the earliest steps to ensure that the common dictionary to be developed is reviewed by the people that have to use it and are familiar with the impacts of specific decisions. Note; the governance of the procees would differentiate stakeholders’ levels, with regulators proposing the first common list of concepts, that banks and solution providers could later extend, considering their internal processes. .
3- Work on a scope as wide as possible (all types of reporting, all authorities involved, all countries involved), allowing continuing analysis between granular and aggregated data, and between existing and new data. Considering the important links between the banking and insurance sectors, it is important to involve the insurance point of view. EIOPA and EBA should at least share the same models and technical components. Currently, even the lists of countries and currencies differ in the two reporting collection sets.
4- Be as rationale as possible. The concepts should have a fully similar definition when used at a national level, only extensions or derivations with some new concepts should be allowed: In this case the national competent authority should be responsible for defining the link between the extension with the original concept (with an anchoring mechanism describing the transformation between the European and national levels, that would be similar to the one set up by the ESEF regulation).
5- Include multilingual labels. The concept names and definitions should be translated in the various European languages as they are the basis of all data transformation. It is important that the definitions and the linkages between concept may be understood by the various EU members. However, translation time should not delay the process and there is a need for a unique reference language to avoid misunderstanding by institutions.
6- Stay consistent in time. The dictionary must manage its history and links to older structures (versioning).
One objective is missing in the Discussion Paper: have a reporting dictionary that links each data to its regulatory requirements and reporting instructions, together with the associated breakdowns and thresholds. This means to integrate the semantic dictionary concepts in the reporting instructions (share the words between the reporting dictionary and the regulatory requirements such as ITS, RTS). In a recent study by Bank of England (https://www.bankofengland.co.uk/paper/2021/transforming-data-collection-from-the-uk-financial-sector-a-plan-for-2021-and-beyond), a part of the assumptions to tackle the burden were focused on a way to modernize the instructions and allow them to be directly transformed into machine-readable rules.
On a syntactic level, reporting rules must include threshold management, reporters' categorization and submission deadlines, including the handling of resubmissions in case of errors. Those elements must therefore be part of the dictionary, making the semantic and syntactic levels of the data dictionary tightly integrated.
The dictionary infrastructure must use technology that allows sharing, together with the appropriate rights management. It may seem challenging to address with a unique platform all the various requirements of all national competent authorities. Therefore, an open and widely used standard should be used to define and share the data dictionary. Using XBRL taxonomies and OIM could help to reach that target.
Concerning DATA COLLECTION, reporting rules are relevant to indicate the content, the format and the collection frequency. However, the rules may greatly differ from one country to another. For instance, Luxembourg nowadays has additional remittances of FINREP based on the “accounting version”; some other countries introduced separate reporting thresholds. The rules therefore need to be monitored and updated at both the European and local levels. XBRL provides the flexibility for local authorities to extend the central dictionary and to collect the data in different ways. However, the long-term goal should be to help the NCAs move towards a single common dictionary, which may require incorporation of locally required reporting elements.
The data collection rules should be visible not only to the authorities but also to the reporting firms, and this should be done in due time before the entry into application of a new regulation of a change in the regulation. The data collection concerns granular and aggregated data. The aggregated data highly depend on the characteristics of each institution; therefor, to allow this data to be collected after the data transformation step – performed by banks through their internal systems – the reporting rules must be made available in due time to reporting firms.
For most reporting firms, the management of format obligation is usually done by external IT providers. The more different formats and specificities you have, the more tools you need and the more various collection processes you must set up. A single data exchange format for all regulatory reports should simplify the reporting submission to authorities. XBRL is widely used for prudential and resolution framework, and the use should be extended to all reporting requirements for prudential, resolution and statistical frameworks. In the near future, xBRL-CSV may be used, in addition to XBRL-XML format, to collect EBA CRD4 and EIOPA Solvency 2, enabling larger, record style data sets in an efficient manner, or iXBRL for narrative reports which can then be transformed into XBRL (as for ESEF). xBRL-JSON may well be relevant in many other contexts for the publishing and exchange of information. The key is to is to define a common abstract dictionary that can be readily associated with a syntax/collection format that is flexible to the specific requirements.
To explain this point, we would like to provide some further information about the XBRL Standard. Now 20 years old, XBRL is an open, freely licensed and highly sophisticated digital reporting standard governed by XBRL International, which is a not-for-profit association with members draw from both the public and private sectors. The standards making process is consensus based, open to all members (membership is accessible to all) and subject to public feedback. The standards-making process is drawn on best practices developed by W3C and ISO. The resulting specifications are, as previously mentioned, freely licensed and open to use. At the time of writing there were 184 regulatory mandates around the world, for collecting data from a very wide range of regulated entities. XBRL International operates within an explicitly public interest purpose: to enhance the transparency and accountability of business performance by providing a global open data exchange standard.
Standards benefit from a network effect, and there is a very significant ecosystem of XBRL software and services right around the world. In Europe, in particular, there is a large and responsive set of vendors that can help ensure that regulated entities can respond effectively to XBRL-related mandates. As open standards, the barriers to entry for new actors (regulators, regulated entities, supporting vendors and professional services firms amongst others) is very low.
While already successful in terms of adoption, please note that the XBRL specifications are undergoing significant modernisation and simplification. The OIM or “Open Information Model” is an abstract representation of the semantics necessary for the representation of reports in digital form. Added to this abstract model are multiple and interchangeable formats that can be used as required. Today that is xBRL-XML, xBRL-JSON and xBRL-CSV. These formats can all represent these same facts, and each fact is tied back to the relevant XBRL taxonomy, providing a standards-based way to define or publish a sophisticated dictionary of reporting definitions, complete with multi-lingual labels, concept inter-relationships, links to authoritative literature and relevant business rules. These well-defined concepts can then be referenced in chosen syntax within specific data collections.
We would like to make the point that the OIM initiative is already proving popular with regulators around the world, simplifying analytics (xBRL-JSON) and facilitating large and even truly granular data collections (xBRL-CSV) even though, at the time of writing these specifications are still a short way from reaching recommendation status.
The next step for the OIM is “OIM Taxonomy” – the modernisation of the data definition layer, which is expected to greatly enhance concept reuse, enhance governance controls, simplify certain architectures and facilitate interchange between XBRL and other related standards.
We would urge the EBA (and ESAs more generally) to expand their liaison with XBRL International to help ensure that the OIM meets their needs, and that ESAs can maximise the benefit of a large and targeted ecosystem of expertise for reporting entities, regulators and supervisors alike.
From a syntactic point of view, XBRL allows concepts from a common dictionary to be grouped in a Table Linkbase, presenting to the users a friendly rendered view describing what should be collected in the return. Taxonomy business rules allows to adapt the rendering to the context of the reporting firm.
Regarding the choice of the format, “validations rules” are certainly a key point in the regulatory reporting, for both authorities and firms. Some formats do not embed such points and require every actor to develop its own sets of validation rules based on external documentation. This situation must be avoided. It leads to non-uniform implementation of the validations rules across the banking industry. The chosen standard should allow the development of national extensions in order to cope with national specificities, and a native way to perform the majority of the validations expected on the remittance.
DATA TRANSFORMATION is not really a step in the process, but a function. We think that sharing data transformation rules will be greatly beneficial, but it raises the question of the responsibility of the transformation. If institutions remain responsible of all data collected (granular and aggregated) and all data transformed, they should remain responsible of the transformation itself.
In that case, granular data transformation could be done on the reporting institution side only, where existing internal IT system already produce the aggregated data. If the transformation is done by the authorities, there is a possible double cost of human resources to perform these data transformation: institutions resources and authorities resources.
Additional points to consider are:
- The level of detail of calculations: including formulae for measuring the risk weighted assets?
- the cross-period transformations rules: will this need to resend the previous data?
- The time-to-market of such additional information: same time as the ITS?
The resulting costs of implementation will depend on those parameters which are not directly discussed in the Discussion Paper.
Regarding the data transformation at the syntactic level, a common standard shall be used to deal with the reporting requirements. However, even with a common language to store and share transformation rules, running those rules could have a double cost effect: institutions will still manage these data transformation on their internal system to perform regulatory fillings or monitor their aggregated data. Integrated reporting benefits are therefore more limited on this step.
Finally, a unique data transformation platform shared by institutions and authorities would not be sufficient to address all their respective needs. Some needs are indeed different between authorities and institutions. That concerns for firms: internal controls, cross-risks controls, business analysis… And for Authorities: cross-institutions analysis, some cross-reporting check… Moreover, some aggregated data will not easily be performed outside banks internal system (internal model, internal ratings…). Again, that could limit the benefits of integrated reporting for the data transformation step.
The key is to use a standard that can work at both an aggregated and granular data level, so that the specific reporting framework can adopt the most relevant approach, taking in to account the benefits and the costs.
In general, the XBRL community has found that integrated reporting principles will globally reduce reporting costs across all players in the information supply chain. The key is to be flexible and this is where XBRL is unique. The ability to extend an initial dictionary and to combine dictionaries by simply referencing the taxonomy enables the integrated reporting framework to grow in an evolutionary way, For example, with an initial unique new reporting framework (like CRR3) being developed with a new data dictionary (taxonomy); and then having additional reports integrated each year as the framework grows, i.e. reusability and extensibility are core features of an XBRL integrated reporting framework.
With some similar initiative being in progress by various authorities in Europe, we fear that each authority will define its own set of primary and final concepts, which will be quite troublesome for internationally based reporting firms. This could be a cause of higher costs.
Reusing existing technologies and open standards help to reduce implementation and reporting costs. XBRL technology is widely used by reporting firms, national authorities and other financial authorities in Europe and across the world. Developing the Integrated Reporting target on this existing technology will allow a cheaper and easier transition.
In addition, costs for reporting firms depends on the gap to be compliant to the targeted data model. A standard metadata methodology is a good basis to tackle the technical cost of any development. DPM and taxonomies a existing tools to work describe the data, in a more efficient way when using a core common dictionary at semantic and syntactic levels.
The main step to bring significant benefits is common DATA DEFINITION, by harmonising concepts and facilitating their understanding, based on a granular data dictionary at the core of every step of the process.
A unique and common data dictionary is therefore highly important, and higher investments in this area will improve the whole process.
Governance must be defined before building the dictionary and must work continuously.
The most important aspect, per above, is to have a unique and common data dictionary and data collection layer to provide an efficient mechanism for both authorities and institutions to manage submissions.
Data collection costs are part of the data definition steps it this last one includes filing, validation and transformation rules in the dictionary itself. This is particularly true when the data dictionary language is both human and machine readable.
In a world where reporting is not integrated, the data collection process is highly costly for firms because regulatory requirements are unharmonized and each reporting framework requires different software tools, skills and a siloed approach. So any integration will save costs, however, this may also mean that reporting firms have invested in human resources and infrastructure to deal with that situation so any changes may result in significant decommissioning costs.
Semantic and syntactic levels would bring more significant benefits than infrastructure level to streamline reporting process.
With Integrated Reporting, data transformation and data exploration processes will be remain fully developed on each side (authorities and reporting firms) to respond to their specific needs.
Only a small part of data transformation could be implemented and shared on a common platform. In fact, aggregated data required by authorities which are not based on internal model or internal referential like internal rating would not manage on a unique and centralized data transformation platform. A unique and integrated data transformation process seems more costly than beneficial.
The project costs (data definition to data exploration) depend on the ability of the reporting firms to achieve each step related to the set up a common data dictionary, to feed a unique data collection point, to transform these data and load into a format that can e readily analysed and investigated.
XBRL is focussed on collection and validation as it is used for business information exchange. It was not initially developed for data exploration, so today work is required to get the data into an optimum format for analysis. However, per above, the XBRL community has recognised this and XBRL-JSON will provide a potential standard to enable large data environments, e.g. NoSQl, semantic databases to readily consume XBRL data using the semantic layer as defined in the XBRL taxonomy with no transformation.
In the meantime, vendors have developed sophisticated and efficient mechanisms for storing XBRL data in commercial SQL databases.
At each step (data definition to data exploration), project costs are more and more high for reporting firms, but benefits seem less important for them. However, firms have begun to realise that using the common data dictionary as defined in an XBRL taxonomy for both external reporting purposes to collect and analyse regulatory data could provide significant benefits.
For example, insurance firms are using the Solvency 2 data model to help them extract the data from their regulatory reports and use this for their ORSA dashboards and the scenario planning to be included in their narrative regulatory reports. As another example, group entities are using enterprise XBRL collection systems to collect regulatory reports as part of the benchmarking of subsidiaries where heterogeneous consolidation and reporting systems are used.
XBRL Europe sees the move of XBRL standards further down the information supply chain, into the submitting companies as one of the key long-term benefits of deploying XBRL, without the costs involved in asking all submitting firms to adopt common infrastructures.
As an association promoting the XBRL standard, we fully endorse the use of a single data dictionary to manage reporting requirements in the form as an XBRL taxonomy. Today, this includes the CRD4 taxonomies of the EBA reporting framework; EIOPA Solvency II, ESMA European Single Electronic Format (ESEF) – based upon the IFRS taxonomy, various initiatives for taxonomies regarding to ESG (environmental, social and governance), local GAAP taxonomies for financial statements in various standards, as well as SBR (standard business reporting) taxonomies developed by some countries, such as the Netherlands, which has adopted a single data dictionary approach developed in XBRL to manage all Business to Government and inter government departments information exchange – covering tax reports, annual returns, statistics, health, education and farming today. In addition, other international standards bodies like GLEIF have adopted XBRL for the LEI taxonomy
Using XBRL taxonomies does not mean that a reporting firm has to change all of its internal dictionaries and systems, but they may use part of it (considering both semantic and syntactic level) to align their internal dictionaries with the public ones.
Today, there are many reporting frameworks which have been built as technical silos at the semantic and syntactic level. However, XBRL technology allows supervisory authorities to join these silos together and to bring existing taxonomies and new extensions in to a single common dictionary. For example, XBRL Europe is closely following the development of the BIRD initiative (Banks' Integrated Reporting Dictionary) and providing input where requested.
From a bank standpoint, several data dictionaries are usually in use, generally containing granular and aggregated data. They may partially share common data, which can create duplicates or discrepancies. Additionally, there may also be multiple dictionary layer: the business dictionary, the bank IT data collection layer, the regulatory layer... The concept of data dictionary is quite recent for banks and has been developed since they are using big data technologies, applying the BCBS 239 principles.
For banks, heading to a single data dictionary would require a significant change and a data-driven organisation and governance. Significant banks are currently applying the BCBS 239 principles, optimizing their data processing chain, but not many are ready yet to work with a unique data dictionary, as changes in tools and data collections require time. Not all of them have yet a Chief Data Officer in charge of data dictionaries. So to request banks to move to such a situation in the time horizon of the survey would be unrealistic and expensive. However, we would urge the EBA to ensure that it has a clear picture of the relevant data sophistication of different regulated entities, perhaps mapping their operations against a capability maturity model. It is important, from a cost-benefit perspective, to ensure that relevant decisions do not assume that the skill base of firms is at the same level as the larger and most advanced regulated entities. Again, one of the key reasons for expressing reporting requirements in conformance with well used and well understood standards is to help reduce the costs of compliance and improve the capabilities of the reporting population as a whole. In addition, as commented upon above, the process to move to single unified data dictionary can be an evolutionary process.
We fully agree with all the characteristics in the document, however, we propose one additional characteristic: having a multilingual data dictionary, as it is essential to have a clear definition of data across Europe in local languages, to avoid misunderstanding, synonyms, or false friends.
A unique data dictionary should be multi-purpose and rely on a harmonized regulatory framework. This requires that no other data dictionary should be used to comply with similar regulatory requirements. For instance, BIRD includes all prudential and resolution frameworks, and it should be extended to cover the full statistical framework managed through IReF project (ECB).
The dictionary should be based widely on granular data, and be scalable, and quickly updated to include new requirements (new regulations, including quick amendments of regulation, such as the CRR2 QuickFix or the FINREP Covid-19 templates).
The key characteristics of the data dictionary are then: scalability, data comparability, multi-purpose (serve all regulatory data processes) and comprehensive (contains all granular and aggregated data, qualitative and quantitative data, required by EU & national authorities for all prudential, resolution and statistical frameworks).
The data dictionary would provide a unique data definition of a specific concept/element that is required to be reported (including transformation, validation and relationships to other concepts), to avoid misunderstanding in the reporting process (the smaller the room for interpretation, the more reliable the data disclosed by banks will be). A unique, common data definition will help to avoid variability of data dictionary usages between bank’s departments, entities, and locations. This will make discussions between the banks and its EU & National authorities easier.
A central data dictionary will also harmonize the interpretation of the reporting requirement between the various European authorities. That could help the sharing of data between supervisors and hence improve and coordinate supervision between the Supervisory bodies.
We are very aware of the costs imposed on internationally operating firms associated with widely divergent reporting requirements. We would encourage the EBA and ECB to discuss the potential for wider adoption of the dictionary with the BIS.
Also, the dictionary must be the core of the governance of the regulatory rules, helping to make the regulation more consistent to bring higher confidence on the quality of the data disclosed by the banks to their regulators.
This only can happen when the data dictionary is managed with adequate governance, taking into account all core issues like implication of all stakeholders, ownership of the various data, versioning and security management. An easy to use interface to this dictionary must be provided to developers of the various regulations, supranational and national.
Understanding reporting regulation
Extracting data from internal system
Processing data (including data reconciliation before reporting)
Exchanging data and monitoring regulators’ feedback
Exploring regulatory data
Preparing regulatory disclosure compliance.
Other processes of institutions
Per above, a common dictionary should help to make the regulation more consistent, however, understanding the regulatory requirements is not necessarily tied to the existence of a data dictionary. It can also come from clearer regulatory interpretations. Compliance is not only driven by a data definition, but also by the data quality, after transformation controlled through output format checks. The central dictionary is a key tool but should not be the only solution to target integrated reporting.
A standard data dictionary is an effort from the data users to express their needs in a standard, common, unique, and rationalised way. It avoids misunderstanding and redundancy. Even if reporting firms do not integrate the dictionary in to their internal systems, but only link to it via their regulatory reporting systems, a public standard dictionary will help them to significantly improve the reconciliation and consistency controls (intra & cross reporting) and provide a common internal general understanding (cross department, entity, team).
A unique data dictionary also facilitates the automation process and enables a common set up of data transformation rules between banks and authorities. These transformation rules could be drawn together and stored in one place to ease updates, reducing global cost of reporting (reducing costs of production on a medium term but increasing costs of project on a short term).
However, this could only be achieved if the dictionary is built in an efficient way, i.e. one that does not create duplicates, provides unique definitions, clear references, and multilingual labels to be understood by all. It should include assertions to describe the relations between concepts, and easily be read by human as well as by machines. The XBRL taxonomies allows to build such dictionaries for financial reporting and are already largely used by the banking industry (in a non-integrated way).
The dictionary should facilitate the regulatory requirement understanding and enable a better consistency between the various reporting processes (prudential, resolution & statistical). The objective is to avoid silos within the banks data organisation.
The dictionary should not only serve for external reporting but assist in the implementation of internal management dashboards and steering reports. As a reminder, a data-driven organisation must manage a global data dictionary for all internal and external requirements. Setting up an EU standard dictionary could drive reporting firms to head to a unique internal data dictionary for their own.
We have learned from the Anacredit experience that different understandings for common concepts may create a huge difficulty for reporting firms. A standard data dictionary must avoid concepts being defined in separated specifications, using different reporting formats and having different interpretations between the countries.
To answer to this question, we have considered the (relative) return on investment (RoI) more than the absolute costs.
A common dictionary at the European level brings huge savings compared to having each local regulator (NCA) define its own dictionary. Per the comments above, a common data dictionary also brings savings from common software tools, automation of the reporting process and from better understanding of what is to be reported.
The RoI for local authorities is very significant as they can share a common effort and benefit from each others knowledge. This has already been shown by the current European frameworks such as CRD4, Solvency 2, etc.
The RoI for banks will depend on their ability to utilise the common dictionary and common technology in their reporting processes, i.e., if they have already implemented a prudential reporting data mart and if they use an internal data dictionary for all their regulatory reports (and potentially internal reports), they may find it easier to adopt a common data dictionary. Software vendors will also find they can reduce the long-term costs of development by adopting a common data dictionary and will be able to invest in tools to help them manage this.
At this stage, banks are not yet compliant with BIRD mostly because BIRD is not complete for now.
The implementation cost savings of using a common dictionary must be balanced with existing hidden costs of teams gathering, reprocessing and harmonising the data, due to discrepancies in the non-integrated reporting.
Costs may be better managed by using the existing initiatives and work done on standardisation in the EU. The BIRD dictionary identifies common concepts for a significant part of the reporting framework covered by the EBA. In addition, there has already been a significant investment in XBRL technology and taxonomies. In general, this has not been considered as excessively expensive by banks and authorities. A move to a unique regulatory data dictionary based on existing XBRL taxonomies is therefore likely to be significantly less costly from a technical point of view.
High cost reductions
For cross-border banks, costs reductions are high thanks to harmonisation which allows a common, unique process. For national authorities, it allows them to share costs more easily, as investments will be European and not national. For local reporting institutions, the savings primarily come from the availability of a competitive environment for reporting software, created and encouraged by a single technical platform.
A key feature of XBRL is that it allows the development of extensions in a simple and manageable way. This means extensions can be readily created and easily managed to cover specific national or regional requests additional to the core list of concepts. Control processes can be put in place to move those extensions to the core data dictionary (taxonomy) when they are widely used. Such extensions to the EBA CRD4 and EIOPA Solvency 2 frameworks to provide National Specific Templates (NSTs) is a process that has been working for years. It is operational, mostly automated, and well managed. Costs more often are due to technical issues related to desynchronised evolution in the regulations or in the technologies.
Moderate cost reductions
Standardisation reduces the number of ad hoc requests and facilitate the good understanding between authorities and reporting firms. A common semantic and syntax technical base for ad-hoc reports can still provide benefits.
Ad-hoc requests could also be reduced, if data is collected at a more granular / detailed level, which is something the XBRL technology allows (use of XBRL-CSV), and if authorities and banks share common transformation rules. However, the costs need to be weighed up between the burden of collecting granular data versus the costs of potentially having to make additional ad-hoc requests.
Additional COSTS for reporting firms:
- Adjustment costs about regulatory reporting process.
- Evolvement costs about the operating model which is currently performed by reporting teams: organisational changes (size, skills…) to set up a data driven organisation, to review the organisation between the teams in charge of prudential, resolution and statistical reports.
- Cost of governance overhaul.
Additional BENEFITS for reporting firms:
- Facilitate consistency control process for each report and across reports.
- Improve data quality assessment.
- Free up time for analysis needed for strategic decision.
- Decrease amount of data produced by reducing data overlap between reports.
- Reduce multilingual issues.
We all agree on the costs, but the benefits depend on the feasibility of the changes and on the governance and quality of the data dictionary. Setting up a dictionary with a unique and precise definition for each data, shared by all and kept in time, requires to overcome a lot of limits. Calculated data (according to internal models) can hardly be defined in a unique way. Local practices are not easy to align (each national authority allows some exemptions which creates big differences).
Costs also are driven by reporting frequency and deadlines.
The data governance targets given in the Discussion Paper §182 use the 14 principles of data management required by BCBS 239.
For institutions, the implications depend upon the gap between their current level and current frequency of granular data collected and the level of granular data expected by their authorities. The collection and reporting of data at a more granular level requires a better compliance with the BCBS 239 principles in terms of both data management and data governance. For example, it may improve the data quality of granular data and their governance thanks to a clear identification of data usages. It may also improve the data controls and adjustments processes. However, it will introduce complexity in naming and governance, when a concept is required at different granularity level (a loan vs. a loan per sector at national level vs. a loan per sector at EU level) which may compromise the data quality if misunderstood or mixed up.
Granular data allows to define simple, factual data prior to any interpretative transformation or calculation. It allows to reduce ad-hoc requests. The harmonisation of the definitions for granular data collection should therefore facilitate the reporting process of the three frameworks (statistical, resolution, prudential), even if the amount of granular data is probably less important than the amount of aggregated data for the prudential and resolution frameworks.
For those two frameworks, where reporting frequency is generally higher and calculation for aggregated indicators is complex, time to process and chare the granular data may be short compared to reporting frequency and some data, especially in the prudential domain, will probably need to be reported on an aggregated level if the regulator cannot compute and share it on its side. Also, qualitative data, such as in resolution reports, cannot be detailed on a granular level. Semi-structured reports could be a better solution, with narratives including texts and data tables. Inline XBRL, with narrative as HTML text and granular data in a structured WBRL scheme, supports this kind of approach.
Regarding statistical returns, the use of granular data presents a solution, given that aggregated and derivative calculations are primarily a function undertaken on the regulator side and not limited to each bank but sharing data sources from all the reporting firms.
Our main preference goes to option 3, however option 2 is more realistic.
Option 1 does not improve the current process because a unique data dictionary (without review of the scope and level of data collected) would not be sufficient to provide significant benefits for both authorities and institutions.
XBRL is already being used and providing significant benefits to individual collection frameworks and using XBRL as a common standard to define semantics and syntax helps the data to be combined across reporting frameworks that adopt XBRL and enables the use of common technology to be deployed at the institutions and to be implemented for the regulator collection systems. However, it does not make the most of the potential for developing a common data dictionary in XBRL.
The key challenge would be to use the Data Dictionary to help define each of the separate collection layers and to manage this over time.
Option 2 given the timescale on which the survey/discussion paper is based this appear to be the optimum approach. It is feasible as described in the previous section using XBRL as the common standard and it is also consistent with the direction that the reporting systems data architecture is taking within reporting institutions.
However it is potentially only a first step on a path to the collection of more granular data and towards option 3, which appears natural evolution that reporting systems are heading towards.
Option 3 has the huge benefit of avoiding any data duplication and enables the data to be aggregated and the calculation of derived facts to be fully flexible to the specific requirements. However, at this point, authorities do not run all transformation rules for bank’s internal calculations on granular data. Fully granular data reports will bring the calculation work on their side as no computed (aggregated) data should be reported, and will require an information flow from regulators to banks as the results must be shared with the reporting firms for validation (feedback loop).
The collection of granular data across all reporting frameworks requires huge change, the cost/benefit ratio of a direct switch to Option 3 therefore appears too high. Reporting firms should first progress on the automation and integration of their reporting process (based on their granular data) to reduce the volume of manual adjustments.
Clearly there are also other significant aspects of the collection of granular data that need to be considered and planned for. Amongst them — heightened exposure for regulators to:
- Cybersecurity risk. Granular data is, by its nature, potentially more revealing about the business activities, exposures and capabilities of regulated institutions, potentially even leaving entities exposed within a range of markets if their open positions are discovered. It is therefore an even more attractive target for criminal activity.
- Reputation risk. Granular data will almost certainly give rise to huge volumes of information that will be held — but not necessarily fully analysed — by regulators. When an institution fails, and later inquiries determine that authorities held relevant information about that failure, a new expectations gap will be created.
Decision makers in this field will need to consider these kinds of risks in the balance associated with the undoubted utility of granular data in a range of fields. Techniques including federated storage (on a pull basis from standardised repositories within regulated entities), anonymisation and multiple levels of encryption will need to be considered.
The granular data collection should be designed as a unique source of data (managed by a dedicated data department) with a clear governance.
It should use a unique file format, independent of programming language, using standardized and globally used format like xBRL-CSV and/or xBRL-JSON.
Moreover, it should include meta-data to make sure each data is understood through all data collection chain and flagged (scope: prudential / resolution / statistical) and type (granular / aggregated data,).
This data collection layer should enable to drill down aggregated data to link with underlying granular data.
No costs (4)
Collection/compilation of the granular data
Additional aggregate calculations due to feedback loops and anchor values
Costs of setting up a common set of transformations*
Costs of executing the common set of transformations**
Costs of maintaining a common set of transformations
Complexity of the regulatory reporting requirements
Other: please specify
Costs of implementation appears as highly important (IT architecture, databases capacity, coordination efforts, …) for both authorities and institutions, especially if it is a common set of transformation has to be shared by authorities and institutions.
No benefits (4)
Reducing the number of resubmissions
Less additional national reporting requests
Further cross-country harmonisation and standardisation
Level playing field in the application of the requirements
Simplification of the internal reporting process
Reduce data duplications
Complexity of the reporting requirements
Other: please specify
OTHER = Improvement of data quality.
Granular data collection offers a lot of advantages in terms of data quality (it is more difficult to ensure a reliable aggregated data as it depends on both source quality and transformation quality). Benefits highly depends on the reporting firms’ decision to use the integrated dictionary for granular data for their own IT system.
To assess the costs/benefits ratio on each option, we have compared the potential project costs to the gap between the current running costs and the expected running costs.
About Option 2, costs should be higher than benefits if data transformation rules are not clearly defined (scope, definition and final usage) by authorities and reporting firms.
The data dictionary should embrace all granular and aggregated data needed to perform all data transformation rules expected by authorities. To avoid double running costs, data transformation should not result to an aggregated data already collected into the data dictionary collection step. The feedback loop process should be highly costly if it implies for reporting firms to setup their own data transformation rules to validate the resulting data.
Authorities and reporting institutions jointly
Harmonised and standardised, ready to be implemented by digital processes (fixed)
Harmonised and standardised, ready to be implemented by digital processes (fixed) Yes
Indicative instructions of calculation explaining the possible approaches (allowing for adaptations)
We think that definition and execution of transformations are two separate actions with different responsibilities.
Regarding definition of transformations, authorities and reporting firms (based on inputs from the institutions and their representative associations) should jointly be responsible whereas executions of transformations would be more efficient if done on one side only, but the responsibility of checking the results must remain on the firm’s side.
Joint definition of transformations allows to better secure transformation process, to prevent misunderstandings (same understanding on both side), to improve cooperation between authorities and institutions (comprehend each other’s view), and to change the relation between them (more sharing, less guidelines).
Execution of transformations requires to have access to data and to store it somewhere, to have computing power and efficient processes to run the transformations rules, which is currently well managed on the reporting firm’s side. Heading to a joint execution or transferring execution to authorities would be a huge and costly challenge in terms of data privacy, confidentiality, security, human and tech resources. It will however allow a centralized mutual tool, which is less costly on long-term.
Furthermore, we segregate transformations tied to common needs between both authorities and reporting firms from transformations tied to specific needs (internal reporting, result checking). Transformation rules related to common needs should be transparent for both authorities and institutions to allow a satisfying data quality and a well understanding between them. It is especially true to set up the feedback loop (controls) process.
Defining a more granular layer would have different impact whether execution is done on reporting firms’ side, on authorities’ side, or jointly.
With more granular the data, execution of transformation rules must be kept running only on one side, otherwise the cost/benefit ratio would be much lower.
The more granular the data, the more complex to:
- Ensure data quality and correctness (setting up anchor values for data quality checks).
- Run data transformation (given the the same technology, the same technical environment, the same software version, etc.) .
- Reconciliate (setting up feedback loops because of parallel run authority/firm; comparison because of manual data adjustments).
- Update and store data transformation rules (versioning)
- Synchronize computation through time (producing data in the past is not necessarily supported by systems).
Most probably, granular data that would be collected by authorities on the data collection layer would not be enough to produce the whole aggregated data required by prudential and resolution reporting authorities. In fact, consolidation rules, internal data referential (counterparties, financial products…) are key components on institutions reporting processes. Same limitations are true for transformations rules, it would require sharing internal models which is not necessarily wanted by institutions.
By defining jointly authorities and reporting firms a list of automated adjustments rules (with some thresholds for quantitative data).
By implementing a set of consolidation rules of each banking group on the transformation layer shared by authorities and reporting access, with a secured access. That suppose for banks to provide a fully transparent set of accounting and prudential consolidation rules.
By defining jointly authorities and reporting firms a list of automated adjustments rules to comply with official valuation sources (market data providers…).
By giving the last check and the word to reporting institution before supervisory review.
If there is no unique transformation rule for calculating the data, the data should be considered as a granular indicator.
The challenge could be met by segregating each type of transformation rule: first one is a common set for common needs (responsibility should be defined by discussing between authorities and reporting forms), second one is only used by authorities to perform their ad-hoc analysis (authorities' responsibility) and third one is only used by reporting firms to perform their aggregated data based on internal source (institutions’ responsibility).
Data security and confidentiality. Once collected, the data security should be guaranteed by the authority.
Feedback loops should pass all aggregated data computed from a common set of transformation rules based on granular data available in the central dictionary.
It is important that other closely related frameworks where financial institutions are required to report significant regulatory data sets are aligned, e.g. the Insurance sector’s reporting requirements and consistency with EIOPA’s plans for Solvency II and beyond..
Compliance, anti-money laundering data, fraud and payments data, as those domains are now under the coordination of the EBA.
On a full granular level, there should be consistency between bank supervision and market data collection (ESMA) for MIFID/MIFIR and related regulations (data collected through Data Service Reporting Provider).
More than having a unique collection, we think that a common dictionary and common standard technology such as XBRL between those domains could bring consistency and mutual understanding.
Different definitions for a common concept. Different concept for a common requirement.
More than having a central collection point, having a common dictionary and technology brings consistency and mutual understanding.
There are common taxonomies published by EBA/SRB but those are not integrated (one separate taxonomy per domain) and local authorities may adapt those dictionaries.
Having an anchoring mechanism (such as in ESEF) between dictionaries could help to link and harmonise definitions and dictionaries.
Having XBRL (or XBRL CSV) as single format could help to integrate the reporting process.
More than having a central collection point, having a common dictionary and technology brings consistency and mutual understanding.
The use of one common technology, such as XBRL (already in use).
A CDCP will oblige to have a standard technology and dictionary.
As an association focusing on data definition and reporting, we have no common comment on this question.
Yes, to a limited extent
XBRL Europe and its member XBRL jurisdiction in Europe support this approach and would be happy to work on semantic and technical discussions for integrated reporting. Its members are supervisors, reporting firms and solution providers.
not valuable at all
valuable to a degree
Data definition – Involvement
Data definition – Cost contribution
Date collection – Involvement
Date collection – Cost contribution
Data transformation – Involvement
Data transformation – Cost contribution
Data exploration – Involvement
Data exploration – Cost contribution
Data dictionary – Involvement
Data dictionary – Cost contribution
Granularity – Involvement
Granularity – Cost contribution
Architectures – Involvement
Architectures – Cost contribution
Governance – Involvement
Governance – Cost contribution
Other – Involvement
Other – Cost contribution
As an association focusing on data definition and reporting, we have no common comment on this question.
A pull approach could be considered only if CDCP is running, with a unique common technology.
Even if currently used in a Push approach, the XBRL technology allows both Pull and Push options.
We understand that the CDCP scenario means that the reporting firms will no longer use the collection process of each national authority but a common collection process where all relevant supervisory information will be collected and available for various national authorities according to some accreditations.
From our point of view, the main obstacles for a centralised collection approach would be for the national authorities. According to the country, the number and scope of national authorities may greatly differ. In some country for instance, the same authorities are in charge of supervising the CRR and Solvency II remittances while in other countries such reporting is supervised by different authorities. In case of an adoption of a CDCP restricted to the banking sector, the potential cost savings for authorities having a broader scope will be limited.
Furthermore, such solution will require a strong governance and some flexibility to allow the various authorities to define their:
- Specific reporting deadlines: Discrepancies must be limited. The complexity may reach a level as to become inefficient when deadlines are not harmonised in Europe, as it is the case in Anacredit (some local authorities have defined for instance business rules where every new contract / instrument should be submitted within a 10 day delay). However, national differences will persist (e.g., the bank holidays are not the same in all countries).
- Specific reporting requirements on validation rules: Some local authorities have defined a set of additional and specific validation rules to enhance the quality and the effectiveness of the supervision according to their local requirements. If such control is not performed by the CDCP, it should be necessary to define a mechanism to transfer the custom validation to the fillers and to flag the remittance collected in the CDCP as non-consistent.
- Additional reporting requirements: Some local authorities are used to derive and enrich the European collection with some local national reporting (NSTs). In this case which entity should oversee developing the additional technical reporting requirements?
Additionally, there may be some concerns about the languages used in the CDCP. Regulations and templates are provided in each EU language.
From the supervisor point of view, a centralised solution will require to develop a new expertise of the common data sets, to be able to directly access and derive new reporting requirements from the previous collection.
In term of audit trails, the reporting firms are currently responsible for keeping the relevant information for a predefined period to provide a corrected version of the reports in case of errors being identified later. With the new CDCP approach where both reporting firms and authorities work on the aggregation rules, who will keep that responsibility, which may be costly from an infrastructure point of view?
Even if it allows to reduce the volume of data transfers, on-change submission of granular data should absolutely be avoided as it is difficult to manage on long term for reporting firms.It may ondeed create divergence between the views of the reporting firm and the collecting authority about what has been effectively registered. From a reporting firm’s perspective, the block-update approach (rather than the on-change approach) is easier to manage and more robust.
Reporting firms should be accountable of:
- The quality of the granular data sent. To ensure the quality of the declaration a set if detailed validations rules, defined by the authority with the industry, implying multi period checks should be performed by the reporting institutions. The submission should include the results of such validation rules and comments for the reporting firms giving some insights on the data quality (e.g., why some non-blocking validations rules have not passed the full set of controls).
- The monitoring of its activity and the quality of the financial information disclosed to the public on an aggregated level. Following the recent mapping done by the EBA between the disclosure and the supervisory requirements, some additional reconciliation could be done by the authorities between key indicators provided by the reporting firms at an aggregated level (in their disclosure requirements) and the one calculated by the CDCP, based on the granular data. Having common taxonomy concepts for regulatory returns and pillar 3 disclosures would be a great help to facilitate reconciliation.
By including a set of common validation rules in the taxonomy with the data definitions, as previously described, XBRL provides a significant benefit to regulators and institutions alike.
Unless explicitly requested to review a computed data (feedback loop), reporting firms should not be responsible anymore for:
- Providing a detailed audit trail of the aggregation performed by the CDCP.
- Any anomalies linked to inconsistent transformation rules performed by the CDCP.
- Any additional delay in the collection process once they have sent their data to the supervisor.
To allow this mechanism, a similar transmission format and dictionary should be used for the feedback loop information. XBRL, which is known by reporting firms and authorities, is a good solution to handle this mechanism.
In general, you can have agile data collection definitions if you minimise manual filing rules and you focus on providing the complete set of definitions in the taxonomy/formula to define what is to be collected. A good collection system should be capable of being updated simply by issuing new or extended taxonomies. This would support a system with an update cycle that takes the shortest possible time.
As an association focusing on data definition and reporting, we have no common comment on this question.
As an association, we promote the use of XBRL,the continual development of its specifications and the innovative ways it can be used in the the regtech arena. We foresee that XBRL-CSV and xBRL-JSON and the future development of OIM will provide further opportunities to make regulatory collection systems more efficient and tailored to the specific needs, e.g., xBRL-CSV for exchanging structured granular data and Inline XBRL to provide semi-structured reports with significant narrative information and comments on the data that needs to be read and not just validated and stored in a database.
An open and mature technical standard like XBRL also allows historical solution providers and regtech firms to innovate and deliver efficient tools and offers.
For data transformation and exploration, once the data is structured and clearly defined (XBRL taxonomy), the general use of machine learning is the source of many potential regtech innovations.
One of the key questions for regulators is purpose. Is data collected primarily so that other people can view it, or is it collected so that it can be processed by the collecting agency or by others? If the latter, it is important to understand that processing will work at best if the data is fully specification-compliant and is validated at every stage. Fully validated data will be capable of being interoperable, which reduces costs for all the agencies involved.
via a service provider
The members of our association and national jurisdictions include regtech providers.
XBRL Europe and its member are ready to help and develop use cases on the latest uses of the XBRL technology.
The more you use a worldwide standard such as XBRL, the more regtech innovations you will get around it.
We promote fully open semantic standards able to describe the data but also the dictionary in a way which is understandable by both the human and machine users.
XBRL first focused on data to give a common understanding. Having a common dictionary (instead of multiple taxonomies) will help to avoid redundancy. XBRL wasn’t initially designed to handle volumetric granular data, but has evolved to allow it, keeping its benefit on common understanding and dictionary.