European XBRL Taxonomy Architecture
From XBRLWiki
(diff) ←Older revision | Current revision | Newer revision→ (diff)
Contents |
Forword
Introduction
Objective
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.
Target 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.
Relationship to other work
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.
Scope
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.
RH: Is this terminology stable? I've seen 'report' as term for 'framework' and trying to grasp the essence of a framework I think that it represents a number of forms or tables. In essence its just a semantic name given to a number of forms and or tables, its not defining anything for itself, only by derivation of what it groups. A report (IMO) also represents a single form or table. Which is why I put framework as the proposed name. OTOH the framework seems to represent business rules too and that is not always correct since business rules can be applied on dictionary level, on framework level or on single table and even cell level.
Normative references
Terms and definitions
| Term | Definition | Explanation |
|---|---|---|
| Owner | The owner represents an European institution that defines concepts in the data point model. | The owner is the top level of everything that is defined in the taxonomy. It is represented by a schema in which a number of characteristics of an owner are stored. |
| Public elements | Public elements are XBRL concepts in the data point model. | They are identified by a code in a certain scope. They MAY include additional information such as readable labels, definitions and legal references in different languages. |
RH: The occurences of the owner and his IP rights and supportive languages etc. appear to me to be facts, not meta data expressed in namespace, concepts etc. The owner name is already expressed through the namespace of each schema.
RH: Public elements are just XBRL concepts, why not use that term? Moreover, IMO the MUST contain labels and definitions. How else are you going to interpret them? I advise not to hard link all the different languages. Too much overhead if you want Spanish only.
Symbols and abbreviations
Rules
Localisation, extensibility
There are two areas that are commonly understood as part of a 'localisation' of the taxonomy. In some cases this refers to enabling the taxonomy to operate in a certain language area and in other cases the term is referring to the enabling of the taxonomy to support local legal requirements. The term 'local' is often understood as geographical based but it can also be industry specific or represent any other grouping of businesses involved in the reporting domain.
Language
If there is a need to have a representation of taxonomy content for a certain language, XBRL offers the option of extending the taxonomy with extra labels in the language preferred. This can be done by anybody with the proper knowledge of the taxonomy content and the preferred language. In the European Union all member state language belong to the 'official' languages of the EU. It is up to the EU agency to provide the necessary languages with their taxonomy. By providing the different languages in separate files (linkbases) and NOT linking them directly into the taxonomy, any regulator can create an extension calling only the required languages and save on the size of the taxonomy being discovered by the XBRL enabled software.
Legal and other requirements
Local NSA's may create extra tables or extend existing tables with columns/rows that are needed to abide local legal regulations. For reporters that create reports in multiple countries it eases the reporting burden when these extensions to the base taxonomy are created in a similar way (from a technical perspective). The scenarios that allow for extensions are:
- adding rows/columns to existing tables
- adding new tables
- dividing existing cells
