European XBRL Taxonomy Architecture V2.0

From XBRLWiki

(Difference between revisions)

Revision as of 08:24, 11 June 2013

CEN WS XBRL Experts: Thierry Declerck (DFKI), Roland Hommes (Rhocon), Katrin Heinze (Deutsche Bundesbank)

Foreword

Introduction

The purpose of this document is to present and explain the European XBRL Taxonomy Architecture (EXTA) defined by European supervisory authorities. In particular, it explains the scope (coverage of information requirements), modularization in files, manner of defining concepts and relations and other important design aspects. It is fully compatible with the Data Point Methodology approach. As DPMs are semantic models being created by supervisory experts, they are not formalized from a technical point of view. XBRL as formal language can fill this gap. XBRL as data format is standardized and can therefore be used to enable automated processes. XBRL taxonomies are metadata specifications that provide a formal description of the data requirements to be used as data format in the European reporting process. The document intends also to provide a description for IT experts about the linkage between a DPM as source and the XBRL taxonomy as target of a transformation process.

These pages are hosting the guidelines to an European XBRL Taxonomy Architecture (EXTA).

European: this project is funded by the EU commission to support the standardisation process for supervisory reporting in Europe, but there is no restriction in applying it anywhere else;
XBRL: this format has been chosen by the supervisory authorities EBA and EIOPA for the electronic data exchange between national banking supervisors and the European authorities;
Taxonomy Architecture: this architecture has been created to limit the wide variety of options to define an XBRL taxonomy; different European XBRL taxonomies for similar purposes cause incompatability and would lead to increased implementation costs for all adopters in the EU market.

Objective

The objective of the EXTA is to define a set of architecture guidelines that transforms an European DPM without a loss in quality in an XBRL format. The taxonomy architecture provides a set of rules for this transformation to enable the creation of consistent and predictable XBRL meta data definitions in an automated process. EXTA supports a modular structure to enable the extensibility of these taxonomies as well as to ease their maintenance. As EXTA is a formal representation of a DPM it contains several structural concepts which has no correspondance in other known XBRL architectures.

Target audience

EXTA is targetted at taxonomy authors. Initially organisations like EBA, EIOPA, ESMA, ECB etc. 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 need 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.

This document is aimed at users of the Bundesbank taxonomies, in particular editors of the taxonomy or producers of instance documents (by applying mappings to internal systems or assigning XBRL tags with values in any other manner) as well as developers of the IT solutions facilitating reporting in the XBRL format or analysis of XBRL data.

Relationship to other work

The reader of this EXTA is expected to be familiar with the 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

The EXTA has been defined for the creation of XBRL Taxonomies in the context of European supervisory reporting. XBRL taxonomie following this architecture are published by an European supervisory authority to reflect the data requirements based on a DPM in a machine-readable form.

Normative references

The eXtensible Business Reporting Language (XBRL), see | XBRL Standard

The Extensible Markup Language (XML), see | XML Standard

Terms and definitions

Concept: A concept is an XML element defined in the substitutionGroup xbrli:item or xbrli:tuple.
Data Point Model (DPM): A DataPointModel defines structures of data describing the characteristics of the information exchanged in the context of supervisory reporting processes.
Dimension: A Dimension is a data set to one characteristic area which is composed of individual and non-overlapping data elements. In XBRL terms a dimension is an abstract concept in the substitutionGroup xbrldt:dimensionItem.
Domain: A Domain is a classification system to categorize items that share a common semantic identity. A domain is an abstract concept and is the parent in a domain-member relationship. E.g. all individual countries can be members in a domain 'Countries'.
Family: Families are groups of Dimensions relevant for presentation or querying purposes. In XBRL terms a family is an abstract concept in the substitutionGroup xbrli:item with the @type set to 'model:familyType'.
Framework: A Framework is a business term common to a group of business users that consists of reporting regulations for a domain specific scope of information, like COREP, FINREP or Solvency II. Frameworks are public elements represented using XBRL abstract items with @type set to 'model:frameworkType' in schema 'fws.xsd'.
Item: An item is an abstract XML element in the substitutionGroup xbrli:item that can be used to carry facts or to represent business measurements. The item is defined by XBRL International as a placeholder for creating concepts.
(Domain) Member: A domain-member is discrete and countable. These Members can be explicitly defined in a domain. A member is an abstract concept in the substitutionGroup xbrli:item and is the child in a domain-member relationship.
Metric: A metric represent the nature of the data with a fixed and unchangeable meaning. Metrics are strongly related to the underlying data type. Mostly they are numeric and quantitatively measurable but they can be also reflect boolean or date values. A metric also known in XBRL terms as primary is a non abstract concept in the substitutionGroup xbrli:item that is defined based on the unique combination of a (XML) type and xbrli:periodType.
Namespace: The unique string in the form of an URI that is the @targetNamespace content of (a set of) XML schema file(s).
Owner: The owner represents an European institution that defines concepts. The owner's namespace is a URI used to establish the namespace of the concepts defined by that owner.
Perspective: Perspectives are extended linkroles that have a child node <link:usedOn>link:presentationLink</link:usedOn> AND contain only parent-child relationships in which families are the parent and dimensions are the child.
Public elements: Public elements of DPMs are represented as concepts in XBRL taxonomies. 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.
SubstitutionGroup: An XML attribute to classify a complexType of simpleType element so its construction can be re-used by other elements.
TableGroup: A TableGroup is a set of Tables that represents a business template. In XBRL terms tableGroups are public elements represented using XBRL abstract items with @type set to 'model:tableGroupType'.
Taxonomy: Taxonomies are defined as part of the DPM. It represents a version of the framework; kind like a 'name' for the set of definitions used in the framework that are not part of the dictionary. There is a virtual link with the XBRL term 'taxonomy' which is a set of concepts with their relationships and definitions. The XBRL taxonomy has much wider definition than the EXTA one. Taxonomies are public elements represented using XBRL abstract items with @type set to 'model:taxonomyType' in schema 'tax.xsd'.

European XBRL Taxonomy Architecture

Supporting concepts

Taxonomy levels and owners

Taxonomy concepts could be defined on one of the three levels:

cross sector concepts and breakdowns (to be shared between different institutions e.g. banking, insurance and securities supervision),
concepts from information requirements of an European supervisory authority,
concepts defined by a NSA.

Level one are cross sector concepts that shall be eventually defined and agreed by a joint group of experts involved in setting up information requirements for different sectors such as banking, insurance and reporting of other commercial and non-profit companies. It is expected, that these concepts will mainly include the list of countries and currencies as defined by the ISO codes and subsequently extended by for example economy sectors, classes of financial instruments, accounting portfolios, time intervals, etc. This task will be most likely conducted by reconciliation between the dictionaries of business concepts defined by the EBA, EIOPA and other interested parties. Cross sector concepts will be published in the Eurofiling on-line resources as a set of XBRL schema and linkbase files that can be referenced from level two or level three dictionaries.

Level two are the concepts of an European supervisory authoriy. They represent the information requirements of COREP, FINREP, Solvency II and other scope defined on the European level. They may refer to and extend level one (cross-sector) concepts.

Level three are the concepts of national supervisors. They reflect information requirements set by a national legislation and specific banking regulations.

The idea of levels for concepts definitions has been addressed in the XBRL taxonomy model by introducing the notion of the owner. The owner represents an institution that defines concepts of the model. The owner is closely related to the idea of extensibility in XBRL. The main properties of the owner are:

owner’s namespace {ons},
owner’s prefix {opre}, and
official location {oloc}.

The owner namespace {ons} is a URI used to establish the namespace of the concepts defined by that owner. This URI is generally built by adding xbrl to the internet domain of the institution that the owner represents. In case of the Bundesbank, the domain is extended by stat and sprv components to distinguish between statistical and supervisory datasets. The prefix {opre} is used as the basis to establish namespace prefixes in taxonomy files and for some short representations of the concepts by QNames using shorter prefixes (instead of long namespaces) plus the local name.

Official location {oloc} is a URL used to specify the location where taxonomy files associated to that owner are to be published. Different owners must have different official locations, even owners with the same internet domain/same namespace. The official location is generally built by adding three parts to the internet domain of the institution:

representation of the geographical area covered by the institution (e.g. eu in case of the cross sector or the EBA concepts or es for the national specific concepts applied in a sample Europea country),
indication of the scope of information requirement (e.g. fr for general financial reporting)
fixed xbrl component identifying the type of standard used to express information requirements.

The following table presents examples of owners and applied namespaces, prefixes and official locations of taxonomy files.

Owner	Namespace	Prefix	Official location
Cross-sector	http://www.eurofiling.info/xbrl	eu	http://www.eurofiling.info/eu/fr/xbrl
EBA	http://www.eba.europa.eu/xbrl	eba	http://www.eba.europa.eu/eu/fr/xbrl
Banca d’Esmirna	http://www.bde.se/xbrl	se	http://www.bde.se/se/fr/xbrl

Copyright: text used as a header in every taxonomy file published by its owner.

Filing indicators

Filing indicators serve the purpose of communicating the scope of the reported data based on templates. The main purposes of filing indicators are:

provide hints to applications using the taxonomy, on which templates/forms are included in the filing and for example shall be displayed to users,
trigger execution of business rules (value assertions) to be run on a filing to check its correctness depending on the reported scope of data.

In technical terms, filing indicators are facts included as part of an instance document where the filer estates which templates/forms are being reported. Each template/form is represented as an instance fact of the item “table” under the “fIndicators” tuple element. These elements are defined in the namespace http://www.eurofiling.info/xbrl/ext/filing-indicators. The official location of this schema file is http://www.eurofiling.info/eu/fr/xbrl/ext/filing-indicators.xsd. This schema file is imported in every taxonomy module.

Throughout this document, the prefix find will be used to make reference to this schema namespace.

The following instance excerpt represents a filing with information about templates/forms with codes CA1 and MKRSAEQU:

<find:fIndicators>
   <find:table contextRef=”ctx”>CA1</find:table>
   <find:table contextRef=”ctx”>MKRSAEQU</find:table>
</find:fIndicators>

The following instance excerpt represents a filing with information about tables with code 100 and 200:

<find:fIndicators>
   <find:table contextRef=”ctx”>100</find:table>
   <find:table contextRef=”ctx”>200</find:table>
 </find:fIndicators>

Context to which facts representing find:table element refer must identify the reporting entity and use the instant date which is the end date of the reporting period.

Table codes to be used on find:table facts are the ones identified by {template code} component of the documentation label of tabel:table resource (see 6.4.5.3 Tables). If a template results in multiple tables (as a result of its original arrangement in multiple physical tables or due to normalization process) it is identified by find:table fact only once.

Filing indicators are facts included as part of an instance document where the filer estates which tables are being reported. Each table is represented as an instance fact of the item “table” under the “fIndicators” element. These elements are defined in the namespace http://www.eurofiling.info/xbrl/ext/filing-indicators. The official location of this schema file is http://www.eurofiling.info/eu/fr/xbrl/ext/filing-indicators.xsd. Throughout this document, the prefix “find” will be used to make reference to this schema namespace.

This approach enables a clear separation between business facts (under the xbrli:xbrl element) and additional data required in the reporting process. Moreover, it does not require the addition of filing indicators to the dictionary of concepts, as filing indicators are defined in a generic way in its own schema.

Filing indicators include a Boolean attribute named “find:filed” with default value “true”. Tables not filed can be omitted from the list of filing indicators or have an entry with the “find:filed” attribute equal to “false”. The latter is especially useful if a footnote explaining the reasons for not filing a table want to be included.

Model supporting schema

The XBRL representation of the model makes use of some schema definitions in the namespace http://www.eurofiling.info/xbrl/ext/model. The official location of this schema file is http://www.eurofiling.info/eu/fr/xbrl/ext/model.xsd. Throughout this document, the prefix “model” will be used to make reference to this schema namespace.

Namespaces

The following table shows the prefixes used throughout this document as an abbreviated reference to namespaces:

Prefix	Namespace
xbrli	http://www.xbrl.org/2003/instance
xbrldt	http://xbrl.org/2005/xbrldt
link	http://www.xbrl.org/2003/linkbase
xl	http://www.xbrl.org/2003/XLink
gen	http://xbrl.org/2008/generic
iso4217	http://www.xbrl.org/2003/iso4217
nonnum	http://www.xbrl.org/dtr/type/non-numeric
num	http://www.xbrl.org/dtr/type/numeric
model	http://www.eurofiling.info/xbrl/ext/model
find	http://www.eurofiling.info/xbrl/ext/filing-indicators
pvar	http://www.eurofiling.info/xbrl/ext/pivot-variable
iaf	http://www.eurofiling.info/xbrl/functions/interval-arithmetics
variable	http://xbrl.org/2008/variable

Public elements

Public elements are all concepts based on a DPM that are identified by a code in a certain scope and may include some additional information such as readable labels, definitions and legal references in different languages.

Public elements include two attributes to reflect their creation date (model:creationDate) and the date when they was last modified (model:modificationDate).

Language specific information of public elements is represented using the following label resources: XBRL 2.1 labels (link:label) for xbrli:items (or derived) public elements,

