Best Practices on Extending CEBS Taxonomies

From XBRLWiki

Revision as of 14:00, 2 November 2007; Katrin (Talk | contribs)
(diff) ←Older revision | Current revision | Newer revision→ (diff)
Jump to: navigation, search


Contribution dated 2007-11-02



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 and on the project related websites and


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 (

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”.

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.

5.2.6 Creating instance documents

An instance document contains contexts whose <scenario> elements point to specific dimension members in one or more dimension taxonomies. So, both the dimensions and the specific dimension elements that a fact refers to can always be determined by the corresponding context of that fact. It is important to remember that this has nothing to do with hypercubes and the principle explained in the previous chapter: Hypercubes are used to express combination of dimensions and to link them to specific primary items. Hypercubes are necessary to determine whether a specific combination of dimensions is valid or invalid for a specific primary item. The instance document declares which combination of dimensions a fact refers to. Whether this is a valid combination or not has to be determined by XBRL, and the hypercubes defined in the taxonomies are used for that. For the creation of an instance document that contains dimensions linked to the primary items, it is necessary to use the xbrldi-2005-11-07.xsd schema file in the instance document.

Image:Instance document.gif‎

This schema defines an “explicitMember” element for explicit dimensions and a “typedMember” element for implicit (= typed) dimensions which is an extension of QName with xlink attributes to define a simple relationship to the dimension Placeholder element.
The syntax to express a dimension is as follows:

Image:Instance document syntax.gif‎

An example (with namespace prefixes instead of URIs):

Image:Instance document syntax2.gif‎

So, the “dimension” attribute always points to the name of the abstract element which represents the affected dimension, and the value of the “explicitMember” element is the name of the specific dimension element. If the corresponding dimension is open (that means, the dimensional elements are not explicitly defined, only their structure is given), the name of the element is “typedMember”. The “scenario” element can contain an unlimited number of “explicitMember” or “typedMember” elements, depending on the number of different dimension elements a fact refers to.

Personal tools