European XBRL Taxonomy Architecture
From XBRLWiki
| Revision as of 07:04, 2 October 2012 (edit) Hommes (Talk | contribs) ← Previous diff |
Revision as of 11:38, 2 October 2012 (edit) Hommes (Talk | contribs) (→Approach) Next diff → |
||
| Line 44: | Line 44: | ||
| As a consequence to EXTA the taxonomy will rely heavily on the use of dimensions and their members. Given the XBRL specification of how to express dimensions the taxonomy will have some 'exceptions' to support specific dimensional constructs. EXTA will also provide a number of naming conventions for the XBRL building blocks that are needed to construct the taxonomy. | As a consequence to EXTA the taxonomy will rely heavily on the use of dimensions and their members. Given the XBRL specification of how to express dimensions the taxonomy will have some 'exceptions' to support specific dimensional constructs. EXTA will also provide a number of naming conventions for the XBRL building blocks that are needed to construct the taxonomy. | ||
| + | |||
| + | There will be multiple taxonomies from multiple EU agencies based on multiple reporting frameworks. This means that modularity is important to prevent a complex structure with intensive maintenance tasks. It is recognized that there will be two major components to all of the taxonomies: the more or less 'fixed' part compromised of all the detailed building blocks like concepts, types and their labels, and the 'flexible' part that is formed by the reporting requirements of a single table, form or report. It is expected that both parts can be extended but that the frequency in which modifications will have to be made lies mostly in the 'flexible' part. | ||
| + | |||
| + | The 'fixed' part of the building blocks is known as the <b>dictionary</b> layer, the 'flexible' part as the <b>framework</b>. | ||
| == Definitions, terminology == | == Definitions, terminology == | ||
Revision as of 11:38, 2 October 2012
Contents |
Introduction
These pages are hosting the guidelines to an European XBRL Taxonomy Architecture. (EXTA, for short)
- European; because this project is funded by the EU commission, but there is no restriction in applying it anywhere else;
- XBRL; because that is the syntax standard that has been chosen to be used in electronic information exchange between national banking supervisors and the European authorities;
- Taxonomy architecture, because creation of different 'dictionaries' or 'reporting frameworks' in XBRL have such a wide variety of options it would cause incompatability between the different XBRL taxonomies which would lead to increased implementation costs for all adopters in the EU market.
The reader of this EXTA is expected to be familiar with the basic principles of data modelling and have a thorough understanding of the XBRL family of specifications to evaluate the impact of the rules set to the XBRL taxonomy that needs to be created.
Targetted audience
EXTA is targetted at taxonomy authors. Initially organisations like EBA, EIOPA, ESMA, ECB etcetera. As a spin-off of these taxonomies, local (national) initiatives will emerge, hosted by National Supervisory Agencies (NSA's). To meet local legislation the European taxonomies may have to be extended with local requirements. The EXTA is also aimed at supporting these national extensions according to the same guiding principles. The main advantage being a consistent framework of XBRL taxonomies which enables a cost efficient implementation in software solutions.
Consistent taxonomies throughout Europe also creates the opportunity for cross-EU harmonisation of terminology and, in a later stage, consistent reported facts that are more easily analyzed since the underlying structure is the same and terms used are complementary to each other.
A consequence of a consistent taxonomy framework is that software developers can choose to support only the architectural guidelines of EXTA. Although this limits their software in supporting full fledged XBRL taxonomies it eases implementation costs.
Area covered
From a semantic point of view, EXTA is aimed at European financial reporting frameworks. This involves (but not limits to) banks, insurance companies, pension funds, stock exchanges and investor vehicles that have an obligation to report their financial status to European supervisors.
From a syntax point of view, EXTA works with:
- XBRL 2.1
- XBRL for Dimensional Taxonomies (XDT) 1.0
- XBRL Generic Link 1.0
- XBRL Formula 1.0
- XBRL Versioning 1.0
- XBRL Table linkbase (not released yet)
The syntax standards documentation is freely available at | XBRL International
Principles
EXTA principles are:
- Consistency and predictability of the taxonomy;
- (Automated) controllability of the taxonomy;
- Modularity, which enables extensibility and maintainability of the taxonomy;
- Following international best practices;
- ...
Approach
Designing any consistent architecture requires a methodology. For EU supervisors the Data Point Modelling (DPM) methodology has been chosen. This methodology relies on defining datapoints (facts) and support all of their aspects as dimensions. For an explanation of how to work with DPM, dedicated pages are provided in this Wiki at ...
As a consequence to EXTA the taxonomy will rely heavily on the use of dimensions and their members. Given the XBRL specification of how to express dimensions the taxonomy will have some 'exceptions' to support specific dimensional constructs. EXTA will also provide a number of naming conventions for the XBRL building blocks that are needed to construct the taxonomy.
There will be multiple taxonomies from multiple EU agencies based on multiple reporting frameworks. This means that modularity is important to prevent a complex structure with intensive maintenance tasks. It is recognized that there will be two major components to all of the taxonomies: the more or less 'fixed' part compromised of all the detailed building blocks like concepts, types and their labels, and the 'flexible' part that is formed by the reporting requirements of a single table, form or report. It is expected that both parts can be extended but that the frequency in which modifications will have to be made lies mostly in the 'flexible' part.
The 'fixed' part of the building blocks is known as the dictionary layer, the 'flexible' part as the framework.