generic labels (label:label) for public elements represented as XLink resources or other construct (e.g. link:roleTypes).
The default (standard) role (http://www.xbrl.org/2003/role/link) is used for the extended links containing the label resources.

The role types used as roles for generic and standard label resources are presented in the following table.

Property	Generic label role	Standard label role
Name	http://www.xbrl.org/2008/role/label	http://www.xbrl.org/2003/role/label
Definition	http://www.xbrl.org/2008/role/verboseLabel	http://www.xbrl.org/2003/role/verboseLabel
Legal references	http://www.xbrl.org/2008/role/documentation	http://www.xbrl.org/2003/role/documentation

The labels of the concepts of a schema or a linkbase file are represented jointly in a separate label linkbase file distinguished by language, in the same folder as its corresponding schema or linkbase file. Each language is stored in a separate label linkbase file. The naming convention for these label linkbase files is:

{main-file}-lab-{lang}.xml

where {main-file} corresponds to the name of the schema or linkbase file where the concept is defined (without extension) and {lang} component represents the ISO 639-1 code of the language (lowercase).

In addition to this, some concepts of the dictionary may contain a special linkbase to represent codes needed for different purposes. In particular, the codes given to the columns and rows of tables or codes assigned to the data points are represented using this mechanism. The name of these linkbase files constructed as follows:

{main-file}-lab-{lang}-codes.xml or {main-file}-lab-codes.xml

In case of the later, the distinction between codes appearing in different language versions is determined basing on xml:lang attribute on label resources. The labels for these codes are represented as resources with a custom role. The role defined in the model.xsd schema for resources representing codes of rows or columns is http://www.eurofiling.info/xbrl/role/rc-code.

Dictionary of concepts

The core concepts of the dictionary are metrics, dimensions, domains and domain members. Secondary concepts are families and perspectives (auxiliary concepts meant to group dimensions for presentation purposes). All the concepts in the dictionary are public elements.

To cope with changes in the reporting, in addition to the properties and language specific information of public elements, dictionary elements include two optional attributes that establish its currency period: the starting date of the period interval (model:fromDate attribute) and its end date (model:toDate attribute). If the model:fromDate attribute is not included, then the concept is assumed to be valid for any period prior to the model:toDate attribute. If the model:toDate attribute is not included, then the concept is assumed to be valid for any period after the model:fromDate attribute. If neither model:fromDate nor model:toDate attributes are included, then the concept is assumed to be current for any period of time. The first versions of the dictionary will not include these attributes. As new versions are released and some concepts become obsolete and replaced by others, these attributes will be updated. These attributes don’t have any impact on the reporting process itself; they are meant to simplify the management of the concepts of the dictionary.

All files in the dictionary of concepts are placed under the folder dict in the official location of its owner (see Table 3). Its namespace is obtained by adding a suffix that depends on the type of element to the namespace of the owner. The prefix to represent that namespace is obtained by adding a predefined suffix to the prefix of its owner (as presented in Table 4) where {oloc} represents the official location of taxonomy files of the owner of the concepts, {ons} its base namespace, {opre} the prefix of its base namespace, and {dc}/{DC} the code of a domain in lower and capital case.

Dictionary concept	Official location	Target namespace	Namespace prefix
Metrics	{oloc}/dict/met/met.xsd	{ons}/dict/met	{opre}_met
Dimensions	{oloc}/dict/dim/dim.xsd	{ons}/dict/dim	{opre}_dim
Explicit domains	{oloc}/dict/dom/exp.xsd	{ons}/dict/exp	{opre}_exp
Typed domains	{oloc}/dict/dom/typ.xsd	{ons}/dict/typ	{opre}_typ
Explicit domain members	{oloc}/dict/dom/{dc}/mem.xsd	{ons}/dict/dom/{DC}	{opre}_{DC}

Examples of location, target namespace and its prefix for dictionary concepts of the taxonomy are listed below:

Dictionary concept	Official location	Target namespace	Namespace prefix
Cross-sector metrics	http://www.eurofiling.info/xbrl/dict/met	http://www.eurofiling.info/eu/fr/xbrl/dict/met/met.xsd	eu_met
Cross-sector dimensions	http://www.eurofiling.info/xbrl/dict/dim	http://www.eurofiling.info/eu/fr/xbrl/dict/dim/dim.xsd	eu_dim
EBA explicit domains	http://www.eba.europa.eu/xbrl/dict/exp	http://www.eba.europa.eu/eu/fr/xbrl/dict/dom/exp.xsd	eba_exp
EBA typed domains	http://www.eba.europa.eu/xbrl/dict/typ	http://www.eba.europa.eu/eu/fr/xbrl/dict/dom/typ.xsd	eba_typ
SE explicit domain members example (domain CP)	http://www.bde.se/xbrl/dict/dom/CP	http://www.bde.se/se/fr/xbrl/dict/dom/CP	se_CP
EBA families	http://www.eba.europa.eu/xbrl/dict/fam	http://www.eba.europa.eu/eu/fr/xbrl/dict/dim/fam.xsd	eba_fam
EBA perspectives	http://www.eba.europa.eu/xbrl/dict/pers	http://www.eba.europa.eu/eu/fr/xbrl/dict/dim/pers.xsd	eba_pers

Metrics

Metrics define the nature of the measure to be performed. Metrics determine the data type, the period type (instant / duration) plus additional semantics of their corresponding data points. Metrics are represented in XBRL as primary items and defined in schema files named met.xsd that reference label linkbase files. A local name of metrics is composed of three components:

a letter that represents the data type in lower case (for available options see the table below),
a letter that represents the period type: i for instant and d for duration,
a number that corresponds to the numeric code in the model (no zero padding or predetermined length).

Model data type	XBRL data type	Local name codification letter	Reporting unit
Monetary (currency)	xbrli:monetaryItemType	m	Adequate currency using ISO 4217 codification (e.g.: iso4217:EUR)
Percent	num:percentItemType	p	xbrli:pure
Decimal	xbrli:decimalItemType	p	xbrli:pure
Integer	xbrli:integerItemType	i	xbrli:pure
Date	xbrli:dateItemType	d	not applicable
Boolean	xbrli:booleanItemType	b	not applicable
Text	xbrli:stringItemType	s	not applicable
Explicit domain	xbrli:qnameItemType	e	not applicable
Typed domain	typed domain corresponding data type, e.g. xbrli:stringItemType if a typed domain is xs:string

In case of domain based data types, an additional attribute (model:domain) is included to identify the qualified name of the explicit or typed domain (e.g. model:domain="eba:GA").

The id of the element (necessary for XLink locators) is composed as:

{opre}_{name}

where {opre} represents the prefix of the base namespace of the owner of the base item and {name} represents the name described above.

The following table contains a few examples of metrics declared in a taxonomy.

Owner	Data / period type	Code	Name	Id	Namespace	Prefix
Cross-sector	Boolean / duration	3	bd3	eu_bd3	http://www.eurofiling.info/xbrl/dict/met	eu_met
Cross-sector	Monetary / duration	7	md7	eu_md7	http://www.eurofiling.info/xbrl/dict/met	eu_met
EBA	Monetary / instant	7	mi7	eu_mi7	http://www.eba.europa.eu/xbrl/dict/met	eba_met
EBA	Text / instant	7	si7	eu_si7	http://www.eba.europa.eu/xbrl/dict/met	eba_met
BdE	Boolean / duration	3	bd3	se_bd3	http://www.bde.se/xbrl/dict/met	se_met
BdE	Monetary / duration	7	md7	se_md7	http://www.bde.se/xbrl/dict/met	se_met

Metrics can be arranged in hierarchies. Hierarchies are represented using XBRL extended link roles whose role type URI is built according to the following pattern:

{ons}/role/dict/mem/{hierarchy-code}

where {ons} represents the namespace of the owner and {hierarchy-code} the numeric code of the hierarchy. Value of id attribute of these roles is composed following the pattern:

{opre}_{code}

Examples of extended link roles used for hierarchies of metrics are presented in the table below:

As a DPM is the source of a transformation process with an XBRL taxonomy as its target graph transformations are being used to describe how the structure of a DPM, represented as class diagram in UML, is mapped to an UML class diagram visualising the underlying XBRL structure. To express the model transformation the UML source model of the DPM as well as the UML target model for representing the XBRL structure is given. Between the two graphs an abstract transformation syntax is used to describe the transformation rules from the source to the target model. The graph transformation intends to ease the understanding of the correlation between data structures reflected in Data Point Models and how these objects and structures can be matched to an XBRL data format. The graph transformation is limited to an essential part of the whole process. UML class diagrams reflecting the XBRL specification structure are visualized in the Aspect Model 2.0 of XBRL International.

The transformation process starts from the DPM UML graph on the left hand side marked in blue to the UML class diagram using red squares to visualize the XBRL structure. The black arrows between both UML class diagrams are not part of the general UML language but customized extensions which are used to describe the graph transformation. The square between two black arrows contains an abbreviation what is being mapped. We distinguish eight different types of mappings rules between the two graphs:

C2C - transformation from an UML class in the DPM meta model in an UML class representing an XBRL concept,
A2A - transformation from an attributevof a DPM meta class to an attribute of an XBRL element,
A2R - transformation from an attribute of a DPM meta class to a XBRL resource as part of an XBRL linkbase,
A2E - transformation from an attribute of a DPM meta class to its XML element representation in XBRL,
C2RS - transformation of an UML class of the DPM meta model to an UML class representing an Relationship which is located in an XBRL linkbase,
RS2RS - transformation of an UML class of the DPM meta model representing an Relationship to an UML class representing an Relationship which is located in an XBRL linkbase,
C2Arc - transformation of an UML class of the DPM meta model to an XBRL arc combining two XBRL elements, in the given examples resources,
C2E - transformation of an UML class of the DPM meta model to a table linkbase specific XBRL element which links to an XBRL concept.

The graph above shows how the meta class DimensionedElement of the DPM meta model is mapped to an XBRL concept with its corresponding XBRL attributes according to the EXTA definitions. Dimensioned Elements are known as metrics in the EXTA (synonym in XBRL: Primary item). Dimensioned Elements are part of the Dictionary so they inherit the attributes defined by the abstract concept of a Dictionary element. The abstract Dictionary element is subordinated element of the abstract meta class representing a Public element so the Dimensioned Element inherits also the attributes defined by this superordinated element. In XBRL terms a metric in EXTA must include at least the attribute model:creationDate of the custom attributes.

Taxonomy Architecture Description

Introduction

The purpose of this document is to present and explain the architecture of the XBRL taxonomies defined by the CEN WS XBRL. In particular, it explains the scope (coverage of information requirements), modularization in files, manner of defining concepts and relations and other important design aspects. This document is aimed at users of the CEN WS XBRL compliant taxonomies, in particular editors of the taxonomy or producers of instance documents (by applying mappings to internal systems or assigning XBRL tags with values in any other manner) as well as developers of the IT solutions facilitating reporting in the XBRL format or analysis of XBRL data. Comprehension of the Extensible Business Reporting Language (XBRL) 2.1 Specification and other XBRL Specifications such as XBRL Dimensions 1.0, XBRL Formula 1.0, Generic Link 1.0 and Table Linkbase 1.0 (Public Working Draft as of 21 December 2011) is required to comprehend the content of this document.

Important assumptions

For modelling of data and its formal as well as physical representation in XBRL format, the CEN WS XBRL follows the approached applied for various deliverables of the Eurofiling project and the draft assumptions for the EBA products. The reason for this decision is assumed future alignment of the Bundesbank data models and taxonomies with the final EBA products (COREP, FINREP, etc). Therefore, the Bundesbank applied the Data Point Modelling for description of each exchanged data field . In terms of reflection of the model semantics in XBRL syntax, the Bundesbank follows the assumptions and plans for the architecture of the EBA taxonomies . In addition to that, the Bundesbank XBRL taxonomies architecture obeys certain rules on defining and modelling of metadata in order to increase their reusability by the consuming applications, in particular the supervisory and analytical systems.

Data model

Prior to the development of taxonomy, information requirements need to be identified specifying reportable concepts and relations between them. This is done in the form of data models. The main input in creation of data models are reporting templates, i.e. tabular representation of information requirements as they exist at the moment as well as supportive laws and regulations. These temples, laws and regulations are analysed in order to create a Data Point Model (DPM). The main deliverables of the Data Point Modelling methodology consists of two types of MS Excel workbooks:  DPM dictionary, defining properties and classifications (breakdowns) that can be used to describe each data point,  Annotated Templates, which are the input (original) reporting templates where each row/column is associated with a property or a set of properties defined in the DPM dictionary. The Bundesbank taxonomies were created by translation of the DPM into XBRL syntax basing on the rules described in this document.

Scope

The Bundesbank XBRL taxonomies resemble the content of the DPM dictionary and the Annotated Templates. They reflect information requirements for filings that are submitted by institutions supervised by the Bundesbank according to the German banking and other reporting regulations.

Components of the information requirements

Components of the information requirements currently include:  statistical data: − Monthly Balance Sheet Statistics [MBS ],  supervisory data: − Financial Reporting [FR] and Monthly Return [MR] reports jointly referred to as FMR , − other miscellaneous reports (referred to as MISC) consisting of:  Liquidity regulation [LR],  Leverage ratio [ER],  Interest Risk information [IR],  other. The division into statistical and supervisory data results from the current process of the DPM development. It is possible, that in the future these two separate at the moment datasets are merged into a single dataset. MBS, FMR and MISC are called frameworks. All frameworks apart from the MBS (which is defined in the statistical dataset) use the same definitions declared in the DPM dictionary. Information requirements and taxonomy scope overview diagram is provided in Annex C to this document.

Scope extension

It is expected that the scope of information requirements covered by DPM and XBRL taxonomy may be extended in the future for other reporting domains, in particular for the German extension of the COREP and FINREP data models and taxonomies developed currently by the European Banking Authority [EBA]. Architecture of the XBRL taxonomies, as defined in the next sections of this document, already addresses the manner of including these extensions in scope.

XBRL specifications compliance

Following the XBRL standard requirements, the Bundesbank taxonomies and any assisting reports (XBRL instance documents) are compliant with:  XBRL 2.1 specification as of December 31, 2003 with Errata Corrections up to January 25, 2012,  Dimensions 1.0 specification as of September 18, 2006 with errata corrections up to January 25, 2012. The business rules layer in the form of linkbase files is defined according to the XBRL Formula Specification 1.0 - 2009 – 2011 and supporting specifications (Registry – 2009-2011, Generic Links – June 22, 2009). Rendering of tables is created according to the most recent version of the Table Linkbase specification (as of December 21, 2011) published on www.xbrl.org website. It is expected that in the future the taxonomies shall comply with the version of this specification in recommendation status .

XBRL taxonomy components

Model supporting schema

The XBRL representation of the model makes use of some schema definitions in the namespace http://www.eurofiling.info/xbrl/ext/model. The official location of this schema file will be http://www.eurofiling.info/eu/fr/xbrl/ext/model.xsd however at the moment it is not yet stored in this location. Due to the fact, that taxonomy files reference the official location, applications using the taxonomy require mappings to the local file which is included in the taxonomy package (in folder www.eurofiling.info/eu/fr/xbrl/ext/). Throughout this section of the document, the prefix model will be used to make references to this schema namespace.

Other XBRL technical files

Taxonomy package contains also all files defined by various XBRL specifications and registries. They are placed in folder www.xbrl.org and its subfolder. Taxonomy references the official location of these files on www.xbrl.org website. Some of these files however are not yet available in their official location and local mappings may be required. This is for example the case of technical files supporting the Public Working Draft of Table Linkbase specification, which can be found in the taxonomy package in folder www.xbrl.org/2011. For clarity of this document, XBRL technical constructs are referenced by their qualified names [QNames] . Prefixes applied in this QNames to abbreviate the namespaces are listed in Table 1. Table 1. Prefixes and namespaces of the XBRL technical files referenced in this document

Prefix	Namespace
xs	http://www.w3.org/2001/XMLSchema
xbrli	http://www.xbrl.org/2003/instance
xbrldt	http://xbrl.org/2005/xbrldt
iso4217	http://www.xbrl.org/2003/iso4217
nonnum	http://www.xbrl.org/dtr/type/non-numeric
link	http://www.xbrl.org/2003/linkbase
label	http://xbrl.org/2008/label

6.3 Public elements Public elements are all concepts of the model that are identified by a code in a certain scope and may include some additional information such as readable labels, definitions and legal references in different languages. Public elements include two attributes to reflect their creation date (model:creationDate) and the date when they was last modified (model:modificationDate). Language specific information of public elements is represented using the following label resources:  XBRL 2.1 labels (link:label) for xbrli:items (or derived) public elements,  generic labels (label:label) for public elements represented as XLink resources or other construct (e.g. link:roleTypes). The default (standard) role (http://www.xbrl.org/2003/role/link) is used for the extended links containing the label resources. The role types used as roles for generic and standard label resources are presented in Table 2. Table 2. Role types used as roles for generic and standard label resources Property Generic label role Standard label role Name http://www.xbrl.org/2008/role/label http://www.xbrl.org/2003/role/label Definition http://www.xbrl.org/2008/role/verboseLabel http://www.xbrl.org/2003/role/verboseLabel Legal references http://www.xbrl.org/2008/role/documentation http://www.xbrl.org/2003/role/documentation The labels of the concepts of a schema or a linkbase file are represented jointly in a separate label linkbase file distinguished by language, in the same folder as its corresponding schema or linkbase file. Each language is stored in a separate label linkbase file. The naming convention for these label linkbase files is: {main-file}-lab-{lang}.xml where {main-file} corresponds to the name of the schema or linkbase file where the concept is defined (without extension) and {lang} component represents the ISO 639-1 code of the language (lowercase). The primary language for all Bundesbank taxonomies is German (ISO 639-1 code “de”) and secondary language is English (ISO 639-1 code “en”). In addition to this, some concepts of the dictionary may contain a special linkbase to represent codes needed for different purposes. In particular, the codes given to the columns and rows of tables or codes assigned to the data points are represented using this mechanism. The name of these linkbase files constructed as follows: {main-file}-lab-{lang}-codes.xml or {main-file}-lab-codes.xml In case of the later, the distinction between codes appearing in different language versions is determined basing on xml:lang attribute on label resources. The labels for these codes are represented as resources with a custom role. The role defined in the model.xsd schema for resources representing codes of rows or columns is http://www.eurofiling.info/xbrl/role/rc-code. 6.4 Logical taxonomy architecture This section describes in detail the components and content of the XBRL taxonomy model applied in the taxonomy. The diagram provided in Annex B: Taxonomy architecture diagram may be helpful in reading and understanding this section of the document. 6.4.1 Taxonomy levels and owners Taxonomy concepts could be defined on one of the three levels: 1) cross sector concepts and breakdowns (to be shared between different institutions e.g. banking, insurance and securities supervision), 2) concepts from the EBA information requirements, 3) concepts defined by the Bundesbank: i) for statistics purposes, ii) for supervisory purposes. Level one are cross sector concepts that shall be eventually defined and agreed by a joint group of experts involved in setting up information requirements for different sectors such as banking, insurance and reporting of other commercial and non-profit companies. It is expected, that these concepts will mainly include the list of countries and currencies as defined by the ISO codes and subsequently extended by for example economy sectors, classes of financial instruments, accounting portfolios, time intervals, etc. This task will be most likely conducted by reconciliation between the dictionaries of business concepts defined by the EBA, EIOPA and other interested parties. Cross sector concepts will be published in the Eurofiling on-line resources as a set of XBRL schema and linkbase files that can be referenced from level two or level three dictionaries. Level two are the EBA concepts. They represent the information requirements of COREP, FINREP and other scope defined on the European level. They may refer to and extend level one (cross-sector) concepts. Level three are the concepts of national supervisors, in this case represented by the Bundesbank. They reflect information requirements set by the German legislation and specific banking regulations. In case of the Bundesbank taxonomies, this level is divided in information requirements related to statistics and supervisory reporting for the scope and frameworks presented in 4.1 Components of the information requirements section of this document. The reason for splitting level three is the underlying DPM which is currently defined separately for statistics and supervisory data. The idea of levels for concepts definitions has been addressed in the XBRL taxonomy model by introducing the notion of the owner. The owner represents an institution that defines concepts of the model. The owner is closely related to the idea of extensibility in XBRL. The main properties of the owner are:  owner’s namespace {ons},  owner’s prefix {opre}, and  official location {oloc}. The owner namespace {ons} is a URI used to establish the namespace of the concepts defined by that owner. This URI is generally built by adding xbrl to the internet domain of the institution that the owner represents. In case of the Bundesbank, the domain is extended by stat and sprv components to distinguish between statistical and supervisory datasets. The prefix {opre} is used as the basis to establish namespace prefixes in taxonomy files and for some short representations of the concepts by QNames using shorter prefixes (instead of long namespaces) plus the local name . Official location {oloc} is a URL used to specify the location where taxonomy files associated to that owner are to be published. Different owners must have different official locations, even owners with the same internet domain/same namespace. The official location is generally built by adding three parts to the internet domain of the institution:  representation of the geographical area covered by the institution (e.g. eu in case of the cross sector or the EBA concepts or de for the Bundesbank specific concepts applied in Germany),  indication of the scope of information requirement (e.g. fr for general financial reporting, stat for statistical data, sprv for supervisory data, etc)  fixed xbrl component identifying the type of standard used to express information requirements. Table 3 presents examples of owners and applied namespaces, prefixes and official locations of taxonomy files. Table 3. Examples of namespaces, prefixes and official locations of taxonomies files for different owners Owner Namespace Prefix Official location Cross-sector http://www.eurofiling.info/xbrl eu http://www.eurofiling.info/eu/fr/xbrl EBA http://www.eba.europa.eu/xbrl eba http://www.eba.europa.eu/eu/fr/xbrl Bundesbank, Statistics http://www.bundesbank.de/stat/xbrl de_stat http://www.bundesbank.de/de/stat/xbrl Bundesbank, Supervision http://www.bundesbank.de/sprv/xbrl de_sprv http://www.bundesbank.de/de/sprv/xbrl Other properties of the owner are the copyright (text used as a header in every taxonomy file) and the list of supported languages. 6.4.2 Header information Header taxonomy is located at the first level in entire taxonomy structure (under http://www.bundesbank.de/de/ext/ folder”), which means it can be applied to different reporting purposes. Applicability to many reporting frameworks imposed departure from some architectural constructs proposed by the EBA, e.g. ownership of elements or division into dictionary layer and reporting layer. The purpose of the header taxonomy is to provide basic information about reporting entity, contact data and reporting periods. Header taxonomy consists of three files: − bbk-basis.xsd – schema file containing element declarations, − bbk-basis-label.xml – label linkbase file with German and English labels for header taxonomy concepts, − data-types.xsd – schema file with definition of specific (custom) data types used in bbk-basis.xsd to impose constraints on possible to reported Header taxonomy is later imported by the modules in the framework section. The currently applied solution for inclusion of header taxonomy items may be replaced in the future by a different approach, e.g. recommended by the CEN/WS XBRL . 6.4.3 Filing indicators Filing indicators serve the purpose of communicating the scope of the reported data based on templates. The main purposes of filing indicators are:  provide hints to applications using the taxonomy, on which templates/forms are included in the filing and for example shall be displayed to users,  trigger execution of business rules (value assertions) to be run on a filing to check its correctness depending on the reported scope of data. In technical terms, filing indicators are facts included as part of an instance document where the filer estates which templates/forms are being reported. Each template/form is represented as an instance fact of the item “table” under the “fIndicators” tuple element. These elements are defined in the namespace http://www.eurofiling.info/xbrl/ext/filing-indicators. The official location of this schema file is http://www.eurofiling.info/eu/fr/xbrl/ext/filing-indicators.xsd. This schema file is imported in every taxonomy module (see 6.4.5.4 Modules) Throughout this document, the prefix find will be used to make reference to this schema namespace. The following instance excerpt represents a filing with information about templates/forms with codes EJB and EGV: <find:fIndicators> <find:table contextRef=”ctx”>EJB</find:table> <find:table contextRef=”ctx”>EGV</find:table> </find:fIndicators> Context to which facts representing find:table element refer must identify the reporting entity and use the instant date which is the end date of the reporting period. Table codes to be used on find:table facts are the ones identified by {template code} component of the documentation label of tabel:table resource (see 6.4.5.3 Tables). If a template results in multiple tables (as a result of its original arrangement in multiple physical tables or due to normalization process) it is identified by find:table fact only once. 6.4.4 Dictionary layer 6.4.4.1 Core concepts The core concepts of the dictionary are metrics, dimensions, domains and domain members. Secondary concepts are families and perspectives (auxiliary concepts meant to group dimensions for presentation purposes). All the concepts in the dictionary are public elements. To cope with changes in the reporting, in addition to the properties and language specific information of public elements, dictionary elements include two optional attributes that establish its currency period: the starting date of the period interval (model:fromDate attribute) and its end date (model:toDate attribute). If the model:fromDate attribute is not included, then the concept is assumed to be valid for any period prior to the model:toDate attribute. If the model:toDate attribute is not included, then the concept is assumed to be valid for any period after the model:fromDate attribute. If neither model:fromDate nor model:toDate attributes are included, then the concept is assumed to be current for any period of time. The first versions of the dictionary will not include these attributes. As new versions are released and some concepts become obsolete and replaced by others, these attributes will be updated. These attributes don’t have any impact on the reporting process itself; they are meant to simplify the management of the concepts of the dictionary. All files in the dictionary of concepts are placed under the folder dict in the official location of its owner (see Table 3). Its namespace is obtained by adding a suffix that depends on the type of element to the namespace of the owner. The prefix to represent that namespace is obtained by adding a predefined suffix to the prefix of its owner (as presented in Table 4) where {oloc} represents the official location of taxonomy files of the owner of the concepts, {ons} its base namespace, {opre} the prefix of its base namespace, and {dc}/{DC} the code of a domain in lower and capital case. Table 4. Pattern for location, target namespace and its prefix for dictionary concepts Dictionary concept Official location Target namespace Namespace prefix Metrics {oloc}/dict/met/met.xsd {ons}/dict/met {opre}_met Dimensions {oloc}/dict/dim/dim.xsd {ons}/dict/dim {opre}_dim Explicit domains {oloc}/dict/dom/exp.xsd {ons}/dict/exp {opre}_exp Typed domains {oloc}/dict/dom/typ.xsd {ons}/dict/typ {opre}_typ Explicit domain members {oloc}/dict/dom/{dc}/mem.xsd {ons}/dict/dom/{DC} {opre}_{DC} Examples of location, target namespace and its prefix for dictionary concepts of the taxonomy are presented in Table 5. Table 5. Examples of location, target namespace and its prefix for dictionary concepts Dictionary concept Prefix Target namespace Official location Cross-sector metrics eu_met http://www.eurofiling.info/xbrl/dict/met http://www.eurofiling.info/eu/fr/xbrl/dict/met/met.xsd Cross-sector dimensions eu_dim http://www.eurofiling.info/xbrl/dict/dim http://www.eurofiling.info/eu/fr/xbrl/dict/dim/dim.xsd Cross-sector explicit domains eu_exp http://www.eurofiling.info/xbrl/dict/exp http://www.eurofiling.info/eu/fr/xbrl/dict/dom/exp.xsd Cross-sector typed domains eu_typ http://www.eurofiling.info/xbrl/dict/typ http://www.eurofiling.info/eu/fr/xbrl/dict/dom/typ.xsd Cross-sector explicit domain members example (domain GA) eu_GA http://www.eurofiling.info/xbrl/dict/dom/GA http://www.eurofiling.info/eu/fr/xbrl/dict/dom/ga/mem.xsd EBA metrics eba_met http://www.eba.europa.eu/xbrl/dict/met http://www.eba.europa.eu/eu/fr/xbrl/dict/met/met.xsd EBA dimensions eba_dim http://www.eba.europa.eu/xbrl/dict/dim http://www.eba.europa.eu/eu/fr/xbrl/dict/dim/dim.xsd EBA explicit domains eba_exp http://www.eba.europa.eu/xbrl/dict/exp http://www.eba.europa.eu/eu/fr/xbrl/dict/dom/exp.xsd EBA typed domains eba_typ http://www.eba.europa.eu/xbrl/dict/typ http://www.eba.europa.eu/eu/fr/xbrl/dict/dom/typ.xsd EBA explicit domain members example (domain CP) eba_CP http://www.eba.europa.eu/xbrl/dict/dom/CP http://www.eba.europa.eu/eu/fr/xbrl/dict/dom/cp/mem.xsd EBA families eba_fam http://www.eba.europa.eu/xbrl/dict/fam http://www.eba.europa.eu/eu/fr/xbrl/dict/dim/fam.xsd EBA perspectives eba_pers http://www.eba.europa.eu/xbrl/dict/pers http://www.eba.europa.eu/eu/fr/xbrl/dict/dim/pers.xsd Bundesbank statistics metrics de_stat_met http://www.bundesbank.de/stat/xbrl/dict/met http://www.bundesbank.de/de/stat/xbrl/dict/met/met.xsd Bundesbank statistics dimensions de_stat_dim http://www.bundesbank.de/stat/xbrl/dict/dim http://www.bundesbank.de/de/stat/xbrl/dict/dim/dim.xsd Bundesbank statistics explicit domains de_stat_exp http://www.bundesbank.de/stat/xbrl/dict/exp http://www.bundesbank.de/de/stat/xbrl/dict/dom/exp.xsd Bundesbank statistics typed domains de_stat_typ http://www.bundesbank.de/stat/xbrl/dict/typ http://www.bundesbank.de/de/stat/xbrl/dict/dom/typ.xsd Bundesbank statistics explicit domain members example (domain SE) de_stat_SE http://www.bundesbank.de/stat/xbrl/dict/dom/SE http://www.bundesbank.de/de/stat/xbrl/dict/dom/se/mem.xsd Bundesbank supervision metrics de_sprv_met http://www.bundesbank.de/sprv/xbrl/dict/met http://www.bundesbank.de/de/sprv/xbrl/dict/met/met.xsd Bundesbank supervision dimensions de_sprv_dim http://www.bundesbank.de/sprv/xbrl/dict/dim http://www.bundesbank.de/de/sprv/xbrl/dict/dim/dim.xsd Bundesbank supervision explicit domains de_sprv_exp http://www.bundesbank.de/sprv/xbrl/dict/exp http://www.bundesbank.de/de/sprv/xbrl/dict/dom/exp.xsd Bundesbank supervision typed domains de_sprv_typ http://www.bundesbank.de/sprv/xbrl/dict/typ http://www.bundesbank.de/de/sprv/xbrl/dict/dom/typ.xsd Bundesbank supervision explicit domain members example (domain SC) de_sprv_SC http://www.bundesbank.de/sprv/xbrl/dict/dom/SC http://www.bundesbank.de/de/sprv/xbrl/dict/dom/sc/mem.xsd Bundesbank supervision explicit domain members example (extension of EBA domain CP) de_sprv_eba_SC http://www.bundesbank.de/sprv/xbrl/dict/dom/de_stat_eba_SC http://www.bundesbank.de/de/sprv/xbrl/dict/dom/eba_cp/mem.xsd 6.4.4.2 Metrics Metrics define the nature of the measure to be performed. Metrics determine the data type, the period type (instant / duration) plus additional semantics of their corresponding data points. Metrics are represented in XBRL as primary items and defined in schema files named met.xsd that reference label linkbase files. A local name of metrics is composed of three components: 1. a letter that represents the data type in lower case (for available options see Table 6 below), 2. a letter that represents the period type: i for instant and d for duration, 3. a number that corresponds to the numeric code in the model (no zero padding or predetermined length). Table 6. Model and XBRL data type, local name codification letter and reporting unit. Model data type XBRL data type Local name codification letter Reporting unit Monetary (currency) xbrli:monetaryItemType m Adequate currency using ISO 4217 codification (e.g.: iso4217:EUR) Percent num:percentItemType p xbrli:pure Decimal xbrli:decimalItemType p xbrli:pure Integer xbrli:integerItemType i xbrli:pure Date xbrli:dateItemType d not applicable Boolean xbrli:booleanItemType b not applicable Text xbrli:stringItemType s not applicable Explicit domain xbrli:qnameItemType e not applicable Typed domain typed domain corresponding data type, e.g. xbrli:stringItemType if a typed domain is xs:string e depending on typed domain, usually xbli:pure In case of domain based data types, an additional attribute (model:domain) is included to identify the qualified name of the explicit or typed domain (e.g. model:domain="eba:GA"). The id of the element (necessary for XLink locators) is composed as: {opre}_{name} where {opre} represents the prefix of the base namespace of the owner of the base item and {name} represents the name described above. Table 7 contains a few examples of metrics declared in the taxonomy. Table 7. Examples of metrics in the taxonomy. Owner Data / period type Code Name Id Namespace Prefix Cross-sector Boolean / duration 3 bd3 es_bd3 http://www.eurofiling.info/xbrl/dict/met eu_met Cross-sector Monetary / duration 7 md7 es_md7 http://www.eurofiling.info/xbrl/dict/met eu_met EBA Monetary / instant 7 mi7 eba_mi7 http://www.eba.europa.eu/xbrl/dict/met eba_met EBA Text / instant 7 si7 eba_si7 http://www.eba.europa.eu/xbrl/dict/met eba_met Bundesbank Statistics Text / duration 10 sd10 de_stat_sd10 http://www.bundesbank.de/stat/xbrl/dict/met de_stat_met Bundesbank Supervision Date / duration 5 dd5 de_sprv_dd5 http://www.bundesbank.de/sprv/xbrl/dict/met de_sprv_met Metrics can be arranged in hierarchies. Hierarchies are represented using XBRL extended link roles whose role type URI is built according to the following pattern: {ons}/role/dict/mem/{hierarchy-code} where {ons} represents the namespace of the owner and {hierarchy-code} the numeric code of the hierarchy. Value of id attribute of these roles is composed following the pattern: {opre}_{code} Examples of extended link roles used for hierarchies of metrics are presented in Table 12. Table 8. Extended link roles used for hierarchies of metrics Owner Hierarchy code Role URI Role id Cross-sector 1 http://www.eurofiling.info/xbrl/role/dict/met/1 eu_1 EBA 1 http://www.eba.europa.eu/xbrl/role/dict/met/1 eba_1 Bundesbank Statistics 4 http://www.bundesbank.de/stat/xbrl/role/dict/met/4 de_stat_4 Bundesbank Supervision 2 http://www.bundesbank.de/sprv/xbrl/role/dict/met/2 de_sprv_2 The schema file that represents hierarchies (defining role types and referring linkbases) is placed in the same folder as metrics and it is named hier.xsd. Examples of such schema files, their namespaces and prefixes are presented in Table 13. Table 9. Examples of schema files defining hierarchies for domain members Owner Hierarchies schema Namespace Prefix Cross-sector http://www.eurofiling.info/xbrl/dict/met/hihi.xsd http://www.eurofiling.info/xbrl/dict/met/hier eu_met_h EBA http://www.eba.europa.eu/xbrl/dict/met/hier.xsd http://www.eba.europa.eu/xbrl/dict/met/hier eba_met_h Bundesbank Statistics http://www.bundesbank.info/stat/xbrl/dict/met/hier.xsd http://www.bundesbank.info/stat/xbrl/dict/met/hier de_stat_met_h Bundesbank Supervision http://www.bundesbank.info/sprv/xbrl/dict/met/hier.xsd http://www.bundesbank.info/sprv/xbrl/dict/met/hier de_sprv_met_h Each hierarchy can have a label (or labels in multiple languages). Standard label (generic label with standard role) contains description for a hierarchy purpose/content and may include hints on application of the hierarchy in templates. In addition to labels, these schemas refer to three additional linkbases with information about hierarchies: - a presentation linkbase (hier-pre.xml), - a definition linkbase (hier-def.xml), - a calculation linkbase (hier-cal.xml). Application and purpose of these linkbases identical as in case of hierarchies of domain members (see section 6.4.4.3.1 of this document). 6.4.4.3 Domains Explicit domains are represented using XBRL abstract items of domain type model:explicitDomainType in the schema file exp.xsd. Typed domains are represented as XML elements that are not in the substitution group of xbrli:item. These elements are defined in the schema file typ.xsd . The local name of each domain corresponds to its code in the model: {dom-code}, which is a short sequence of capital case letters (usually two, but may be more). Value of the id attribute of the element (necessary for XLink locators) is composed according to the following pattern: {opre}_{name} where {opre} represents the prefix of the base namespace of the owner of the domain and {name} represents the name described above. Some examples of domains items are presented in Table 10. Table 10. Examples of domain items Owner Code Element Name Type Id Namespace Prefix Cross-sector GA GA Explicit eu_GA http://www.eurofiling.info/xbrl/dict/exp eu_exp EBA CO CO Explicit eba_CO http://www.eba.europa.eu/xbrl/dict/exp eba_exp EBA MI MI Typed eba_MI http://www.eba.europa.eu/xbrl/dict/typ eba_typ Bundesbank Statistics CG CG Explicit de_stat_CG http://www.bundesbank.de/stat/xbrl/dict/exp de_stat_exp Bundesbank Supervision ICTX ICTX Typed de_sprv_ICTX http://www.bundesbank.de/sprv/xbrl/dict/typ de_sprv_typ Although the namespace of explicit and typed domains is different, different local names should be used anyway to avoid confusion. Also the local names of domain items for Bundesbank Statistics and Bundesbank Supervision must be unique (repeating the same code in each dataset must be avoided). 6.4.4.3.1 Explicit domain members and hierarchies Explicit domain members are represented using XBRL abstract items of domain item type defined in the non-numeric set of types of the XBRL International type registry: nonnum:domainItemType. The local name of each explicit domain member corresponds to its numeric code in the model preceded by a lower case x . If the concept represented already has a widely accepted standard codification, like ISO codes or UN code lists, the local name will match the existing codification in lower case. More specifically, the following ISO codes are used: − ISO 4217: standard currency codes composed of three alphabetical characters, − ISO 3166-1 alpha-2: standard country codes composed of two alphabetical characters. Value of the id attribute of explicit domain members follows the general rule: {opre}_{name} The default domain member of a domain (usually the one with numeric code component of the name set to 0) is marked with an attribute: model:isDefaultMember=”true”. A special domain, identified in the model with code BC (Base categories), may define members whose declaration includes an additional xbrli:balance attribute specifying the credit or debit nature of the financial concept (according to the double entry accounting rule). The schema file that represents explicit members is placed in a folder with the name of its corresponding domain. The schema file for explicit domain members is called mem.xsd. Examples of schema files defining explicit domain members in the taxonomies are presented in Table 11. Table 11. Examples of schema files defining explicit domain members Owner Domain code Domain members schema Namespace Prefix Cross-sector GA http://www.eurofiling.info/xbrl/dict/dom/ga/mem.xsd http://www.eurofiling.info/xbrl/dict/dom/GA eu_GA EBA CO http://www.eba.europa.eu/xbrl/dict/dom/co/mem.xsd http://www.eba.europa.eu/xbrl/dict/dom/CO eba_CO EBA MI http://www.eba.europa.eu/xbrl/dict/dom/mi/mem.xsd http://www.eba.europa.eu/xbrl/dict/dom/MI eba_MI Bundesbank Statistics CG http://www.bundesbank.info/stat/xbrl/dict/dom/cg/mem.xsd http://www.bundesbank.info/stat/xbrl/dict/dom/CG de_stat_CG Bundesbank Supervision AP http://www.bundesbank.info/sprv/xbrl/dict/dom/ap/mem.xsd http://www.bundesbank.info/sprv/xbrl/dict/dom/AP de_sprv_AP Hierarchies are represented using XBRL extended link roles whose role type URI is built according to the following pattern: {ons}/role/dict/dom/{dom-code}/{hierarchy-code} where {ons} represents the namespace of the owner, {dom-code} represents the code of the domain and {hierarchy-code} the numeric code of the hierarchy. Value of id attribute of these roles is composed following the pattern: {opre}_{code} Examples of extended link roles used for hierarchies of domains are presented in Table 12. Table 12. Extended link roles used for hierarchies of domains Owner Domain code Hierarchy code Role URI Role id Cross-sector GA 1 http://www.eurofiling.info/xbrl/role/dict/dom/GA/1 eu_1 EBA CO 1 http://www.eba.europa.eu/xbrl/role/dict/dom/CO/1 eba_1 EBA CS 1 http://www.eba.europa.eu/xbrl/role/dict/dom/CS/1 eba_1 EBA GA 2 http://www.eba.europa.eu/xbrl/role/dict/dom/GA/2 eba_2 Bundesbank Statistics CG 4 http://www.bundesbank.de/stat/xbrl/role/dict/dom/CG/4 de_stat_4 Bundesbank Supervision AP 2 http://www.bundesbank.de/sprv/xbrl/role/dict/dom/AP/2 de_sprv_2 The schema file that represents hierarchies (defining role types and referring linkbases) is placed in the same folder as members and it is named hier.xsd. Examples of such schema files, their namespaces and prefixes are presented in Table 13. Table 13. Examples of schema files defining hierarchies for domain members Owner Domain code Hierarchies schema Namespace Prefix Cross-sector GA http://www.eurofiling.info/xbrl/dict/dom/ga/hier.xsd http://www.eurofiling.info/xbrl/dict/dom/GA/hier eu_GA_h EBA CO http://www.eba.europa.eu/xbrl/dict/dom/co/hier.xsd http://www.eba.europa.eu/xbrl/dict/dom/CO/hier eba_CO_h EBA MI http://www.eba.europa.eu/xbrl/dict/dom/mi/hier.xsd http://www.eba.europa.eu/xbrl/dict/dom/MI/hier eba_MI_h Bundesbank Statistics CG http://www.bundesbank.info/stat/xbrl/dict/dom/cg/hier.xsd http://www.bundesbank.info/stat/xbrl/dict/dom/CG/hier de_stat_CG_h Bundesbank Supervision AP http://www.bundesbank.info/sprv/xbrl/dict/dom/ap/hier.xsd http://www.bundesbank.info/sprv/xbrl/dict/dom/AP/hier de_sprv_AP_h Each hierarchy of domain members (represented by an extended link role as explained above) must indicate at least one dimension related to a hierarchy. Identification of this dimension is made: − in the standard role of generic label (of a hierarchy) by indication of a dimension label (optional), − in the documentation role of generic label (of a hierarchy) by indication a QName (qualified name) of a dimension item declaration (obligatory). Example of hierarchy reference to a dimension QName with documentation label role is presented below (there is a similar construct in English label linkbase): <link:loc xlink:type="locator" xlink:href="hier.xsd#de_sprv_1" xlink:label="loc_de_sprv_1" /> <label:label xlink:type="resource" xlink:label="label_de_sprv_1_1" xml:lang="de" xlink:role="http://www.xbrl.org/2008/role/documentation">de_sprv_dim:CS</label:label> <gen:arc xlink:type="arc" xlink:arcrole="http://xbrl.org/arcrole/2008/element-label" xlink:from="loc_de_sprv_1" xlink:to="label_de_sprv_1_1" /> This relation between hierarchies and dimensions is “many-to-many”, which means that a number of dimensions can be attached to one hierarchy and more than one hierarchy can be referred by the same dimension. In addition to labels, these schemas refer to three additional linkbases with information about hierarchies: - a presentation linkbase (hier-pre.xml), which represents the hierarchical disposition of members in hierarchies using parent-child relationships, - a definition linkbase (hier-def.xml), which enables the inclusion of the members of a hierarchy in dimensional combinations using domain-member relationships, - a calculation linkbase (hier-cal.xml), which establishes some basic arithmetical relationships between a member of the hierarchy and its children: o a member is equal to the addition of its child members in the hierarchy: complete-breakdown relationships, o a member is greater or equal than the addition of its child members in the hierarchy: partial-breakdown relationships, o a member is less or equal than the addition of its child members in the hierarchy: superset-breakdown relationships. These calculation arcs include a weight attribute to indicate whether the child member contributes to the aggregation positively (+1) or negatively (-1). These roles that represent these calculation relationships are defined in the model.xsd schema that supports the model and are presented in Table 14. Table 14. Arcroles defined in the model.xsd schema, reflecting different forms of aggregations of members. Arc role id Arc role URI complete-breakdown http://www.eurofiling.info/xbrl/arcrole/complete-breakdown partial-breakdown http://www.eurofiling.info/xbrl/arcrole/partial-breakdown superset-breakdown http://www.eurofiling.info/xbrl/arcrole/superset-breakdown The root member of the definition and presentation relationship networks is the domain item defined in the schema exp.xsd associated with the owner. Domain members that extend the domain of another owner are placed in a folder preceded by the prefix of the extended owner. Example of extension of the cross-sector domain by with EBA specific concepts are presented in Table 15. Table 15. Examples of the extension of the cross-sector domain by with EBA specific concepts Code Extending domain members schema Namespace Prefix GA http://www.eba.europa.eu/eu/xbrl/dict/dom/eu_ga/mem.xsd http://www.eba.europa.eu/xbrl/dict/dom/GA eba_eu_GA CU http://www.eba.europa.eu/eu/xbrl/dict/dom/eu_cu/mem.xsd http://www.eba.europa.eu/xbrl/dict/dom/CU eba_eu_CU 6.4.4.3.2 Typed domains Members of typed domains are neither listed as XBRL items with labels nor arranged in hierarchies. The content of typed domains is restricted by XML data type constraints, as these domains (according to the XBRL Dimension specification) are XML elements. In most of the cases, a typed domain would be represented by an XML element with a simple data type (e.g. xs:string or xs:decimal). Further restrictions on the expected value are introduced by means of the Formula specification where value assertions define detailed constraints on the allowed values of a typed domain in association with a certain dimension. For example, the typed domain Code, being a string data type, may follow a certain pattern defined by a value assertion when referred from the Related entity code dimension and another pattern when used by the Instrument code dimension. 6.4.4.4 Dimension items Dimension items’ representation in XBRL is defined in the XBRL Dimensions 1.0 specification. The local name of each dimension corresponds to its code in the model: a short sequence of capital case letters (usually two, but may be more). Value of the id attribute of the element representing a dimension item (necessary for XLink locators) is composed according to the following pattern : {opre}_{name} where {opre} represents the prefix of the base namespace of the owner of the dimension and {name} represents the name described above. A few examples of dimension items are presented in Table 16. Table 16. Examples of dimensions items Owner Code Name Id Namespace Prefix Cross-sector IC IC eu_IC http://www.eurofiling.info/xbrl/dict/dim eu_dim EBA PL PL eba_PL http://www.eba.europa.eu/xbrl/dict/dim eba_dim EBA MC MC eba_MC http://www.eba.europa.eu/xbrl/dict/dim eba_dim Bundesbank Statistics RM RM es_RM http://www.bundesbank.de/stat/xbrl/dict/dim de_stat_dim Bundesbank Supervision ICT ICT es_ICT http://www.bundesbank.de/sprv/xbrl/dict/dim de_sprv_dim Names of schema files defining dimension items is dim.xsd and they include references to label linkbase files and a definition linkbase whose file name is dim-def.xml and are placed in the same folder as the schema file. This definition linkbase includes the following information about explicit dimensions:  reference to the domain associated to the dimension by means of a dimension-domain relationship (with xbrldt:usable attribute equal to false) pointing to a domain item defined in respective exp.xsd or typ.xsd schema file of any referenced or defined owner,  reference to the default member of that dimension by means of a dimension-default relationship (note that although the model defines default members at the domain level, the XBRL Dimensions specification establishes this relationship at dimension level; thus, each dimension using a domain with a default member must include this relationship). These relationships associating dimension with a domain and its default members are defined in an extended whose role is the standard one (i.e. http://www.xbrl.org/2003/role/link). 6.4.4.5 Families Families are placed in the same folder as dimensions. Families are represented as XBRL abstract items of data type model:familyType. The local name of each family corresponds to its numeric code in the model preceded by a lower case letter f. Value of the id attribute of family elements is composed as follows: {opre}_{name} where {opre} represents the prefix of the base namespace of the owner of the family and {name} represents the local name described above. Some examples are presented in Table 17. Table 17. Examples of families Owner Code Name Id Namespace Prefix EBA 1 f1 eba_f1 http://www.eba.europa.eu/xbrl/dict/fam eba_fam EBA 2 f2 eba_f2 http://www.eba.europa.eu/xbrl/dict/fam eba_fam Bundesbank Statistics 1 f1 de_stat_f1 http://www.bundesbank.de/stat/xbrl/dict/fam de_stat_fam Bundesbank Supervision 5 f5 de_sprv_f5 http://www.bundesbank.de/sprv/xbrl/dict/fam de_sprv_fam 6.4.4.6 Perspectives Perspectives are placed in the same folder as dimensions and families. Perspectives are represented as extended link roles that are used in presentation linkbases, where the relationships between dimensions and families are formalized. The URI of these roles is built according to the following pattern: {ons}/role/dict/pers/{code} where {ons} corresponds to the owner namespace and {code} represents the numeric code given to the perspective in the model. Value of the id attribute of the role type is composed according to the following patter: {opre}_p{code} where {opre} corresponds to the owner prefix and {code} represents the numeric code of the perspective in the model. Examples of perspectives are presented in Table 18. Table 18. Examples of perspectives Owner Code Role Id EBA 1 http://www.eba.europa.eu/xbrl/role/dict/pers/1 eba_p1 EBA 2 http:// www.eba.europa.eu/xbrl/role/dict/pers/2 eba_p2 Bundesbank Statistics 1 http://www.budnesbank.de/stat/xbrl/role/dict/pers/1 de_stat_p1 Bundesbank Supervision 5 http://www.bundesbank.de/sprv/xbrl/role/dict/pers/5 de_sprv_p5 The schema file defining perspectives (pers.xsd) imports the schemas of families and dimensions, and refers to a generic linkbase containing generic labels of perspectives and a presentation linkbase (pers-pre.xml) including extended links that correspond to each perspective. The arcs in these extended links have families as source (root) nodes and dimensions as target nodes. 6.4.5 Reporting requirements layer Frameworks, taxonomies, tables, modules and other concepts constitute the layer of the model where actual reporting requirements are specified with the support of the financial concepts defined in the dictionary. All the files that correspond to this layer are placed under the folder fws in the official location of its owner. Its namespace is obtained by adding the suffix fws to the base namespace of the owner plus some additional suffixes that depend on the type of the concept represented. In case of the Bundesbank taxonomies frameworks (similarly to the dictionary layer) are defined separately for the statistical and supervisory datasets. 6.4.5.1 Frameworks Frameworks are public elements represented using XBRL abstract items of the framework type (model:frameworkType) in the schema file fws.xsd. General framework properties are presented in Table 19. Table 19. Framework properties Schema property Value Official location {oloc}/fws/fws.xsd Target namespace {ons}/fws Target namespace prefix {opre}_fws Element local name {framework} Element id {opre}_{framework} The local name of each framework element corresponds to its code in the model and its id follows the general pattern. Examples of frameworks defined by the EBA or Bundesbank taxonomies for statistical and supervisory data are presented in Table 20. Table 20. Examples of frameworks Owner Schema property Value EBA Official location http://www.eba.europa.eu/eu/fr/xbrl/fws/fws.xsd Target namespace http://www.eba.europa.eu/xbrl/fws Target namespace prefix eba_fws Local name example finrep, corep Element id example eba_finrep, eba_corep Element label (English) FINnancial REPorting, COmmon REPorting Bundesbank Statistics Official location http://www.bundesbank.de/de/stat/xbrl/fws/fws.xsd Target namespace http://www.bundesbank.de/stat/xbrl/fws Target namespace prefix de_stat_fws Local name example mbs Element id example de_stat_mbs Element label (English) Monthly Balance Sheet Statistics Element label (German) Monatliche Bilanzstatistik Bundesbank Supervision Official location http://www.bundesbank.de/de/sprv/xbrl/fws/fws.xsd Target namespace http://www.bundesbank.de/sprv/xbrl/fws Target namespace prefix de_sprv_fws Local name examples fmr, misc Element id examples de_sprv_fmr, de_sprv_misc Element label (English) Financial Reporting and Monthly Return Reports, Miscellaneous Reports Element label (German) Jahresabschluss, Basis und Monatsausweisverordnung, Verschiedene Each framework has a folder where the files of its taxonomies are placed. This folder has the name of its code in the model as presented on examples in Table 21. Table 21. Examples of framework folders Description Framework folder EBA FINREP http://www.eba.europa.eu/eu/fr/xbrl/fws/finrep/ Bundesbank Statistics, Monthly Balance Sheet Information http://www.bundesbank.de/de/stat/xbrl/fws/mbs/ Bundesbank Supervision, Financial Reporting and Monthly Return Reports http://www.bundesbank.de/de/sprv/xbrl/fws/fmr/ Bundesbank Supervision, Miscellaneous Reports http://www.bundesbank.de/de/sprv/xbrl/fws/misc/ 6.4.5.2 Taxonomies Taxonomies are public elements represented using XBRL abstract items of the taxonomy type (model:taxonomyType). These elements are stored in the schema file tax.xsd under the folder of its framework, a subfolder that corresponds to its normative code or legislation publication date and another subfolder with the date of taxonomy version. Thus, the file tax.xsd includes a single element. Its local name corresponds to its code in the model and value of its id attribute is constructed according to the general pattern ({opre}_{taxonomy code}). General taxonomy properties are presented in Table 22. Table 22. Taxonomy properties Schema property Value Official location {oloc}/fws/{framework}/{normative code or legislation publication date with “pub_” prefix}/{taxonomy publication date}/tax.xsd Target namespace {ons}/fws/{framework}/{normative code or legislation publication date with “pub_” prefix}/{{taxonomy publication date} Target namespace prefix {opre}_tax Element local name {taxonomy} Element id {opre}_{taxonomy} To facilitate the specification of additional taxonomy resources in this document, hereinafter in applies:  {taxonomy-loc} to the URL {oloc}/fws/{framework}/{normative code or legislation publication date with “pub_” prefix}/{taxonomy publication date},  {taxonomy-ns} to the URI {ons}/fws/{framework}/{normative code or legislation publication date with “pub_” prefix}/{taxonomy publication date}. Examples of taxonomy folders are presented in Table 23. Table 23. Examples of taxonomy folders Description Framework folder EBA FINREP, CRR legislation, taxonomy published on December 31, 2012 http://www.eba.europa.eu/eu/fr/xbrl/fws/finrep/crr/2012-12-31 Bundesbank Statistics, Monthly Balance Sheet Information, legislation published in July 2012, taxonomy published on October 31, 2012 http://www.bundesbank.de/de/stat/xbrl/fws/mbs/pub_2012-07/2012-10-31 Bundesbank Supervision, Financial Reporting and Monthly Return Reports, legislation published in January 2013, taxonomy published January 31, 2013 http://www.bundesbank.de/de/sprv/xbrl/fws/fmr/pub_2013-01-01/2013-01-31 Bundesbank Supervision, Miscellaneous Reports, legislation published in January 2013, taxonomy published January 31, 2013 http://www.bundesbank.de/de/sprv/xbrl/fws/misc/pub_2013-01-01/2013-01-31 The folder of taxonomy includes three subfolders for:  tables (tab),  modules (mod) and  validations (val). Content of these subfolders is explained in the next sections of this document. 6.4.5.3 Tables The table folder includes a schema file (tab.xsd) that references a generic linkbase with the hierarchy of table groups and tables (tab-pre.xml) and a label linkbase for table groups (tab-lab-en.xml). The schema includes the definitions of table groups (if any), which are represented using XBRL abstract items of the table group type (model:tableGroupType). Name of a table group item is composed by adding the prefix tg to the code of a table group in the model or any other custom name. General properties of a table group are presented in Table 24. Table 24. Table group properties Schema property Value Official location {taxonomy-loc}/tab/tab.xsd Target namespace {taxonomy-ns}/tab Target namespace prefix {opre}_tab Element local name tg{table-group-code} or other custom name Element id {opre}_{local-name} Table groups are used to link numerous tables defined by one template or resulting from normalization of templates or if an original templates is composed by two or more physical tables. The files that define the content of each table are placed in a folder whose name corresponds to the code of the template in the model ({table code}). General properties of a table are presented in Table 25. Table 25. General properties of a table. Schema property Value Official location {taxonomy-loc}/tab/{table code}/{table code}.xsd Target namespace {taxonomy-ns}/tab/{table code} Target namespace prefix {opre}_tab_{table code} Element local name N/A (elements defined as resources in linkbases) Element id {opre}_{table code} (element defined as a resource in the table linkbase) {table code} apart from the code of a template defined in the model may include information about rendering of multiple tables resulting from split due to normalization of a larger original template. In such case, the position of each table in a larger template is identified by specifying its relation to other tables using the following notation: {xNyM} where x indicates placement of a table in the horizontal disposition, N is an integer number defining the order of tables in horizontal disposition, y represents placement of a table in the vertical disposition and M is an integer number indicating the order of tables in vertical disposition. For example, template C3 included in information requirements reflected by the Monthly Balance Sheet Statistics taxonomy has been split in six tables, whose codes are: c3_x1y1, c3_x2y1, c3_x1y2, c3_x2y2, c3_x1y3, c3_x2y3. Therefore, tables that constitute this template shall be rendered in the following order and organization: c3_x1y1 c3_x2y1 c3_x1y2 c3_x2y2 c3_x1y3 c3_x2y3 There is a group-table relationship established in the presentation linkbase linking a group item (in this example “c3”) with resources representing each table split due to normalization (e.g. c3_x1y1, c3_x2y1, c3_x1y2, c3_x2y2, c3_x1y3, c3_x2y3). In case of templates with potential multiple occurrence, that are built from two tables, one representing header information and the other with data depending on the header information, {table code} apart from the code of a template as defined in the model includes also a suffix: _masterdata for header information and _data for the part of a template that contains the numbers. Examples of such templates are O2, P1 and S1 included in information requirements reflected by the Monthly Balance Sheet Statistics taxonomy. Similarly, templates that are originally constructed from more than one physical table include “Part N” component in their name, where N corresponds to an integer. Examples of such templates are form H from the Monthly Balance Sheet Statistics information requirements or form HA classified as Miscellaneous in Supervision. Schema file for a table in refers to a table linkbase ({table}-rend.xml), a definition linkbase ({table}-def.xml) and a label linkbase ({table}-{lang}-lab.xml). The table linkbase includes the definition of the table according to the Table Linkbase specification. The relationships of each table are placed in an extended link whose role is built according to the following pattern: {ons}/role/fws/{framework}/{normative code or legislation publication date with “pub_” prefix}/{taxonomy publication date}/tab/{table code} In this linkbase, the different components of tables are represented using resources. Value of the id attribute of these resources is based on the code or sequential number plus a prefix to obtain a unique code in the context of the linkbase file (as presented on Table 26). Table 26. Table linkbase resources and their ids. Model class Table linkbase resource Id Table table {opre}_t{code} Predefined axis ruleAxis (abstract = true) {opre}_a{code} Variable axis filterAxis {opre}_a{code} Coordinate ruleAxis {opre}_c{code} Base items hierarchy reference conceptRelationshipAxis {opre}_h{code} Dimension hierarchy reference dimensionRelationshipAxis {opre}_h{code} According to the Table Linkbase specification, aspect rules are used to specify the concepts represented in predefined axes. In the case of duration type metrics, the size of the period to be reported is constrained using time aspect rules in the context of a table. The default value is a reference period ; other possible values are month, quarter, year, etc. In case of data points that correspond to an instant or period of time prior to the reference period, temporal aspect rules include a temporal offset relative to the reference date. The reference date and the reference period shall be defined in terms of two parameters defined in a linkbase file (http://www.eurofiling.info/eu/fr/xbrl/func/params.xml): - refPeriodEndDate: reference date and end date of the reference period, - refPeriodStartDate: starting date of the reference period. Examples of use of time references are presented in Table 27. Table 27. Examples of time references Time reference Aspect rule Reference date instant = refPeriodEndDate Reference period duration.end = refPeriodEndDate duration.start = refPeriodStartDate Beginning of the reference period instant = refPeriodStartDate A quarter ending at the reference date duration.end = refPeriodEndDate duration.start = refPeriodEndDate - P3M + P1D Previous quarter duration.end = refPeriodEndDate - P3M duration.start = refPeriodEndDate - P6M + P1D Instead of this mechanism, another method can be used to identify information referring to different time periods which is including this information in the semantics of business properties defined in the dictionary part of the model and taxonomy and subsequently applying them as aspect values on rendering resources representing headers of rows or columns in a table (ordinates/nodes on rendering axes). An example is “Carrying amount” and “Carrying amount [beginning balance]” as two separate primary items . The definition linkbase includes dimensional relationships valid in the context of the table. Valid combinations are defined using only positive (all) closed hypercubes obtained from the set of valid cells of the table following certain algorithm in order to optimize their number . Each extended link role contains one or more primary items and a single hypercube . In case of multiple primary items, the first one will be used to group the rest and reduce the number of all arcs. The domain element will be used as the target of dimension-domain arcs to avoid cycles. The @xbrldt:targetRole attribute might be necessary in the case of hypercubes with dimensions sharing the same domain. The roles of the extended links necessary to express these combinations are built adding numeric suffixes to the role previously defined for the table. For example:  {ons}/role/fws/{framework}/{normative code or legislation publication date with “pub_” prefix}/{taxonomy publication date}/tab/{table code}/1  {ons}/role/fws/{framework}/{normative code or legislation publication date with “pub_” prefix}/{taxonomy publication date}/tab/{table code}/2 Label linkbase file for a table contains labels for Table Linkbase nodes. table:table node, apart from the standard label, contains also a documentation label. This label is constructed according to the following pattern: {template code}_{table part}_{table split arrangement} where: − {template code} is obligatory and identifies a table association to an original template by referring to its code in capital letters, e.g. THV1, EJB, etc.; this code should be used on filing indicators (see 6.4.3 Filing indicators) − {table part} is used when original template is constructed with two or more physical tables; it may take values “m” or “d” for masterdata and date respectively, or “pN” where N is integer assigned to each part of table, − {table split arrangement} in the following format “xNyM” as explained above for the tables split due to normalization. Rendering nodes apart from the standard label reflecting text in the header of row/column may also contain verbose, documentation and code label. Verbose label contains a footnote associated with a header (i.e. text included under the table in an original template as for example in tables ELRV, KLRV, KZKR, etc). Documentation label includes reference to a legal regulation/standard or additional information from a template that may be associated with a row or columns (e.g. templates LV1 and LV2 contain a column with percentages that are applicable for each row). Technical construct behind the code label is explained in 6.3 Public elements. These are coded of rows or columns as defined in the original templates. 6.4.5.4 Modules Modules are represented using XBRL abstract items of the module type (model:moduleType). Each module is stored in a different schema file whose name is the same as the code of the module in the model plus the extension .xsd. These schema files import the schemas of all the tables required by that module and additionally header taxonomy and filing indicators. General properties of a module are presented in Table 28. Table 28. Properties of modules Schema property Value Official location {taxonomy-loc}/mod/{module}.xsd Target namespace {taxonomy-bns}/mod/{module} Target namespace prefix {opre}_mod_{module} Element local name mod_{module} Element id {opre}_mod_{module} In addition to label linkbases, each module includes a presentation linkbase ({module}-pre.xml) where the relationships between modules and tables or table groups are expressed using group-table arcs (defined in the model.xsd schema file) whose source is the module element and whose target is a table or a table group element. 6.4.5.5 Validations Validations are expressed using XBRL assertions. Assertions are grouped into assertion sets that correspond to the tables they are to be applied on. The link between an assertion set and the table (or tables ) it applies is represented using arcs from the assertion set to the resource that corresponds to the table. The arcrole URI of this arc is http://www.eurofiling.info/xbrl/arcrole/applies-to-table and it is defined in model.xsd. If an assertion applies to multiple tables individually or to multiple sets of tables, then it is associated to different assertion sets (see examples provided in Table 29). Table 29. Examples of assertions, assertion sets and tables they apply to Example Assertion example (textual description) Assertion sets Tables 1 $a > 0 (where $a represents data in table 1) assertion set 1 table1 2 $a > 0 (where $a represents data in tables 1, 2 and 3) assertion set 1 table1 assertion set 2 table 2 assertion set 3 table 3 3 $a = $b (where $a represents data in table 1 whereas $b represents data in table 2) assertion set 1 table 1 table 2 4 $a = $b (where in some cases, $a represents data in table 1 and $b data in table 2; in other cases, $a represents data in table 3 and $b represents data in table 4) assertion set 1 table 1 table 2 assertion set 2 table 3 table 4 As public elements, assertion set resources may include model:fromDate and model:toDate attributes to constraint the reference date where their associate assertions should be applied. Assertions are identified by a unique code, so that it enables the identification of errors in a validation process with the corresponding definition . Assertions might include a description and custom error messages, as defined by business experts. Existence assertions shall only be used to detect errors in the case of mandatory data that must be reported. Whenever possible, value assertion shall be used instead of existence assertion, as the former enable more comprehensive error messages. The files that define assertions and assertion sets are grouped into files depending on their scope. These files are placed in the val folder of the corresponding taxonomy, together with files to define preconditions and filters of common use shared by different assertions in the taxonomy and parameters. Examples of location and names of linkbase files containing value assertions and shared parameters, filters and preconditions are presented in Table 30. Table 30. Examples of location and names of linkbase files containing value assertions and shared parameters, filters and preconditions Resource description File location Assertions and assertion sets location that apply to a single table (example 1) {taxonomy-loc}/val/val-{tab1}.xml Assertions and assertion sets location that apply to multiple tables individually (example 2) {taxonomy-loc}/val/val-{tab1}.{tab2}.xml Assertions and assertions sets location that cross information in a set of tables (example 3) {taxonomy-loc}/val/val-{tab1}_{tab2}.xml Assertions and assertions sets location that cross information in a multiple sets of tables (example 4) {taxonomy-loc}/val/val-{tab1}_{tab2}.{tab3}_{tab4}.xml Parameters {taxonomy-loc}/val/params.xml Filters common to multiple assertions in the taxonomy {taxonomy-loc}/val/filt.xml Preconditions common to multiple assertions in the taxonomy {taxonomy-loc}/val/prec.xml Any of these linkbases can have its corresponding set of label linkbases, following the convention defined in this document. In the case of assertions, an additional set of linkbases might be included for error messages. Name of this file is created according to the following pattern: {assertions-file}-err-{lang}.xml where {assertions-file} corresponds to the name of the file with the assertions whose error message are described, without the extension. These files will be included by the modules defined in the taxonomy. In order to handle the error margin caused by the imprecision of input data, assertions can make use of a set of functions implemented according to the Custom Functions Implementation specification. These functions use the same name as the ones defined in the XPath 2.0 Functions specifications, but are defined in the namespace http://www.eurofiling.info/xbrl/func/interval-arithmetics and placed in the following official location: -http://www.eurofiling.info/eu/fr/xbrl/func/interval-arithmetics.xml. An entry point for these and any additional functions that could be provided in the future is the following schema file: http://www.eurofiling.info/eu/fr/xbrl/func/functions.xsd. NOTE: The above explanation of implementation of assertions may be modified following the best/common practice established by the EBA taxonomies and their architecture as well as specific needs that may result from first developments of the Formula specification business rules for the Deutsche Bundesbank. Annex A: Data Point Modelling Development process Ideally, a DPM is developed as the first artefact in the process of definition of information requirements. It shall represent the analytical needs of business experts required for fulfilment of supervisory tasks and policy making, by identifying in the form of breakdowns different domains of interest. Subsequently the legislation is prepared together with supporting guidelines, for example tabular views representing the current reporting requirements, selected as a subset of all potentially logical combinations of the predefined breakdowns. The other approach is to first define the tabular views (including the detailed guidelines) and subsequently analyse them in order to list all business properties and arrange them in breakdowns. This method is more common as it represents an evolutionary step in information requirements setting. It is possible that in the process of DPM definition based on existing tabular views, some of the templates may require adjusting (normalization) of their layout. This is the consequence of the application of a consistent model on a rather flexible format which is tabular views. General building blocks and terminology Data Point Model defines business properties that are used to describe each and every piece of the information requirements (hereinafter referred to as a data point and data points respectively). These properties are gathered in sets based on their common and cohesive nature. Distinguishing these properties and their coherence is based on a subjective view of the author. However, this does not mean there are no rules guiding this process. The model shall at least fulfil the basic business requirements such as accuracy, completeness, uniqueness and unambiguity which assume application of certain patterns in the property definition process as well as when performing quality assurance tests. In any case, there are certain properties that must characterise each piece of the information requirements (each data point). These are: − type of the expected value of a fact (e.g. text, monetary value, a number with or without decimals, date, etc.), − duration in time of a defined business concept, distinguishing between a stock - stated at a point in time (such as any asset or liability) - and a flow, reported for a period of time (e.g. revenues, cash flows, etc.). The type of the expected value is the minimum requirement for the description of each data point and is referred to as a metric. A metric can also include the stock/flow aspect and other semantics (business properties) depending on the decision of the model’s author. Each data point in the model must define one and only one metric. Other business properties describing or detailing the data point and which are not included in the definition of a metric are defined in the form of pairs of dimension members. Members are gathered in sets called domains, can be arranged in hierarchical relationships (subdomains) and are contextualized by dimensions. Certain rules and examples presented in the next paragraphs have been added to facilitate the comprehension of these terms. A domain is a cohesive set of members i.e. all members from a domain share a certain common nature defined subjectively but applied consistently by the model’s author. A typical example of a domain is “Geographical areas”. Members of this domain could be different areas of the Earth, classified according to the physical geography (“Europe”, “Pacific Ocean”, “Himalayas”, …) and/or human geography (“France”, “EU”, “G-20 major economies”, …). Combining physical and human geography into one domain is already a subjective view of the author of the classification. Members of a domain can be defined by explicit enumeration of each member or by imposing a constraint on the expected value for each enumeration. A domain of the first kind is called explicit domain, and an example could be the “Geographical areas” presented above. The latter is called a typed domain (the name comes from the data type restriction on its content). An example of a typed domain could be the ISBN identifier (used for uniquely identifying books and similar publications) which is restricted to a certain number of digits. Members of an explicit domain should participate in relationships, typically forming hierarchical tree-structures. Not every hierarchy must include all members of a domain (especially when there could be alternative classifications, e.g. “Poland”/”Other than Poland” and “EU”/”Other than EU” would never form a single hierarchy as “EU” includes “Poland” plus some other countries while “Other than EU” includes “Other than Poland” minus some countries). Therefore hierarchies are called subdomains (even though in some cases they can define relationships including all members of a domain). In case of business data, these relationships would typically reflect basic arithmetic operations where lower level elements aggregate to an upper level element with a certain weight. Comparison operators used to express the relationship between the upper level element and contributing lower level elements could be one of the following “=”, “≥” or “≤”, and the multiplication factors (weights) are typically “+1” or “-1”. In other cases when there are no arithmetic relations, hierarchies are also created to define subgroups of members for other purposes (e.g. hierarchies shared by a large subset of information requirements). Whatever the kind of relationship, hierarchies are an important part of the model as they help in maintaining internal coherence of a domain. Each domain must be associated with one or more dimensions. Theoretically, one dimension could refer to members of multiple domains. However, this is prohibited in the DPM. Dimensions contextualize domain members when applied to a data point (they add up to the semantics of a member which, without a dimension, may be insufficient to represent the full meaning of a property). For instance, in the example above, “Spain” is a geographical area which could represent “Location of an issuer” of a financial instrument, “Location of a stock exchange” where this instrument is traded, “Location of a broker” who participated as a middleman in the transaction or finally “Location of a buyer” who purchased this instrument. The same domain member “Spain” was contextualized in this example by four different dimensions. A similar situation may appear in case of a typed domain whose restriction could be different based on the dimension contextualizing its value (e.g. code = 123-345-567-890 could be the “Identification number for tax purposes” or “Company registration number”, where the kind/type of the number is given by the dimension). Moreover, in case of typed domains, the application of a certain dimension may impact the pattern or enumeration for potential values of a typed domain (for example “ISBN-10” and “ISBN-13” refer to the same “ISBN” domain but expected values are restricted to 10 and 13 digits respectively). Dimensions referring to explicit domains may have default members, which are implicitly applied to every data point that is not explicitly characterised by a particular dimension. For example, a dimension “Original currency” may be associated with a default member “All currencies”. This means that when a data point does not explicitly mention the “Original currency” dimension, it is assumed that it takes the “All currencies” member for this dimension. Default members are very useful when defining the model as otherwise every data point would have to explicitly mention each dimension and the applicable member. With default members it is enough for a data point to name only the properties that are important and distinguish this data point from other data points. Although “default” is a property of a member with respect to a dimension, the DPM assumes that all dimensions referring to a certain domain would have the same default member. This means that only one member in a domain can be assigned as a default and shall apply to all dimensions referring to this domain. There could be dimensions in the model that do not apply to some data points. For example, a data point representing “Equity instruments” is not linked to the “Original maturity” dimension at all (shares and other ownership rights simply do not have maturity). Therefore, the default member is usually named “Total/Not-applicable”. Each pair of a dimension and a member (either explicit or typed) is a single business property of a data point. A data point can have none, one or more such business properties. Each dimension must not be associated with a data point more than once.

Annex B: Taxonomy architecture diagram

Annex C: Information requirements and taxonomy scope overview diagram

Retrieved from "http://xbrlwiki.info/index.php?title=European_XBRL_Taxonomy_Architecture_V2.0"

European XBRL Taxonomy Architecture V2.0

From XBRLWiki

Revision as of 08:24, 11 June 2013

Contents

Foreword

Introduction

Objective

Target audience

Relationship to other work

Scope

Normative references

Terms and definitions

European XBRL Taxonomy Architecture

Supporting concepts

Taxonomy levels and owners

Filing indicators

Model supporting schema

Namespaces

Public elements

Dictionary of concepts

Metrics

Taxonomy Architecture Description

Introduction

Important assumptions

Data model

Scope

Components of the information requirements

Scope extension

XBRL specifications compliance

XBRL taxonomy components

Model supporting schema

Other XBRL technical files

Views

Personal tools

Navigation

Search

Toolbox

 | variable || http://xbrl.org/2008/variable
 |}
-<br><br>
-== Taxonomy Architecture Description ==
 == Public elements ==
 The graph above shows how the meta class DimensionedElement of the DPM meta model is mapped to an XBRL concept with its corresponding XBRL attributes according to the EXTA definitions. Dimensioned Elements are known as metrics in the EXTA (synonym in XBRL: Primary item). Dimensioned Elements are part of the Dictionary so they inherit the attributes defined by the abstract concept of a Dictionary element. The abstract Dictionary element is subordinated element of the abstract meta class representing a Public element so the Dimensioned Element inherits also the attributes defined by this superordinated element. In XBRL terms a metric in EXTA must include at least the attribute ''model:creationDate'' of the custom attributes.
+<br><br>
+== Taxonomy Architecture Description ==
+=== Introduction ===
+The purpose of this document is to present and explain the architecture of the XBRL taxonomies defined by the CEN WS XBRL. In particular, it explains the scope (coverage of information requirements), modularization in files, manner of defining concepts and relations and other important design aspects.
+This document is aimed at users of the CEN WS XBRL compliant  taxonomies, in particular editors of the taxonomy or producers of instance documents (by applying mappings to internal systems or assigning XBRL tags with values in any other manner) as well as developers of the IT solutions facilitating reporting in the XBRL format or analysis of XBRL data.
+Comprehension of the Extensible Business Reporting Language (XBRL) 2.1 Specification and other XBRL Specifications such as XBRL Dimensions 1.0, XBRL Formula 1.0, Generic Link 1.0 and Table Linkbase 1.0 (Public Working Draft as of 21 December 2011) is required to comprehend the content of this document.
+===Important assumptions===
+For modelling of data and its formal as well as physical representation in XBRL format, the CEN WS XBRL follows the approached applied for various deliverables of the Eurofiling project  and the draft assumptions for the EBA products. The reason for this decision is assumed future alignment of the Bundesbank data models and taxonomies with the final EBA products (COREP, FINREP, etc).
+Therefore, the Bundesbank applied the Data Point Modelling for description of each exchanged data field .
+In terms of reflection of the model semantics in XBRL syntax, the Bundesbank follows the assumptions and plans for the architecture of the EBA taxonomies .
+In addition to that, the Bundesbank XBRL taxonomies architecture obeys certain rules on defining and modelling of metadata in order to increase their reusability by the consuming applications, in particular the supervisory and analytical systems.
+===Data model===
+Prior to the development of taxonomy, information requirements need to be identified specifying reportable concepts and relations between them. This is done in the form of data models.
+The main input in creation of data models are reporting templates, i.e. tabular representation of information requirements as they exist at the moment as well as supportive laws and regulations.
+These temples, laws and regulations are analysed in order to create a Data Point Model (DPM).
+The main deliverables of the Data Point Modelling methodology consists of two types of MS Excel workbooks:
+	DPM dictionary, defining properties and classifications (breakdowns) that can be used to describe each data point,
+	Annotated Templates, which are the input (original) reporting templates where each row/column is associated with a property or a set of properties defined in the DPM dictionary.
+The Bundesbank taxonomies were created by translation of the DPM into XBRL syntax basing on the rules described in this document.
+===Scope===
+The Bundesbank XBRL taxonomies resemble the content of the DPM dictionary and the Annotated Templates. They reflect information requirements for filings that are submitted by institutions supervised by the Bundesbank according to the German banking and other reporting regulations.
+====Components of the information requirements====
+Components of the information requirements currently include:
+	statistical data:
+−	Monthly Balance Sheet Statistics [MBS ],
+	supervisory data:
+−	Financial Reporting [FR] and Monthly Return [MR] reports jointly referred to as FMR ,
+−	other miscellaneous reports (referred to as MISC) consisting of:
+	Liquidity regulation [LR],
+	Leverage ratio [ER],
+	Interest Risk information [IR],
+	other.
+The division into statistical and supervisory data results from the current process of the DPM development. It is possible, that in the future these two separate at the moment datasets are merged into a single dataset.
+MBS, FMR and MISC are called frameworks. All frameworks apart from the MBS (which is defined in the statistical dataset) use the same definitions declared in the DPM dictionary. Information requirements and taxonomy scope overview diagram is provided in Annex C to this document.
+====Scope extension====
+It is expected that the scope of information requirements covered by DPM and XBRL taxonomy may be extended in the future for other reporting domains, in particular for the German extension of the COREP and FINREP data models and taxonomies developed currently by the European Banking Authority [EBA].
+Architecture of the XBRL taxonomies, as defined in the next sections of this document, already addresses the manner of including these extensions in scope.
+===XBRL specifications compliance===
+Following the XBRL standard requirements, the Bundesbank taxonomies and any assisting reports (XBRL instance documents) are compliant with:
+	XBRL 2.1 specification as of December 31, 2003 with Errata Corrections up to January 25, 2012,
+	Dimensions 1.0 specification as of September 18, 2006 with errata corrections up to January 25, 2012.
+The business rules layer in the form of linkbase files is defined according to the XBRL Formula Specification 1.0 - 2009 – 2011 and supporting specifications (Registry – 2009-2011, Generic Links – June 22, 2009).
+Rendering of tables is created according to the most recent version of the Table Linkbase specification (as of December 21, 2011) published on www.xbrl.org website. It is expected that in the future the taxonomies shall comply with the version of this specification in recommendation status .
+===XBRL taxonomy components===
+====Model supporting schema ====
+The XBRL representation of the model makes use of some schema definitions in the namespace http://www.eurofiling.info/xbrl/ext/model.
+The official location of this schema file will be http://www.eurofiling.info/eu/fr/xbrl/ext/model.xsd however at the moment it is not yet stored in this location. Due to the fact, that taxonomy files reference the official location, applications using the taxonomy require mappings to the local file which is included in the taxonomy package (in folder www.eurofiling.info/eu/fr/xbrl/ext/).
+Throughout this section of the document, the prefix model will be used to make references to this schema namespace.
+====Other XBRL technical files====
+Taxonomy package contains also all files defined by various XBRL specifications and registries. They are placed in folder www.xbrl.org and its subfolder.
+Taxonomy references the official location of these files on www.xbrl.org website. Some of these files however are not yet available in their official location and local mappings may be required. This is for example the case of technical files supporting the Public Working Draft of Table Linkbase specification, which can be found in the taxonomy package in folder www.xbrl.org/2011.
+For clarity of this document, XBRL technical constructs are referenced by their qualified names [QNames] . Prefixes applied in this QNames to abbreviate the namespaces are listed in Table 1.
+Table 1. Prefixes and namespaces of the XBRL technical files referenced in this document
+{| border="1" cellpadding="2" cellspacing="0"
+! Prefix !! Namespace
+|-
+| xs || http://www.w3.org/2001/XMLSchema
+|-
+| xbrli || http://www.xbrl.org/2003/instance
+|-
+| xbrldt || http://xbrl.org/2005/xbrldt
+|-
+| iso4217 || http://www.xbrl.org/2003/iso4217
+|-
+| nonnum || http://www.xbrl.org/dtr/type/non-numeric
+|-
+| link || http://www.xbrl.org/2003/linkbase
+|-
+| label || http://xbrl.org/2008/label
+|}
+.3	Public elements
+Public elements are all concepts of the model that are identified by a code in a certain scope and may include some additional information such as readable labels, definitions and legal references in different languages.
+Public elements include two attributes to reflect their creation date (model:creationDate) and the date when they was last modified (model:modificationDate).
+Language specific information of public elements is represented using the following label resources:
+	XBRL 2.1 labels (link:label) for xbrli:items (or derived) public elements,
+	generic labels (label:label) for public elements represented as XLink resources or other construct (e.g. link:roleTypes).
+The default (standard) role (http://www.xbrl.org/2003/role/link) is used for the extended links containing the label resources.
+The role types used as roles for generic and standard label resources are presented in Table 2.
+Table 2. Role types used as roles for generic and standard label resources
+Property	Generic label role	Standard label role
+Name	http://www.xbrl.org/2008/role/label 	http://www.xbrl.org/2003/role/label
+Definition	http://www.xbrl.org/2008/role/verboseLabel 	http://www.xbrl.org/2003/role/verboseLabel
+Legal references 	http://www.xbrl.org/2008/role/documentation	http://www.xbrl.org/2003/role/documentation
+The labels of the concepts of a schema or a linkbase file are represented jointly in a separate label linkbase file distinguished by language, in the same folder as its corresponding schema or linkbase file. Each language is stored in a separate label linkbase file. The naming convention for these label linkbase files is:
+{main-file}-lab-{lang}.xml
+where {main-file} corresponds to the name of the schema or linkbase file where the concept is defined (without extension) and {lang} component represents the ISO 639-1 code of the language (lowercase). The primary language for all Bundesbank taxonomies is German (ISO 639-1 code “de”) and secondary language is English (ISO 639-1 code “en”).
+In addition to this, some concepts of the dictionary may contain a special linkbase to represent codes needed for different purposes. In particular, the codes given to the columns and rows of tables or codes assigned to the data points are represented using this mechanism. The name of these linkbase files constructed as follows:
+{main-file}-lab-{lang}-codes.xml or {main-file}-lab-codes.xml
+In case of the later, the distinction between codes appearing in different language versions is determined basing on xml:lang attribute on label resources. The labels for these codes are represented as resources with a custom role. The role defined in the model.xsd schema for resources representing codes of rows or columns is http://www.eurofiling.info/xbrl/role/rc-code.
+.4	Logical taxonomy architecture
+This section describes in detail the components and content of the XBRL taxonomy model applied in the taxonomy. The diagram provided in Annex B: Taxonomy architecture diagram may be helpful in reading and understanding this section of the document.
+.4.1	Taxonomy levels and owners
+Taxonomy concepts could be defined on one of the three levels:
+)	cross sector concepts and breakdowns (to be shared between different institutions e.g. banking, insurance and securities supervision),
+)	concepts from the EBA information requirements,
+)	concepts defined by the Bundesbank:
+i)	for statistics purposes,
+ii)	for supervisory purposes.
+Level one are cross sector concepts that shall be eventually defined and agreed by a joint group of experts involved in setting up information requirements for different sectors such as banking, insurance and reporting of other commercial and non-profit companies. It is expected, that these concepts will mainly include the list of countries and currencies as defined by the ISO codes and subsequently extended by for example economy sectors, classes of financial instruments, accounting portfolios, time intervals, etc. This task will be most likely conducted by reconciliation between the dictionaries of business concepts defined by the EBA, EIOPA and other interested parties. Cross sector concepts will be published in the Eurofiling on-line resources as a set of XBRL schema and linkbase files that can be referenced from level two or level three dictionaries.
+Level two are the EBA concepts. They represent the information requirements of COREP, FINREP and other scope defined on the European level. They may refer to and extend level one (cross-sector) concepts.
+Level three are the concepts of national supervisors, in this case represented by the Bundesbank. They reflect information requirements set by the German legislation and specific banking regulations. In case of the Bundesbank taxonomies, this level is divided in information requirements related to statistics and supervisory reporting for the scope and frameworks presented in 4.1 Components of the information requirements section of this document.  The reason for splitting level three is the underlying DPM which is currently defined separately for statistics and supervisory data.
+The idea of levels for concepts definitions has been addressed in the XBRL taxonomy model by introducing the notion of the owner.
+The owner represents an institution that defines concepts of the model. The owner is closely related to the idea of extensibility in XBRL. The main properties of the owner are:
+	owner’s namespace {ons},
+	owner’s prefix {opre}, and
+	official location {oloc}.
+The owner namespace {ons} is a URI used to establish the namespace of the concepts defined by that owner. This URI is generally built by adding xbrl to the internet domain of the institution that the owner represents. In case of the Bundesbank, the domain is extended by stat and sprv components to distinguish between statistical and supervisory datasets.
+The prefix {opre} is used as the basis to establish namespace prefixes in taxonomy files and for some short representations of the concepts by QNames using shorter prefixes (instead of long namespaces) plus the local name .
+Official location {oloc} is a URL used to specify the location where taxonomy files associated to that owner are to be published. Different owners must have different official locations, even owners with the same internet domain/same namespace. The official location is generally built by adding three parts to the internet domain of the institution:
+	representation of the geographical area covered by the institution (e.g. eu in case of the cross sector or the EBA concepts or de for the Bundesbank specific concepts applied in Germany),
+	indication of the scope of information requirement (e.g. fr for general financial reporting, stat for statistical data, sprv for supervisory data, etc)
+	fixed xbrl component identifying the type of standard used to express information requirements.
+Table 3 presents examples of owners and applied namespaces, prefixes and official locations of taxonomy files.
+Table 3. Examples of namespaces, prefixes and official locations of taxonomies files for different owners
+Owner	Namespace	Prefix	Official location
+Cross-sector	http://www.eurofiling.info/xbrl	eu	http://www.eurofiling.info/eu/fr/xbrl
+EBA	http://www.eba.europa.eu/xbrl	eba	http://www.eba.europa.eu/eu/fr/xbrl
+Bundesbank, Statistics	http://www.bundesbank.de/stat/xbrl	de_stat	http://www.bundesbank.de/de/stat/xbrl
+Bundesbank, Supervision	http://www.bundesbank.de/sprv/xbrl	de_sprv	http://www.bundesbank.de/de/sprv/xbrl
+Other properties of the owner are the copyright (text used as a header in every taxonomy file) and the list of supported languages.
+.4.2	Header information
+Header taxonomy is located at the first level in entire taxonomy structure (under http://www.bundesbank.de/de/ext/ folder”), which means it can be applied to different reporting purposes. Applicability to many reporting frameworks imposed departure from some architectural constructs proposed by the EBA, e.g. ownership of elements or division into dictionary layer and reporting layer.
+The purpose of the header taxonomy is to provide basic information about reporting entity, contact data and reporting periods.
+Header taxonomy consists of three files:
+−	bbk-basis.xsd – schema file containing element declarations,
+−	bbk-basis-label.xml – label linkbase file with German and English labels for header taxonomy concepts,
+−	data-types.xsd – schema file with definition of specific (custom) data types used in bbk-basis.xsd to impose constraints on possible to reported
+Header taxonomy is later imported by the modules in the framework section.
+The currently applied solution for inclusion of header taxonomy items may be replaced in the future by a different approach, e.g. recommended by the CEN/WS XBRL .
+.4.3	Filing indicators
+Filing indicators serve the purpose of communicating the scope of the reported data based on templates.
+The main purposes of filing indicators are:
+	provide hints to applications using the taxonomy, on which templates/forms are included in the filing and for example shall be displayed to users,
+	trigger execution of business rules (value assertions) to be run on a filing to check its correctness depending on the reported scope of data.
+In technical terms, filing indicators are facts included as part of an instance document where the filer estates which templates/forms are being reported. Each template/form is represented as an instance fact of the item “table” under the “fIndicators” tuple element. These elements are defined in the namespace http://www.eurofiling.info/xbrl/ext/filing-indicators. The official location of this schema file is http://www.eurofiling.info/eu/fr/xbrl/ext/filing-indicators.xsd. This schema file is imported in every taxonomy module (see 6.4.5.4 Modules)
+Throughout this document, the prefix find will be used to make reference to this schema namespace.
+The following instance excerpt represents a filing with information about templates/forms with codes EJB and EGV:
+<find:fIndicators>
+	<find:table contextRef=”ctx”>EJB</find:table>
+	<find:table contextRef=”ctx”>EGV</find:table>
+</find:fIndicators>
+Context to which facts representing find:table element refer must identify the reporting entity and use the instant date which is the end date of the reporting period.
+Table codes to be used on find:table facts are the ones identified by {template code} component of the documentation label of tabel:table resource (see 6.4.5.3 Tables). If a template results in multiple tables (as a result of its original arrangement in multiple physical tables or due to normalization process) it is identified by find:table fact only once.
+.4.4	Dictionary layer
+.4.4.1	Core concepts
+The core concepts of the dictionary are metrics, dimensions, domains and domain members. Secondary concepts are families and perspectives (auxiliary concepts meant to group dimensions for presentation purposes). All the concepts in the dictionary are public elements.
+To cope with changes in the reporting, in addition to the properties and language specific information of public elements, dictionary elements include two optional attributes that establish its currency period: the starting date of the period interval (model:fromDate attribute) and its end date (model:toDate attribute). If the model:fromDate attribute is not included, then the concept is assumed to be valid for any period prior to the model:toDate attribute. If the model:toDate attribute is not included, then the concept is assumed to be valid for any period after the model:fromDate attribute. If neither model:fromDate nor model:toDate attributes are included, then the concept is assumed to be current for any period of time. The first versions of the dictionary will not include these attributes. As new versions are released and some concepts become obsolete and replaced by others, these attributes will be updated. These attributes don’t have any impact on the reporting process itself; they are meant to simplify the management of the concepts of the dictionary.
+All files in the dictionary of concepts are placed under the folder dict in the official location of its owner (see Table 3). Its namespace is obtained by adding a suffix that depends on the type of element to the namespace of the owner. The prefix to represent that namespace is obtained by adding a predefined suffix to the prefix of its owner (as presented in Table 4) where {oloc} represents the official location of taxonomy files of the owner of the concepts, {ons} its base namespace, {opre} the prefix of its base namespace, and {dc}/{DC} the code of a domain in lower and capital case.
+Table 4. Pattern for location, target namespace and its prefix for dictionary concepts
+Dictionary concept	Official location	Target namespace	Namespace prefix
+Metrics	{oloc}/dict/met/met.xsd	{ons}/dict/met	{opre}_met
+Dimensions	{oloc}/dict/dim/dim.xsd	{ons}/dict/dim	{opre}_dim
+Explicit domains	{oloc}/dict/dom/exp.xsd	{ons}/dict/exp	{opre}_exp
+Typed domains	{oloc}/dict/dom/typ.xsd	{ons}/dict/typ	{opre}_typ
+Explicit domain members	{oloc}/dict/dom/{dc}/mem.xsd	{ons}/dict/dom/{DC}	{opre}_{DC}
+Examples of location, target namespace and its prefix for dictionary concepts of the taxonomy are presented in Table 5.
+Table 5. Examples of location, target namespace and its prefix for dictionary concepts
+Dictionary concept	Prefix	Target namespace	Official location
+Cross-sector metrics	eu_met	http://www.eurofiling.info/xbrl/dict/met	http://www.eurofiling.info/eu/fr/xbrl/dict/met/met.xsd
+Cross-sector dimensions	eu_dim	http://www.eurofiling.info/xbrl/dict/dim	http://www.eurofiling.info/eu/fr/xbrl/dict/dim/dim.xsd
+Cross-sector explicit domains	eu_exp	http://www.eurofiling.info/xbrl/dict/exp	http://www.eurofiling.info/eu/fr/xbrl/dict/dom/exp.xsd
+Cross-sector typed domains	eu_typ	http://www.eurofiling.info/xbrl/dict/typ	http://www.eurofiling.info/eu/fr/xbrl/dict/dom/typ.xsd
+Cross-sector explicit domain members example (domain GA)	eu_GA	http://www.eurofiling.info/xbrl/dict/dom/GA	http://www.eurofiling.info/eu/fr/xbrl/dict/dom/ga/mem.xsd
+EBA metrics	eba_met	http://www.eba.europa.eu/xbrl/dict/met	http://www.eba.europa.eu/eu/fr/xbrl/dict/met/met.xsd
+EBA dimensions	eba_dim	http://www.eba.europa.eu/xbrl/dict/dim	http://www.eba.europa.eu/eu/fr/xbrl/dict/dim/dim.xsd
+EBA explicit domains	eba_exp	http://www.eba.europa.eu/xbrl/dict/exp	http://www.eba.europa.eu/eu/fr/xbrl/dict/dom/exp.xsd
+EBA typed domains	eba_typ	http://www.eba.europa.eu/xbrl/dict/typ	http://www.eba.europa.eu/eu/fr/xbrl/dict/dom/typ.xsd
+EBA explicit domain members example (domain CP)	eba_CP	http://www.eba.europa.eu/xbrl/dict/dom/CP	http://www.eba.europa.eu/eu/fr/xbrl/dict/dom/cp/mem.xsd
+EBA families	eba_fam	http://www.eba.europa.eu/xbrl/dict/fam	http://www.eba.europa.eu/eu/fr/xbrl/dict/dim/fam.xsd
+EBA perspectives	eba_pers	http://www.eba.europa.eu/xbrl/dict/pers	http://www.eba.europa.eu/eu/fr/xbrl/dict/dim/pers.xsd
+Bundesbank statistics metrics	de_stat_met	http://www.bundesbank.de/stat/xbrl/dict/met	http://www.bundesbank.de/de/stat/xbrl/dict/met/met.xsd
+Bundesbank statistics dimensions	de_stat_dim	http://www.bundesbank.de/stat/xbrl/dict/dim	http://www.bundesbank.de/de/stat/xbrl/dict/dim/dim.xsd
+Bundesbank statistics explicit domains	de_stat_exp	http://www.bundesbank.de/stat/xbrl/dict/exp	http://www.bundesbank.de/de/stat/xbrl/dict/dom/exp.xsd
+Bundesbank statistics typed domains	de_stat_typ	http://www.bundesbank.de/stat/xbrl/dict/typ	http://www.bundesbank.de/de/stat/xbrl/dict/dom/typ.xsd
+Bundesbank statistics explicit domain members example (domain SE)	de_stat_SE	http://www.bundesbank.de/stat/xbrl/dict/dom/SE	http://www.bundesbank.de/de/stat/xbrl/dict/dom/se/mem.xsd
+Bundesbank supervision metrics	de_sprv_met	http://www.bundesbank.de/sprv/xbrl/dict/met	http://www.bundesbank.de/de/sprv/xbrl/dict/met/met.xsd
+Bundesbank supervision dimensions	de_sprv_dim	http://www.bundesbank.de/sprv/xbrl/dict/dim	http://www.bundesbank.de/de/sprv/xbrl/dict/dim/dim.xsd
+Bundesbank supervision explicit domains	de_sprv_exp	http://www.bundesbank.de/sprv/xbrl/dict/exp	http://www.bundesbank.de/de/sprv/xbrl/dict/dom/exp.xsd
+Bundesbank supervision typed domains	de_sprv_typ	http://www.bundesbank.de/sprv/xbrl/dict/typ	http://www.bundesbank.de/de/sprv/xbrl/dict/dom/typ.xsd
+Bundesbank supervision explicit domain members example (domain SC)	de_sprv_SC	http://www.bundesbank.de/sprv/xbrl/dict/dom/SC	http://www.bundesbank.de/de/sprv/xbrl/dict/dom/sc/mem.xsd
+Bundesbank supervision explicit domain members example (extension of EBA domain CP)	de_sprv_eba_SC	http://www.bundesbank.de/sprv/xbrl/dict/dom/de_stat_eba_SC	http://www.bundesbank.de/de/sprv/xbrl/dict/dom/eba_cp/mem.xsd
+.4.4.2	Metrics
+Metrics define the nature of the measure to be performed. Metrics determine the data type, the period type (instant / duration) plus additional semantics of their corresponding data points. Metrics are represented in XBRL as primary items and defined in schema files named met.xsd that reference label linkbase files.
+A local name of metrics is composed of three components:
+.	a letter that represents the data type in lower case (for available options see Table 6 below),
+.	a letter that represents the period type: i for instant and d for duration,
+.	a number that corresponds to the numeric code in the model (no zero padding or predetermined length).
+Table 6. Model and XBRL data type, local name codification letter and reporting unit.
+Model data type	XBRL data type	Local name codification letter	Reporting unit
+Monetary (currency)	xbrli:monetaryItemType	m	Adequate currency using ISO 4217 codification (e.g.: iso4217:EUR)
+Percent	num:percentItemType	p	xbrli:pure
+Decimal	xbrli:decimalItemType	p	xbrli:pure
+Integer	xbrli:integerItemType	i	xbrli:pure
+Date	xbrli:dateItemType	d	not applicable
+Boolean	xbrli:booleanItemType	b	not applicable
+Text	xbrli:stringItemType	s	not applicable
+Explicit domain	xbrli:qnameItemType	e	not applicable
+Typed domain	typed domain corresponding data type, e.g. xbrli:stringItemType if a typed domain is xs:string	e	depending on typed domain, usually xbli:pure
+In case of domain based data types, an additional attribute (model:domain) is included to identify the qualified name of the explicit or typed domain (e.g. model:domain="eba:GA").
+The id of the element (necessary for XLink locators) is composed as:
+{opre}_{name}
+where {opre} represents the prefix of the base namespace of the owner of the base item and {name} represents the name described above.
+Table 7 contains a few examples of metrics declared in the taxonomy.
+Table 7. Examples of metrics in the taxonomy.
+Owner	Data / period type	Code	Name	Id	Namespace	Prefix
+Cross-sector	Boolean / duration	3	bd3	es_bd3	http://www.eurofiling.info/xbrl/dict/met	eu_met
+Cross-sector	Monetary / duration	7	md7	es_md7	http://www.eurofiling.info/xbrl/dict/met	eu_met
+EBA	Monetary / instant	7	mi7	eba_mi7	http://www.eba.europa.eu/xbrl/dict/met	eba_met
+EBA	Text / instant	7	si7	eba_si7	http://www.eba.europa.eu/xbrl/dict/met	eba_met
+Bundesbank Statistics	Text / duration	10	sd10	de_stat_sd10	http://www.bundesbank.de/stat/xbrl/dict/met	de_stat_met
+Bundesbank Supervision	Date / duration	5	dd5	de_sprv_dd5	http://www.bundesbank.de/sprv/xbrl/dict/met	de_sprv_met
+Metrics can be arranged in hierarchies. Hierarchies are represented using XBRL extended link roles whose role type URI is built according to the following pattern:
+{ons}/role/dict/mem/{hierarchy-code}
+where {ons} represents the namespace of the owner and {hierarchy-code} the numeric code of the hierarchy. Value of id attribute of these roles is composed following the pattern:
+{opre}_{code}
+Examples of extended link roles used for hierarchies of metrics are presented in Table 12.
+Table 8. Extended link roles used for hierarchies of metrics
+Owner	Hierarchy code	Role URI	Role id
+Cross-sector	1	http://www.eurofiling.info/xbrl/role/dict/met/1	eu_1
+EBA	1	http://www.eba.europa.eu/xbrl/role/dict/met/1	eba_1
+Bundesbank Statistics	4	http://www.bundesbank.de/stat/xbrl/role/dict/met/4	de_stat_4
+Bundesbank Supervision	2	http://www.bundesbank.de/sprv/xbrl/role/dict/met/2	de_sprv_2
+The schema file that represents hierarchies (defining role types and referring linkbases) is placed in the same folder as metrics and it is named hier.xsd. Examples of such schema files, their namespaces and prefixes are presented in Table 13.
+Table 9. Examples of schema files defining hierarchies for domain members
+Owner	Hierarchies schema	Namespace	Prefix
+Cross-sector	http://www.eurofiling.info/xbrl/dict/met/hihi.xsd	http://www.eurofiling.info/xbrl/dict/met/hier	eu_met_h
+EBA	http://www.eba.europa.eu/xbrl/dict/met/hier.xsd	http://www.eba.europa.eu/xbrl/dict/met/hier	eba_met_h
+Bundesbank Statistics	http://www.bundesbank.info/stat/xbrl/dict/met/hier.xsd	http://www.bundesbank.info/stat/xbrl/dict/met/hier	de_stat_met_h
+Bundesbank Supervision	http://www.bundesbank.info/sprv/xbrl/dict/met/hier.xsd	http://www.bundesbank.info/sprv/xbrl/dict/met/hier	de_sprv_met_h
+Each hierarchy can have a label (or labels in multiple languages). Standard label (generic label with standard role) contains description for a hierarchy purpose/content and may include hints on application of the hierarchy in templates.
+In addition to labels, these schemas refer to three additional linkbases with information about hierarchies:
+-	a presentation linkbase (hier-pre.xml),
+-	a definition linkbase (hier-def.xml),
+-	a calculation linkbase (hier-cal.xml).
+Application and purpose of these linkbases identical as in case of hierarchies of domain members (see section 6.4.4.3.1 of this document).
+.4.4.3	Domains
+Explicit domains are represented using XBRL abstract items of domain type model:explicitDomainType in the schema file exp.xsd.
+Typed domains are represented as XML elements that are not in the substitution group of xbrli:item. These elements are defined in the schema file typ.xsd .
+The local name of each domain corresponds to its code in the model: {dom-code}, which is a short sequence of capital case letters (usually two, but may be more).
+Value of the id attribute of the element (necessary for XLink locators) is composed according to the following pattern:
+{opre}_{name}
+where {opre} represents the prefix of the base namespace of the owner of the domain and {name} represents the name described above.
+Some examples of domains items are presented in Table 10.
+Table 10. Examples of domain items
+Owner	Code	Element Name	Type	Id	Namespace	Prefix
+Cross-sector	GA	GA	Explicit	eu_GA	http://www.eurofiling.info/xbrl/dict/exp	eu_exp
+EBA	CO	CO	Explicit	eba_CO	http://www.eba.europa.eu/xbrl/dict/exp	eba_exp
+EBA	MI	MI	Typed	eba_MI	http://www.eba.europa.eu/xbrl/dict/typ	eba_typ
+Bundesbank Statistics	CG	CG	Explicit	de_stat_CG	http://www.bundesbank.de/stat/xbrl/dict/exp	de_stat_exp
+Bundesbank Supervision	ICTX	ICTX	Typed	de_sprv_ICTX	http://www.bundesbank.de/sprv/xbrl/dict/typ	de_sprv_typ
+Although the namespace of explicit and typed domains is different, different local names should be used anyway to avoid confusion. Also the local names of domain items for Bundesbank Statistics and Bundesbank Supervision must be unique (repeating the same code in each dataset must be avoided).
+.4.4.3.1	Explicit domain members and hierarchies
+Explicit domain members are represented using XBRL abstract items of domain item type defined in the non-numeric set of types of the XBRL International type registry: nonnum:domainItemType.
+The local name of each explicit domain member corresponds to its numeric code in the model preceded by a lower case x . If the concept represented already has a widely accepted standard codification, like ISO codes or UN code lists, the local name will match the existing codification in lower case. More specifically, the following ISO codes are used:
+−	ISO 4217: standard currency codes composed of three alphabetical characters,
+−	ISO 3166-1 alpha-2: standard country codes composed of two alphabetical characters.
+Value of the id attribute of explicit domain members follows the general rule:
+{opre}_{name}
+The default domain member of a domain (usually the one with numeric code component of the name set to 0) is marked with an attribute: model:isDefaultMember=”true”.
+A special domain, identified in the model with code BC (Base categories), may define members whose declaration includes an additional xbrli:balance attribute specifying the credit or debit nature of the financial concept (according to the double entry accounting rule).
+The schema file that represents explicit members is placed in a folder with the name of its corresponding domain. The schema file for explicit domain members is called mem.xsd. Examples of schema files defining explicit domain members in the taxonomies are presented in Table 11.
+Table 11. Examples of schema files defining explicit domain members
+Owner	Domain code	Domain members schema	Namespace	Prefix
+Cross-sector	GA	http://www.eurofiling.info/xbrl/dict/dom/ga/mem.xsd	http://www.eurofiling.info/xbrl/dict/dom/GA	eu_GA
+EBA	CO	http://www.eba.europa.eu/xbrl/dict/dom/co/mem.xsd	http://www.eba.europa.eu/xbrl/dict/dom/CO	eba_CO
+EBA	MI	http://www.eba.europa.eu/xbrl/dict/dom/mi/mem.xsd	http://www.eba.europa.eu/xbrl/dict/dom/MI	eba_MI
+Bundesbank Statistics	CG	http://www.bundesbank.info/stat/xbrl/dict/dom/cg/mem.xsd	http://www.bundesbank.info/stat/xbrl/dict/dom/CG	de_stat_CG
+Bundesbank Supervision	AP	http://www.bundesbank.info/sprv/xbrl/dict/dom/ap/mem.xsd	http://www.bundesbank.info/sprv/xbrl/dict/dom/AP	de_sprv_AP
+Hierarchies are represented using XBRL extended link roles whose role type URI is built according to the following pattern:
+{ons}/role/dict/dom/{dom-code}/{hierarchy-code}
+where {ons} represents the namespace of the owner, {dom-code} represents the code of the domain and {hierarchy-code} the numeric code of the hierarchy. Value of id attribute of these roles is composed following the pattern:
+{opre}_{code}
+Examples of extended link roles used for hierarchies of domains are presented in Table 12.
+Table 12. Extended link roles used for hierarchies of domains
+Owner	Domain code	Hierarchy code	Role URI	Role id
+Cross-sector	GA	1	http://www.eurofiling.info/xbrl/role/dict/dom/GA/1	eu_1
+EBA	CO	1	http://www.eba.europa.eu/xbrl/role/dict/dom/CO/1	eba_1
+EBA	CS	1	http://www.eba.europa.eu/xbrl/role/dict/dom/CS/1	eba_1
+EBA	GA	2	http://www.eba.europa.eu/xbrl/role/dict/dom/GA/2	eba_2
+Bundesbank Statistics	CG	4	http://www.bundesbank.de/stat/xbrl/role/dict/dom/CG/4	de_stat_4
+Bundesbank Supervision	AP	2	http://www.bundesbank.de/sprv/xbrl/role/dict/dom/AP/2	de_sprv_2
+The schema file that represents hierarchies (defining role types and referring linkbases) is placed in the same folder as members and it is named hier.xsd. Examples of such schema files, their namespaces and prefixes are presented in Table 13.
+Table 13. Examples of schema files defining hierarchies for domain members
+Owner	Domain code	Hierarchies schema	Namespace	Prefix
+Cross-sector	GA	http://www.eurofiling.info/xbrl/dict/dom/ga/hier.xsd	http://www.eurofiling.info/xbrl/dict/dom/GA/hier	eu_GA_h
+EBA	CO	http://www.eba.europa.eu/xbrl/dict/dom/co/hier.xsd	http://www.eba.europa.eu/xbrl/dict/dom/CO/hier	eba_CO_h
+EBA	MI	http://www.eba.europa.eu/xbrl/dict/dom/mi/hier.xsd	http://www.eba.europa.eu/xbrl/dict/dom/MI/hier	eba_MI_h
+Bundesbank Statistics	CG	http://www.bundesbank.info/stat/xbrl/dict/dom/cg/hier.xsd	http://www.bundesbank.info/stat/xbrl/dict/dom/CG/hier	de_stat_CG_h
+Bundesbank Supervision	AP	http://www.bundesbank.info/sprv/xbrl/dict/dom/ap/hier.xsd	http://www.bundesbank.info/sprv/xbrl/dict/dom/AP/hier	de_sprv_AP_h
+Each hierarchy of domain members (represented by an extended link role as explained above) must indicate at least one dimension related to a hierarchy. Identification of this dimension is made:
+−	in the standard role of generic label (of a hierarchy) by indication of a dimension label (optional),
+−	in the documentation role of generic label (of a hierarchy) by indication a QName (qualified name) of a dimension item declaration (obligatory).
+Example of hierarchy reference to a dimension QName with documentation label role is presented below (there is a similar construct in English label linkbase):
+<link:loc xlink:type="locator" xlink:href="hier.xsd#de_sprv_1" xlink:label="loc_de_sprv_1" />
+<label:label xlink:type="resource" xlink:label="label_de_sprv_1_1" xml:lang="de" xlink:role="http://www.xbrl.org/2008/role/documentation">de_sprv_dim:CS</label:label>
+<gen:arc xlink:type="arc" xlink:arcrole="http://xbrl.org/arcrole/2008/element-label" xlink:from="loc_de_sprv_1" xlink:to="label_de_sprv_1_1" />
+This relation between hierarchies and dimensions is “many-to-many”, which means that a number of dimensions can be attached to one hierarchy and more than one hierarchy can be referred by the same dimension.
+In addition to labels, these schemas refer to three additional linkbases with information about hierarchies:
+-	a presentation linkbase (hier-pre.xml), which represents the hierarchical disposition of members in hierarchies using parent-child relationships,
+-	a definition linkbase (hier-def.xml), which enables the inclusion of the members of a hierarchy in dimensional combinations using domain-member relationships,
+-	a calculation linkbase (hier-cal.xml), which establishes some basic arithmetical relationships between a member of the hierarchy and its children:
+o	a member is equal to the addition of its child members in the hierarchy: complete-breakdown relationships,
+o	a member is greater or equal than the addition of its child members in the hierarchy: partial-breakdown relationships,
+o	a member is less or equal than the addition of its child members in the hierarchy: superset-breakdown relationships.
+These calculation arcs include a weight attribute to indicate whether the child member contributes to the aggregation positively (+1) or negatively (-1). These roles that represent these calculation relationships are defined in the model.xsd schema that supports the model and are presented in Table 14.
+Table 14. Arcroles defined in the model.xsd schema, reflecting different forms of aggregations of members.
+Arc role id	Arc role URI
+complete-breakdown	http://www.eurofiling.info/xbrl/arcrole/complete-breakdown
+partial-breakdown	http://www.eurofiling.info/xbrl/arcrole/partial-breakdown
+superset-breakdown	http://www.eurofiling.info/xbrl/arcrole/superset-breakdown
+The root member of the definition and presentation relationship networks is the domain item defined in the schema exp.xsd associated with the owner.
+Domain members that extend the domain of another owner are placed in a folder preceded by the prefix of the extended owner. Example of  extension of the cross-sector domain by with EBA specific concepts are presented in Table 15.
+Table 15. Examples of the extension of the cross-sector domain by with EBA specific concepts
+Code	Extending domain members schema	Namespace	Prefix
+GA	http://www.eba.europa.eu/eu/xbrl/dict/dom/eu_ga/mem.xsd	http://www.eba.europa.eu/xbrl/dict/dom/GA	eba_eu_GA
+CU	http://www.eba.europa.eu/eu/xbrl/dict/dom/eu_cu/mem.xsd	http://www.eba.europa.eu/xbrl/dict/dom/CU	eba_eu_CU
+.4.4.3.2	Typed domains
+Members of typed domains are neither listed as XBRL items with labels nor arranged in hierarchies. The content of typed domains is restricted by XML data type constraints, as these domains (according to the XBRL Dimension specification) are XML elements.
+In most of the cases, a typed domain would be represented by an XML element with a simple data type (e.g. xs:string or xs:decimal). Further restrictions on the expected value are introduced by means of the Formula specification where value assertions define detailed constraints on the allowed values of a typed domain in association with a certain dimension. For example, the typed domain Code, being a string data type, may follow a certain pattern defined by a value assertion when referred from the Related entity code dimension and another pattern when used by the Instrument code dimension.
+.4.4.4	Dimension items
+Dimension items’ representation in XBRL is defined in the XBRL Dimensions 1.0 specification.
+The local name of each dimension corresponds to its code in the model: a short sequence of capital case letters (usually two, but may be more).
+Value of the id attribute of the element representing a dimension item (necessary for XLink locators) is composed according to the following pattern :
+{opre}_{name}
+where {opre} represents the prefix of the base namespace of the owner of the dimension and {name} represents the name described above. A few examples of dimension items are presented in Table 16.
+Table 16. Examples of dimensions items
+Owner	Code	Name	Id	Namespace	Prefix
+Cross-sector	IC	IC	eu_IC	http://www.eurofiling.info/xbrl/dict/dim	eu_dim
+EBA	PL	PL	eba_PL	http://www.eba.europa.eu/xbrl/dict/dim	eba_dim
+EBA	MC	MC	eba_MC	http://www.eba.europa.eu/xbrl/dict/dim	eba_dim
+Bundesbank Statistics	RM	RM	es_RM	http://www.bundesbank.de/stat/xbrl/dict/dim	de_stat_dim
+Bundesbank Supervision	ICT	ICT	es_ICT	http://www.bundesbank.de/sprv/xbrl/dict/dim	de_sprv_dim
+Names of schema files defining dimension items is dim.xsd and they include references to label linkbase files and a definition linkbase whose file name is dim-def.xml and are placed in the same folder as the schema file.
+This definition linkbase includes the following information about explicit dimensions:
+	reference to the domain associated to the dimension by means of a dimension-domain relationship (with xbrldt:usable attribute equal to false) pointing to a domain item defined in respective exp.xsd or typ.xsd schema file of any referenced or defined owner,
+	reference to the default member of that dimension by means of a dimension-default relationship (note that although the model defines default members at the domain level, the XBRL Dimensions specification establishes this relationship at dimension level; thus, each dimension using a domain with a default member must include this relationship).
+These relationships associating dimension with a domain and its default members are defined in an extended whose role is the standard one (i.e. http://www.xbrl.org/2003/role/link).
+.4.4.5	Families
+Families are placed in the same folder as dimensions. Families are represented as XBRL abstract items of data type model:familyType. The local name of each family corresponds to its numeric code in the model preceded by a lower case letter f. Value of the id attribute of family elements is composed as follows:
+{opre}_{name}
+where {opre} represents the prefix of the base namespace of the owner of the family and {name} represents the local name described above. Some examples are presented in Table 17.
+Table 17. Examples of families
+Owner	Code	Name	Id	Namespace	Prefix
+EBA	1	f1	eba_f1	http://www.eba.europa.eu/xbrl/dict/fam	eba_fam
+EBA	2	f2	eba_f2	http://www.eba.europa.eu/xbrl/dict/fam	eba_fam
+Bundesbank Statistics	1	f1	de_stat_f1	http://www.bundesbank.de/stat/xbrl/dict/fam	de_stat_fam
+Bundesbank Supervision	5	f5	de_sprv_f5	http://www.bundesbank.de/sprv/xbrl/dict/fam	de_sprv_fam
+.4.4.6	Perspectives
+Perspectives are placed in the same folder as dimensions and families. Perspectives are represented as extended link roles that are used in presentation linkbases, where the relationships between dimensions and families are formalized.
+The URI of these roles is built according to the following pattern:
+{ons}/role/dict/pers/{code}
+where {ons} corresponds to the owner namespace and {code} represents the numeric code given to the perspective in the model.
+Value of the id attribute of the role type is composed according to the following patter:
+{opre}_p{code}
+where {opre} corresponds to the owner prefix and {code} represents the numeric code of the perspective in the model. Examples of perspectives are presented in Table 18.
+Table 18. Examples of perspectives
+Owner	Code	Role	Id
+EBA	1	http://www.eba.europa.eu/xbrl/role/dict/pers/1	eba_p1
+EBA	2	http:// www.eba.europa.eu/xbrl/role/dict/pers/2	eba_p2
+Bundesbank Statistics	1	http://www.budnesbank.de/stat/xbrl/role/dict/pers/1	de_stat_p1
+Bundesbank Supervision	5	http://www.bundesbank.de/sprv/xbrl/role/dict/pers/5	de_sprv_p5
+The schema file defining perspectives (pers.xsd) imports the schemas of families and dimensions, and refers to a generic linkbase containing generic labels of perspectives and a presentation linkbase (pers-pre.xml) including extended links that correspond to each perspective. The arcs in these extended links have families as source (root) nodes and dimensions as target nodes.
+.4.5	Reporting requirements layer
+Frameworks, taxonomies, tables, modules and other concepts constitute the layer of the model where actual reporting requirements are specified with the support of the financial concepts defined in the dictionary.
+All the files that correspond to this layer are placed under the folder fws in the official location of its owner. Its namespace is obtained by adding the suffix fws to the base namespace of the owner plus some additional suffixes that depend on the type of the concept represented.
+In case of the Bundesbank taxonomies frameworks (similarly to the dictionary layer) are defined separately for the statistical and supervisory datasets.
+.4.5.1	Frameworks
+Frameworks are public elements represented using XBRL abstract items of the framework type (model:frameworkType) in the schema file fws.xsd. General framework properties are presented in Table 19.
+Table 19. Framework properties
+Schema property	Value
+Official location	{oloc}/fws/fws.xsd
+Target namespace	{ons}/fws
+Target namespace prefix 	{opre}_fws
+Element local name	{framework}
+Element id	{opre}_{framework}
+The local name of each framework element corresponds to its code in the model and its id follows the general pattern.
+Examples of frameworks defined by the EBA or Bundesbank taxonomies for statistical and supervisory data are presented in Table 20.
+Table 20. Examples of frameworks
+Owner	Schema property	Value
+EBA	Official location	http://www.eba.europa.eu/eu/fr/xbrl/fws/fws.xsd
+	Target namespace	http://www.eba.europa.eu/xbrl/fws
+	Target namespace prefix	eba_fws
+	Local name example	finrep, corep
+	Element id example	eba_finrep, eba_corep
+	Element label (English)	FINnancial REPorting, COmmon REPorting
+Bundesbank Statistics	Official location	http://www.bundesbank.de/de/stat/xbrl/fws/fws.xsd
+	Target namespace	http://www.bundesbank.de/stat/xbrl/fws
+	Target namespace prefix	de_stat_fws
+	Local name example	mbs
+	Element id example	de_stat_mbs
+	Element label (English)	Monthly Balance Sheet Statistics
+	Element label (German)	Monatliche Bilanzstatistik
+Bundesbank Supervision	Official location	http://www.bundesbank.de/de/sprv/xbrl/fws/fws.xsd
+	Target namespace	http://www.bundesbank.de/sprv/xbrl/fws
+	Target namespace prefix	de_sprv_fws
+	Local name examples	fmr, misc
+	Element id examples	de_sprv_fmr, de_sprv_misc
+	Element label (English)	Financial Reporting and Monthly Return Reports, Miscellaneous Reports
+	Element label (German)	Jahresabschluss, Basis und Monatsausweisverordnung, Verschiedene
+Each framework has a folder where the files of its taxonomies are placed. This folder has the name of its code in the model as presented on examples in Table 21.
+Table 21. Examples of framework folders
+Description	Framework folder
+EBA FINREP	http://www.eba.europa.eu/eu/fr/xbrl/fws/finrep/
+Bundesbank Statistics, Monthly Balance Sheet Information	http://www.bundesbank.de/de/stat/xbrl/fws/mbs/
+Bundesbank Supervision, Financial Reporting and Monthly Return Reports	http://www.bundesbank.de/de/sprv/xbrl/fws/fmr/
+Bundesbank Supervision, Miscellaneous Reports	http://www.bundesbank.de/de/sprv/xbrl/fws/misc/
+.4.5.2	Taxonomies
+Taxonomies are public elements represented using XBRL abstract items of the taxonomy type (model:taxonomyType). These elements are stored in the schema file tax.xsd under the folder of its framework, a subfolder that corresponds to its normative code or legislation publication date and another subfolder with the date  of taxonomy version.
+Thus, the file tax.xsd includes a single element. Its local name corresponds to its code in the model and value of its id attribute is constructed according to the general pattern ({opre}_{taxonomy code}). General taxonomy properties are presented in Table 22.
+Table 22. Taxonomy properties
+Schema property	Value
+Official location	{oloc}/fws/{framework}/{normative code or legislation publication date with “pub_” prefix}/{taxonomy publication date}/tax.xsd
+Target namespace	{ons}/fws/{framework}/{normative code or legislation publication date with “pub_” prefix}/{{taxonomy publication date}
+Target namespace prefix	{opre}_tax
+Element local name	{taxonomy}
+Element id	{opre}_{taxonomy}
+To facilitate the specification of additional taxonomy resources in this document, hereinafter in applies:
+	{taxonomy-loc} to the URL {oloc}/fws/{framework}/{normative code or legislation publication date with “pub_” prefix}/{taxonomy publication date},
+	{taxonomy-ns} to the URI {ons}/fws/{framework}/{normative code or legislation publication date with “pub_” prefix}/{taxonomy publication date}.
+Examples of taxonomy folders are presented in Table 23.
+Table 23. Examples of taxonomy folders
+Description	Framework folder
+EBA FINREP, CRR legislation, taxonomy published on December 31, 2012	http://www.eba.europa.eu/eu/fr/xbrl/fws/finrep/crr/2012-12-31
+Bundesbank Statistics, Monthly Balance Sheet Information, legislation published in July 2012, taxonomy published on October 31, 2012	http://www.bundesbank.de/de/stat/xbrl/fws/mbs/pub_2012-07/2012-10-31
+Bundesbank Supervision, Financial Reporting and Monthly Return Reports, legislation published in January 2013, taxonomy published January 31, 2013	http://www.bundesbank.de/de/sprv/xbrl/fws/fmr/pub_2013-01-01/2013-01-31
+Bundesbank Supervision, Miscellaneous Reports, legislation published in January 2013, taxonomy published January 31, 2013	http://www.bundesbank.de/de/sprv/xbrl/fws/misc/pub_2013-01-01/2013-01-31
+The folder of taxonomy includes three subfolders for:
+	tables (tab),
+	modules (mod) and
+	validations (val).
+Content of these subfolders is explained in the next sections of this document.
+.4.5.3	Tables
+The table folder includes a schema file (tab.xsd) that references a generic linkbase with the hierarchy of table groups and tables (tab-pre.xml) and a label linkbase for table groups (tab-lab-en.xml). The schema includes the definitions of table groups (if any), which are represented using XBRL abstract items of the table group type (model:tableGroupType). Name of a table group item is composed by adding the prefix tg to the code of a table group in the model or any other custom name. General properties of a table group are presented in Table 24.
+Table 24. Table group properties
+Schema property	Value
+Official location	{taxonomy-loc}/tab/tab.xsd
+Target namespace	{taxonomy-ns}/tab
+Target namespace prefix	{opre}_tab
+Element local name	tg{table-group-code} or other custom name
+Element id	{opre}_{local-name}
+Table groups are used to link numerous tables defined by one template or resulting from normalization of templates or if an original templates is composed by two or more physical tables.
+The files that define the content of each table are placed in a folder whose name corresponds to the code of the template in the model ({table code}). General properties of a table are presented in Table 25.
+Table 25. General properties of a table.
+Schema property	Value
+Official location	{taxonomy-loc}/tab/{table code}/{table code}.xsd
+Target namespace	{taxonomy-ns}/tab/{table code}
+Target namespace prefix	{opre}_tab_{table code}
+Element local name	N/A (elements defined as resources in linkbases)
+Element id	{opre}_{table code} (element defined as a resource in the table linkbase)
+{table code} apart from the code of a template defined in the model may include information about rendering of multiple tables resulting from split due to normalization of a larger original template. In such case, the position of each table in a larger template is identified by specifying its relation to other tables using the following notation:
+{xNyM}
+where x indicates placement of a table in the horizontal disposition, N is an integer number defining the order of tables in horizontal disposition, y represents placement of a table in the vertical disposition and M is an integer number indicating the order of tables in vertical disposition.
+For example, template C3 included in information requirements reflected by the Monthly Balance Sheet Statistics taxonomy has been split in six tables, whose codes are: c3_x1y1, c3_x2y1, c3_x1y2, c3_x2y2, c3_x1y3, c3_x2y3. Therefore, tables that constitute this template shall be rendered in the following order and organization:
+c3_x1y1	c3_x2y1
+c3_x1y2	c3_x2y2
+c3_x1y3	c3_x2y3
+There is a group-table relationship established in the presentation linkbase linking a group item  (in this example “c3”) with resources  representing each table split due to normalization (e.g. c3_x1y1, c3_x2y1, c3_x1y2, c3_x2y2, c3_x1y3, c3_x2y3).
+In case of templates with potential multiple occurrence, that are built from two tables, one representing header information and the other with data depending on the header information, {table code} apart from the code of a template as defined in the model includes also a suffix: _masterdata for header information and _data for the part of a template that contains the numbers. Examples of such templates are O2, P1 and S1 included in information requirements reflected by the Monthly Balance Sheet Statistics taxonomy.
+Similarly, templates that are originally constructed from more than one physical table include “Part N”  component in their name, where N corresponds to an integer. Examples of such templates are form H from the Monthly Balance Sheet Statistics information requirements or form HA classified as Miscellaneous in Supervision.
+Schema file for a table in refers to a table linkbase ({table}-rend.xml), a definition linkbase ({table}-def.xml) and a label linkbase ({table}-{lang}-lab.xml).
+The table linkbase includes the definition of the table according to the Table Linkbase specification. The relationships of each table are placed in an extended link whose role is built according to the following pattern:
+{ons}/role/fws/{framework}/{normative code or legislation publication date with “pub_” prefix}/{taxonomy publication date}/tab/{table code}
+In this linkbase, the different components of tables are represented using resources. Value of the id attribute of these resources is based on the code or sequential number plus a prefix to obtain a unique code in the context of the linkbase file (as presented on Table 26).
+Table 26. Table linkbase resources and their ids.
+Model class	Table linkbase resource	Id
+Table	table	{opre}_t{code}
+Predefined axis	ruleAxis (abstract = true)	{opre}_a{code}
+Variable axis	filterAxis	{opre}_a{code}
+Coordinate	ruleAxis	{opre}_c{code}
+Base items hierarchy reference	conceptRelationshipAxis	{opre}_h{code}
+Dimension hierarchy reference	dimensionRelationshipAxis	{opre}_h{code}
+According to the Table Linkbase specification, aspect rules are used to specify the concepts represented in predefined axes. In the case of duration type metrics, the size of the period to be reported is constrained using time aspect rules in the context of a table. The default value is a reference period ; other possible values are month, quarter, year, etc. In case of data points that correspond to an instant or period of time prior to the reference period, temporal aspect rules include a temporal offset relative to the reference date.
+The reference date and the reference period shall be defined in terms of two parameters defined in a linkbase file (http://www.eurofiling.info/eu/fr/xbrl/func/params.xml):
+-	refPeriodEndDate: reference date and end date of the reference period,
+-	refPeriodStartDate: starting date of the reference period.
+Examples of use of time references are presented in Table 27.
+Table 27. Examples of time references
+Time reference	Aspect rule
+Reference date	instant = refPeriodEndDate
+Reference period	duration.end = refPeriodEndDate
+duration.start = refPeriodStartDate
+Beginning of the reference period	instant = refPeriodStartDate
+A quarter ending at the reference date	duration.end = refPeriodEndDate
+duration.start = refPeriodEndDate - P3M + P1D
+Previous quarter	duration.end = refPeriodEndDate - P3M
+duration.start = refPeriodEndDate - P6M + P1D
+Instead of this mechanism, another method can be used to identify information referring to different time periods which is including this information in the semantics of business properties defined in the dictionary part of the model and taxonomy and subsequently applying them as aspect values on rendering resources representing headers of rows or columns in a table (ordinates/nodes on rendering axes). An example is “Carrying amount” and “Carrying amount [beginning balance]” as two separate primary items .
+The definition linkbase includes dimensional relationships valid in the context of the table. Valid combinations are defined using only positive (all) closed hypercubes obtained from the set of valid cells of the table following certain algorithm in order to optimize their number .
+Each extended link role contains one or more primary items and a single hypercube . In case of multiple primary items, the first one will be used to group the rest and reduce the number of all arcs. The domain element will be used as the target of dimension-domain arcs to avoid cycles. The @xbrldt:targetRole attribute might be necessary in the case of hypercubes with dimensions sharing the same domain.
+The roles of the extended links necessary to express these combinations are built adding numeric suffixes to the role previously defined for the table. For example:
+	{ons}/role/fws/{framework}/{normative code or legislation publication date with “pub_” prefix}/{taxonomy publication date}/tab/{table code}/1
+	{ons}/role/fws/{framework}/{normative code or legislation publication date with “pub_” prefix}/{taxonomy publication date}/tab/{table code}/2
+Label linkbase file for a table contains labels for Table Linkbase nodes. table:table node, apart from the standard label, contains also a documentation label. This label is constructed according to the following pattern:
+{template code}_{table part}_{table split arrangement}
+where:
+−	{template code} is obligatory and identifies a table association to an original template by referring to its code in capital letters, e.g. THV1, EJB, etc.; this code should be used on filing indicators (see 6.4.3 Filing indicators)
+−	{table part} is used when original template is constructed with two or more physical tables; it may take values “m” or “d” for masterdata and date respectively, or “pN” where N is integer assigned to each part of table,
+−	{table split arrangement} in the following format “xNyM” as explained above for the tables split due to normalization.
+Rendering nodes apart from the standard label reflecting text in the header of row/column may also contain verbose, documentation and code label. Verbose label contains a footnote associated with a header (i.e. text included under the table in an original template as for example in tables ELRV, KLRV, KZKR, etc). Documentation label includes reference to a legal regulation/standard or additional information from a template that may be associated with a row or columns (e.g. templates LV1 and LV2 contain a column with percentages that are applicable for each row). Technical construct behind the code label is explained in 6.3 Public elements. These are coded of rows or columns as defined in the original templates.
+.4.5.4	Modules
+Modules are represented using XBRL abstract items of the module type (model:moduleType). Each module is stored in a different schema file whose name is the same as the code of the module in the model plus the extension .xsd. These schema files import the schemas of all the tables required by that module and additionally header taxonomy and filing indicators. General properties of a module are presented in Table 28.
+Table 28. Properties of modules
+Schema property	Value
+Official location	{taxonomy-loc}/mod/{module}.xsd
+Target namespace	{taxonomy-bns}/mod/{module}
+Target namespace prefix	{opre}_mod_{module}
+Element local name	mod_{module}
+Element id	{opre}_mod_{module}
+In addition to label linkbases, each module includes a presentation linkbase ({module}-pre.xml) where the relationships between modules and tables or table groups are expressed using group-table arcs (defined in the model.xsd schema file) whose source is the module element and whose target is a table or a table group element.
+.4.5.5	Validations
+Validations are expressed using XBRL assertions.
+Assertions are grouped into assertion sets that correspond to the tables they are to be applied on.
+The link between an assertion set and the table (or tables ) it applies is represented using arcs from the assertion set to the resource that corresponds to the table. The arcrole URI of this arc is http://www.eurofiling.info/xbrl/arcrole/applies-to-table and it is defined in model.xsd.
+If an assertion applies to multiple tables individually or to multiple sets of tables, then it is associated to different assertion sets (see examples provided in Table 29).
+Table 29. Examples of assertions, assertion sets and tables they apply to
+Example	Assertion example (textual description)	Assertion sets	Tables
+	$a > 0 (where $a represents data in table 1)	assertion set 1	table1
+	$a > 0 (where $a represents data in tables 1, 2 and 3)	assertion set 1	table1
+		assertion set 2	table 2
+		assertion set 3	table 3
+	$a = $b (where $a represents data in table 1 whereas $b represents data in table 2)	assertion set 1	table 1
+table 2
+	$a = $b (where in some cases, $a represents data in table 1 and $b data in table 2; in other cases, $a represents data in table 3 and $b represents data in table 4)	assertion set 1	table 1
+table 2
+		assertion set 2	table 3
+table 4
+As public elements, assertion set resources may include model:fromDate and model:toDate attributes to constraint the reference date where their associate assertions should be applied.
+Assertions are identified by a unique code, so that it enables the identification of errors in a validation process with the corresponding definition . Assertions might include a description and custom error messages, as defined by business experts.
+Existence assertions shall only be used to detect errors in the case of mandatory data that must be reported. Whenever possible, value assertion shall be used instead of existence assertion, as the former enable more comprehensive error messages.
+The files that define assertions and assertion sets are grouped into files depending on their scope. These files are placed in the val folder of the corresponding taxonomy, together with files to define preconditions and filters  of common use shared by different assertions in the taxonomy and parameters. Examples of location and names of linkbase files containing value assertions and shared parameters, filters and preconditions are presented in Table 30.
+Table 30. Examples of location and names of linkbase files containing value assertions and shared parameters, filters and preconditions
+Resource description	File location
+Assertions and assertion sets location that apply to a single table (example 1)	{taxonomy-loc}/val/val-{tab1}.xml
+Assertions and assertion sets location that apply to multiple tables individually (example 2)	{taxonomy-loc}/val/val-{tab1}.{tab2}.xml
+Assertions and assertions sets location that cross information in a set of tables (example 3)	{taxonomy-loc}/val/val-{tab1}_{tab2}.xml
+Assertions and assertions sets location that cross information in a multiple sets of tables (example 4)	{taxonomy-loc}/val/val-{tab1}_{tab2}.{tab3}_{tab4}.xml
+Parameters	{taxonomy-loc}/val/params.xml
+Filters common to multiple assertions in the taxonomy	{taxonomy-loc}/val/filt.xml
+Preconditions common to multiple assertions in the taxonomy	{taxonomy-loc}/val/prec.xml
+Any of these linkbases can have its corresponding set of label linkbases, following the convention defined in this document. In the case of assertions, an additional set of linkbases might be included for error messages. Name of this file is created according to the following pattern:
+{assertions-file}-err-{lang}.xml
+where {assertions-file} corresponds to the name of the file with the assertions whose error message are described, without the extension.
+These files will be included by the modules defined in the taxonomy.
+In order to handle the error margin caused by the imprecision of input data, assertions can make use of a set of functions implemented according to the Custom Functions Implementation specification. These functions use the same name as the ones defined in the XPath 2.0 Functions specifications, but are defined in the namespace http://www.eurofiling.info/xbrl/func/interval-arithmetics and placed in the following official location: -http://www.eurofiling.info/eu/fr/xbrl/func/interval-arithmetics.xml. An entry point for these and any additional functions that could be provided in the future is the following schema file: http://www.eurofiling.info/eu/fr/xbrl/func/functions.xsd.
+NOTE: The above explanation of implementation of assertions may be modified following the best/common practice established by the EBA taxonomies and their architecture as well as specific needs that may result from first developments of the Formula specification business rules for the Deutsche Bundesbank.
+Annex A: Data Point Modelling
+Development process
+Ideally, a DPM is developed as the first artefact in the process of definition of information requirements. It shall represent the analytical needs of business experts required for fulfilment of supervisory tasks and policy making, by identifying in the form of breakdowns different domains of interest. Subsequently the legislation is prepared together with supporting guidelines, for example tabular views representing the current reporting requirements, selected as a subset of all potentially logical combinations of the predefined breakdowns.
+The other approach is to first define the tabular views (including the detailed guidelines) and subsequently analyse them in order to list all business properties and arrange them in breakdowns. This method is more common as it represents an evolutionary step in information requirements setting. It is possible that in the process of DPM definition based on existing tabular views, some of the templates may require adjusting (normalization) of their layout. This is the consequence of the application of a consistent model on a rather flexible format which is tabular views.
+General building blocks and terminology
+Data Point Model defines business properties that are used to describe each and every piece of the information requirements (hereinafter referred to as a data point and data points respectively).
+These properties are gathered in sets based on their common and cohesive nature.
+Distinguishing these properties and their coherence is based on a subjective view of the author. However, this does not mean there are no rules guiding this process. The model shall at least fulfil the basic business requirements such as accuracy, completeness, uniqueness and unambiguity which assume application of certain patterns in the property definition process as well as when performing quality assurance tests.
+In any case, there are certain properties that must characterise each piece of the information requirements (each data point). These are:
+−	type of the expected value of a fact (e.g. text, monetary value, a number with or without decimals, date, etc.),
+−	duration in time of a defined business concept, distinguishing between a stock - stated at a point in time (such as any asset or liability) - and a flow, reported for a period of time (e.g. revenues, cash flows, etc.).
+The type of the expected value is the minimum requirement for the description of each data point and is referred to as a metric. A metric can also include the stock/flow aspect and other semantics (business properties) depending on the decision of the model’s author. Each data point in the model must define one and only one metric.
+Other business properties describing or detailing the data point and which are not included in the definition of a metric are defined in the form of pairs of dimension members. Members are gathered in sets called domains, can be arranged in hierarchical relationships (subdomains) and are contextualized by dimensions. Certain rules and examples presented in the next paragraphs have been added to facilitate the comprehension of these terms.
+A domain is a cohesive set of members i.e. all members from a domain share a certain common nature defined subjectively but applied consistently by the model’s author. A typical example of a domain is “Geographical areas”. Members of this domain could be different areas of the Earth, classified according to the physical geography (“Europe”, “Pacific Ocean”, “Himalayas”, …) and/or human geography (“France”, “EU”, “G-20 major economies”, …). Combining physical and human geography into one domain is already a subjective view of the author of the classification.
+Members of a domain can be defined by explicit enumeration of each member or by imposing a constraint on the expected value for each enumeration. A domain of the first kind is called explicit domain, and an example could be the “Geographical areas” presented above. The latter is called a typed domain (the name comes from the data type restriction on its content). An example of a typed domain could be the ISBN identifier (used for uniquely identifying books and similar publications) which is restricted to a certain number of digits.
+Members of an explicit domain should participate in relationships, typically forming hierarchical tree-structures. Not every hierarchy must include all members of a domain (especially when there could be alternative classifications, e.g. “Poland”/”Other than Poland” and “EU”/”Other than EU” would never form a single hierarchy as “EU” includes “Poland” plus some other countries while “Other than EU” includes “Other than Poland” minus some countries). Therefore hierarchies are called subdomains (even though in some cases they can define relationships including all members of a domain).
+In case of business data, these relationships would typically reflect basic arithmetic operations where lower level elements aggregate to an upper level element with a certain weight. Comparison operators used to express the relationship between the upper level element and contributing lower level elements could be one of the following “=”, “≥” or “≤”, and the multiplication factors (weights) are typically “+1” or “-1”. In other cases when there are no arithmetic relations, hierarchies are also created to define subgroups of members for other purposes (e.g. hierarchies shared by a large subset of information requirements). Whatever the kind of relationship, hierarchies are an important part of the model as they help in maintaining internal coherence of a domain.
+Each domain must be associated with one or more dimensions. Theoretically, one dimension could refer to members of multiple domains. However, this is prohibited in the DPM.
+Dimensions contextualize domain members when applied to a data point (they add up to the semantics of a member which, without a dimension, may be insufficient to represent the full meaning of a property). For instance, in the example above, “Spain” is a geographical area which could represent “Location of an issuer” of a financial instrument, “Location of a stock exchange” where this instrument is traded, “Location of a broker” who participated as a middleman in the transaction or finally “Location of a buyer” who purchased this instrument. The same domain member “Spain” was contextualized in this example by four different dimensions. A similar situation may appear in case of a typed domain whose restriction could be different based on the dimension contextualizing its value (e.g. code = 123-345-567-890 could be the “Identification number for tax purposes” or “Company registration number”, where the kind/type of the number is given by the dimension). Moreover, in case of typed domains, the application of a certain dimension may impact the pattern or enumeration for potential values of a typed domain (for example “ISBN-10” and “ISBN-13” refer to the same “ISBN” domain but expected values are restricted to 10 and 13 digits respectively).
+Dimensions referring to explicit domains may have default members, which are implicitly applied to every data point that is not explicitly characterised by a particular dimension. For example, a dimension “Original currency” may be associated with a default member “All currencies”. This means that when a data point does not explicitly mention the “Original currency” dimension, it is assumed that it takes the “All currencies” member for this dimension.
+Default members are very useful when defining the model as otherwise every data point would have to explicitly mention each dimension and the applicable member. With default members it is enough for a data point to name only the properties that are important and distinguish this data point from other data points. Although “default” is a property of a member with respect to a dimension, the DPM assumes that all dimensions referring to a certain domain would have the same default member. This means that only one member in a domain can be assigned as a default and shall apply to all dimensions referring to this domain. There could be dimensions in the model that do not apply to some data points. For example, a data point representing “Equity instruments” is not linked to the “Original maturity” dimension at all (shares and other ownership rights simply do not have maturity). Therefore, the default member is usually named “Total/Not-applicable”.
+Each pair of a dimension and a member (either explicit or typed) is a single business property of a data point.
+A data point can have none, one or more such business properties.
+Each dimension must not be associated with a data point more than once.
+Annex B: Taxonomy architecture diagram
+Annex C: Information requirements and taxonomy scope overview diagram