Best Practices on Extending CEBS Taxonomies
From XBRLWiki
| Revision as of 13:13, 15 February 2008 (edit) Katrin (Talk | contribs) (→Adding dimensions from a template) ← Previous diff |
Revision as of 13:13, 15 February 2008 (edit) Katrin (Talk | contribs) (→Adding dimensions from a template) Next diff → |
||
| Line 147: | Line 147: | ||
| Now it is ensured that only one child element of either of the two domains can be used together with other possible dimension items that are listed in the hypercube. In the example above, the hypercube would be connected with the abstract domain element of the primary dimension (measure) taxonomy with the arcrole “…/all”. | Now it is ensured that only one child element of either of the two domains can be used together with other possible dimension items that are listed in the hypercube. In the example above, the hypercube would be connected with the abstract domain element of the primary dimension (measure) taxonomy with the arcrole “…/all”. | ||
| - | ====Adding dimensions from a template==== | + | ====Adding dimensions to a template==== |
| A supervisor might decide that an additional breakdown for a total is needed. This means that additional columns are added to a template.<br/>Example: The CRD group consolidation of the FINREP taxonomy does not provided possibilities to model both, the IFRS group and the CRD group, as consolidation scope. Supervisors who want to provide these additional information have to extend their taxonomy by adding a new dimension. | A supervisor might decide that an additional breakdown for a total is needed. This means that additional columns are added to a template.<br/>Example: The CRD group consolidation of the FINREP taxonomy does not provided possibilities to model both, the IFRS group and the CRD group, as consolidation scope. Supervisors who want to provide these additional information have to extend their taxonomy by adding a new dimension. | ||
Revision as of 13:13, 15 February 2008
Contribution dated 2007-11-02
Contents
|
Abstract
This document describes the best practices on how to extend CEBS (Committee of European Banking Supervisors) taxonomies. The Committee of European Banking Supervisors (CEBS) has published XBRL taxonomies for the common reporting framework COREP (COmmon REPorting) for the new solvency ratio for credit institutions and investment firms and for the standardised financial reporting framework (FINREP) for credit institutions operating in the EU. These taxonomies are available on the website of the CEBS http://www.c-ebs.org and on the project related websites http://www.corep.info and http://www.finrep.info. Comment
Status
This draft document is created by members of the XBRL network of the CEBS. Taxonomy editors that are extending the CEBS taxonomies (COREP and/or FINREP)are invited to add comments, experiences and suggestions for improvement on how to extend these taxonomies in a practical way.
| KS: As a first approach I've added chapter 7 of the COREP-FINREP documentation that deals with the extension of these taxonomies. |
National Taxonomy Customisation COREP - FINREP
Extending the COREP and FINREP taxonomies is a similar process. In this document a COREP template is used for demonstration purposes; however, all the information provided below holds true for FINREP, as well. Please always take into account that FINREP modularisation is achieved by the use of extended link roles in only one primary taxonomy.
The COREP - FINREP taxonomies have been developed to be customisable – that means extensible and restrictive – by national supervisors. To facilitate the customisation of the taxonomies, the framework is as modular as possible and the structure of the taxonomies is similar to the construction of the CEBS COREP - FINREP templates. This means that the templates consist of measure and dimensions which are combined in a table. Therefore, the COREP taxonomy set consists of measure (primary dimension), dimension and template taxonomies.
In order to build extension taxonomies, the use of a taxonomy editing tool is recommended for their creation and maintenance. Links to useful XBRL tools for evaluation are available on the XBRL International website (http://www.xbrl.org).
National extension structure
National extensions will use the COREP taxonomy as a base. Extensions are done by creating new taxonomies and importing the corresponding COREP taxonomies. So, the national extension taxonomy contains all the functionality of the underlying COREP taxonomy. Changes are made in the national extensions without amending the base COREP taxonomy. The national extension taxonomy can overwrite all the rules that are defined in the imported COREP taxonomy.
Categorisation of national taxonomy extensions
Customisations can be made on:
- labels
- references
- the template structure
- calculations.
The following chapters deal with these customisations and how these changes can be made easily for national extension taxonomies.
Creating extension taxonomy
All customisations start with the creation of a reference to the COREP taxonomy. This is done by building a new national taxonomy and importing the corresponding COREP taxonomy.
To customise a COREP template, a national taxonomy (i.e. “t-me-ISO country code-2006-MM-dd”) must be created. After setting up all the properties and the national namespace, the corresponding taxonomy of COREP should be imported.
After the import, the national extension taxonomy possesses the complete functionality of the underlying COREP taxonomy.
Customisation of labels
The labels of the COREP taxonomy contain the captions of the columns and rows of the templates and can be used to create reports. For example, the receipt of an XBRL instance document could be transformed into other formats as Adobe Pdf or Microsoft Excel to enable easier viewing of the data. In such documents, the labels are used to hide the technical element name. To generate reports in the national language, the English labels of the COREP taxonomy should be translated accordingly. This is done by adding a label linkbase to the extension taxonomy. In this way, each national supervisor can create a COREP dictionary to present reports in one or more languages.
Customisation of references
The COREP templates are based on the EU directive of Basel II. Therefore, references to this EU law will be added to the elements of the COREP taxonomies in version 1.0. If a national law exists that defines what must be reported, this law should be added as a reference because it overrides the rules of the EU directive.
Additional references are added by extending the national taxonomy with another reference linkbase.
A reference to the COREP base taxonomy can be removed by prohibiting the use of the reference arc.
The references build a good glossary because by following the reference of an element, the explanation of what has to be reported can be found in the EU directive or in the national law. No further descriptions are needed.
The COREP taxonomy uses a specific reference structure that accommodates the structure of the EU directive. The national law might have a different structure. To customise the reference structure, the basic reference linkbase should be extended by adding additional elements.
Customisation of the template structure
This sub-chapter briefly describes the following use cases and how they can be incorporated in the national extension taxonomy:
- adding or removing columns and rows;
- reordering the hierarchical structure of a template;
- restricting cells from being reported (adding “grey cells”);
- removing dimensions from a template;
- providing choices among dimensions.
Extensions are explained here by using a small section of the FIRB CRM template with two dimensions (see the template below).
Adding or removing columns and rows
A national supervisor might decide that a column defined in the COREP structure is not needed for the reporting in his country, and so he wants to remove this column. Or else, he needs further information in the template and wants to add an additional column that is not defined in the COREP superset.
A column is removed by prohibiting the use of the arc between the measure and its superordinate parent element. An additional measure will be added in the national extension taxonomy and will be placed in the desired position in the presentation and definition linkbases by adjustment of the order attribute.
Column C has to be removed and column F has to be added. So, the original structure “ABCDE” changes to “ABDEF”.
The order of the measures in a template is represented in a hierarchical structure in the presentation and definition linkbases of a taxonomy, as shown below.
Column C is removed by prohibiting the use of the arc between the measure and its superordinate parent element (MKR SA EQU (measure)). An additional measure (column F) will be added in the national extension taxonomy and will be placed in the desired position in the presentation and definition linkbases.
Reordering the hierarchical structure of a template
The structure of a template can be changed by reordering the measures. If a new measure is added to a parent measure element, it will be positioned at the end of the hierarchical structure. The positioning of new measures as well as for existing can be changed if it is required by the national supervisor.
In this example, column F should move between the columns B and D.
In the hierarchical structure, the reordering of the measures is done by changing the order attribute in the presentation and definition linkbases.
Restricting cells from being reported
Every cell of a template is a combination of a measure and one or more dimensions. Some row/column combinations are not valid for the EU directive of Basel II and must not be reported. They are marked in grey inside the COREP templates. National taxonomies can extend or override those restrictions.
In the example below, the new measure is only valid for the parent element “EQUITIES IN TRADING BOOK” and its child “General Risk”.
The COREP taxonomy defines the general binding between the measures and their corresponding dimensions in the definition linkbase of each template taxonomy. This is done by defining a hypercube that contains abstract dimension item elements for each defined dimension and domain elements of the dimension taxonomies. For the explicit dimensions, the corresponding domain-member elements are assigned to the domain.
To restrict the cell of the example above from being reported, the national extension taxonomy must define an abstract element, called hypercube. This hypercube element must be placed inside an additional extended linkrole of the definition linkbase.
The hypercube will contain the abstract dimension element of the template with the arcrole “.../hypercube-dimension” and the subordinated child element that has to be excluded with the arcrole “…/dimension-domain”. If more than one child should be excluded, all these elements can be assigned as child elements of the dimension element with the arcrole “…/dimension-domain”; or, the abstract domain element of the dimension is assigned to the dimension element and all subordinated child elements of the dimension will get children of these domain element with the arcrole “…/domain-member”. It is also possible to refer to all child elements of the dimension by using the targetRole attribute on the “…/dimension-domain” arc that points to the general link role
Removing dimensions from a template
A banking supervisor can decide that a dimension of a COREP template is not needed for his national purposes. In the example below the dimension “National Market” should be deleted.
The national taxonomy can be created to reflect this requirement by removing the connection between the abstract measure element and the dimension that is not needed in the definition linkbase of the template taxonomy.
In the example above the definition of the hypercubes has to be changed by prohibiting the arc between the hypercube element and the dimension element.
Providing choices among dimensions
If a banking supervisor decides that one of two or more possible dimensions has to be used for a national COREP template, it can define this choice inside the template as well as in the taxonomy. In the example below, either Dimension SA or Dimension IRB has to be used in the national template.
So, a measure can be reported in combination with one or more of the other dimensions and dimension SA, or in combination with one or more of the other dimensions and dimension IRB, but dimensions SA and IRB cannot be used together.
The national supervisor has to define a hypercube with one abstract dimension element in this national extension for those dimensions that are built as choice, and further dimension elements for the possible other dimensions. The domain elements of both dimensions are assigned to this dimension element with the arcrole “…/dimension-domain”. The child elements of the dimensions are listed below the domain element.
Now it is ensured that only one child element of either of the two domains can be used together with other possible dimension items that are listed in the hypercube. In the example above, the hypercube would be connected with the abstract domain element of the primary dimension (measure) taxonomy with the arcrole “…/all”.
Adding dimensions to a template
A supervisor might decide that an additional breakdown for a total is needed. This means that additional columns are added to a template.
Example: The CRD group consolidation of the FINREP taxonomy does not provided possibilities to model both, the IFRS group and the CRD group, as consolidation scope. Supervisors who want to provide these additional information have to extend their taxonomy by adding a new dimension.
The first "column" (IFRS Scope) represents the total amount and matches up with the information that should be reported in those countries that do not include this breakdown.
From a technical perspective a new dimension taxonomy and its corresponding linkbases have to be created which includes the new members. The first column "IFRS Scope" is also added to this taxonomy but as a default member. [Excursus: If the arc role "http://xbrl.org/int/dim/arcrole/dimension-default" is set on a dimension member than this dimension member is the default and it must not appear in a context of an instance. If the primary is used in an instance without a reference to a dimension member than it must be assigned to the default.]
In the example above a new dimension "Activity" has been created with the default dimension value "IFRS Scope".
These changes should not have any influence on the core taxonomy. The linking of the primary items of the core taxonomy and the new dimension must be implemented at extension level. The country specific template taxonomy has to import the new dimension taxonomy and define the additional links.
With this approach we achieve compatibility between instance documents of countries using this breakdown and those who do not include the activity dimension in their extension of FINREP because the "IFRS Scope" member has been modelled as the default value of the new dimension.
Because this example is a real business case the CEBS XBRL network has provided an optional module to be downloaded from the following website:
Link: Optional module for the dimension activity
The advantages of this approach are the reuse of the elements of the core taxonomy and the compatibility to other extensions of the FINREP taxonomy.
Customisation of calculations
The calculation linkbase is used to define summations among measures in the measure taxonomies and to define aggregator-contributor relationships among dimension members of the corresponding dimension taxonomies.
The definition of calculations in the measure taxonomies enables the validation inside one context. Given that the measures of one row of a template are contained in one context because each row belongs to a different dimension, it is not possible to do the calculation across dimensions. In the future, the formula linkbase will support cross-context summations.
The national supervisors through the national taxonomies can extend and restrict the definitions of the calculation linkbases. It is done in the same way as before; by adding new element trees (adding calculations) or prohibiting arcs (removing calculations) in the linkbase.
