Best Practices on Data Definitions
From XBRLWiki
| Revision as of 13:43, 15 January 2009 (edit) Katrin (Talk | contribs) ← Previous diff |
Current revision (10:01, 9 June 2013) (edit) Iboixo (Talk | contribs) (→Numeric items) |
Current revision
ALL TOPICS ARE STILL ON DISCUSSION!
Overview of the Best Practice agreements
| Precision / decimal attributes | TWO DECIMALS, decimals="2". All monetaryItemType (or derivates) figures shall be reported in cents: 1755.89 equals 1755.89 Euro, or 1755 Euro and 89 Cents (or the currency actually used). |
| Percentages | Percentages shall be reported between 0 and 1, with decimals="4". A ratio of 18,78% shall be reported as 0.1878 (1878 Basic Points). |
| Foreign exchange reference rates | Common practice is the reporting of conversion rates with up to six significant digits, following the standard on Euro conversion rule for irrevocable rates. |
| Threshold/tolerance margin | The tolerance shall be set to 1000 Euro (or the currency actually used), implying that 12500 Euro is considered as anything between 11500 and 13500 Euro when executing business or calculation rules. |
| Nil, null, zero and blank values | Numeric values including zero are to reporting as facts in an instance. Unknown or not applicable information should not be included in an instance. |
| Non-numeric items: definition and values | String, date, time and boolean shall be based in W3C datatypes as published in http://www.w3.org/TR/xmlschema-2/ |
| Reporting institution identification | To be defined in "Eurofiling Header" |
| Report type (Solo, Consolidated, other options) | To be defined in "Eurofiling Header" |
| ID and tagging of cells and (sub)totals | To be defined in "Eurofiling Header" |
| Administrative data and feedback parameters | To be defined in "Eurofiling Header" |
| Character codification (UTF-8 or others) | It is recommended to use only "UTF-8" for the CEBS XBRL reporting. |
Introduction
While national reporting frameworks that collect regulatory reports formulated on both IAS/IFRS and the Capital Requirements Directive are all based on the CEBS Guidelines on Reporting, each national implementation varies from one country to another. Therefore, CEBS has launched a project on the harmonization and streamlining of supervisory reporting frameworks with the aim of delivering the EU-wide reporting formats as requested by the ECOFIN.
The IT harmonisation started in 2005, with the development of the COREP and FINREP electronic reporting formats, the so-called XBRL taxonomies. A number of european countries are now using these formats (with national options as deemed necessary), on either a mandatory or optional basis. Currently, the existing technology makes feasible the use of EU-wide harmonised formats, including the validation of most of the reports from the banks, thereby reducing the number of invalid filings and thus speeding up the remittance process. The experience has clearly demonstrated the feasibility to make use of EU-wide harmonised formats. National options are not precluded, albeit with some effort and provided the rules have been strictly followed.
Streamlining and harmonising reporting requirements in Europe
The harmonising of supervisory data definitions is a necessary, but not sufficient condition, to enable an EU-wide harmonization at the IT level. A questionnaire, answered by most of the EU supervisors, shows the need for further harmonisation of IT details.
The CEBS XBRL Operational Network is aware of a lot of implications to harmonise also the XBRL reporting based on COREP and FINREP in Europe. This document lists several reporting issues where a common view of European Banking Supervisors using XBRL is needed and therefore the CEBS XBRL Operational Network recommends to find agreements between the Banking Supervisors involved. The reporting impacts for an harmonised reporting across Europe are described below:
Harmonisation topics
Decimals, Precision, Decimal separator, Percentages
Precision and decimal attributes
Definition
XBRL Specification states that in the case of numerical values it is necessary to specify either a decimals or precision attribute so they must not occur together on the same fact element. The CEBS XBRL Operational Network recommends the use of the decimals attribute instead of precision for numerical values in instance documents based on COREP or FINREP taxonomies. The integer value of the decimals attribute defines the number of decimal places to which the value may be considered accurate. It answers the question on how many digits the banking supervisor can trust because the value might be a result of rounding or truncation.
XBRL 2.1 Specification example:
| decimals="2" | The value of the numeric fact is known to be correct to 2 decimal places. | If a value of 10 is reported than the value can range between 9.995 and 10.005 |
| decimals="-2" | The value of the numeric fact is known to be correct to –2 decimal places, i.e. all digits to the left of the hundreds digit are accurate. | If a value of 2002000 is reported than the value can range between 2001950 and 2002050 |
XBRL parsers rely on the decimals attribute to process the rounding of fact values. While consuming instance data, numbers with the desired degree of precision can be produced by the financial regulator. This mechanism is important when aggregated values
must match with the sum of its child item values depending on the rounded number of decimals. For rounding differences that cannot be preclude, each financial regulator defines thresholds for minor rounding variations.
Most financial regulators predefined the accuracy of the data to be reported, ie. in thousand or million. To ease the composition of the data for the reporting institut, the unrounded values of the database can be put into the fact and the decimals attribute defines how the value should be rounded.
The rounding is being done while consuming the data by the financial regulator.
The table below shows how the decimals might be set for a defined accuracy:
| in thousand | decimals="-3" |
| in million | decimals="-6" |
| accurate value | decimals="INF" or decimals="2" |
| percent | decimals="2" |
Business case
Multinational financial institutions underlying different supervisors must comply with the requirements set in different countries. Often these requirements differ. Regarding the reported values some countries ask for numbers expressed in thousands or millions but some require precise numbers expressed together with cents (or their equivalent). The accuracy of required numbers impacts the validation of these numbers on reporting gates of the supervisors. Especially for multinational financial institutions which use the same set of numbers to report to different supervisors it can lead to issues.
XBRL Perspective on the Business case
The issue mostly concerns the calculation linkbase not being able to calculate properly numbers with a given value of the decimal attribute.
Example below uses two supervisors (1 and 2) and a multinational bank reporting to both of them.
Elements A=B+C+D are modelled in the core taxonomy.
Supervisor 1 imposes use of decimals="2" and supervisor 2 imposes use of decimals="-3".
Multinational bank has following data in their system:
A=4000.00
B=1300.00
C=1300.00
D=1400.00
and reports these numbers to both supervisors.
The validation for supervisor 1 (decimals="2") will conduct a calculation for 1300+1300+1400=4000 and produce result "valid".
The validation for supervisor 2 (decimals="-3") will conduct a calculation for 1000+1000+1000=4000 and produce result "not valid". The instance document will be not accepted at the gate. To be accepted this multinational bank has to change one of the numbers.
For example it would require the bank to change the data from the system (which can be reported without issues to supervisor 1) to:
A=4000.00
B=1000.00
C=1000.00
D=2000.00
for supervisor 2. This leads to another issue if a bank is allowed to report two different set of numbers to two supervisors.
EUROFILING Best Practice Perspective
The background for the reporting of values in thousand and millions is historical and with regard to paper-based reports. Most of the reporting in Europe is actually being done electronically, so there is no need to ease the filling of reports by requesting only the main parts of an amount. As explained above, reporting accurate values reduces the complexity of rounding. Another argument for more precise amounts is the definition of rounding thresholds for calculations. Most of the European supervisors use variable thresholds. Sometimes also depending on the number of items included in the calculation or depending on the rounding definition (thousands, millions). Depending on the grade of accuracy of the amounts, smaller thresholds can be defined to adjust the rounding differences.
Agreeing on a certain value of the decimals attribute and establishing this as a best practice for EUROFILING will help financial institutions deal with creating instance documents. From the current perspective the greater common nominator required by the European supervisors is decimals="2". The established common practice could use this value.
An alternative to the use of decimals="2" would be decimals="INF" accepting for calculations the values with accuracy as reported. This can however lead to later problems in the databases of supervisors where certain accuracy is allowed (by the field/record definition). If a financial institutions reports numbers with for example 10 digits after comma (1999.3333333333) and the validation engine rounds/truncates the number in the ETL process the inconsistency in calculation will be still in place.
Units
Numeric items have a unitRef attribute to be reported in an instance. Units that are referred have to be declared in the instance. According to XBRL rules monetary items must have a unit of measure from the ISO 4217 namespace of currencies. The unit "pure" could be used for dimensionless numeric items like percentages or rates. It is recommended by FRTA (2.7.4) to use standard units to increase the comparability of numeric items.
Numeric items
An XBRL numeric value is defined as an optional sign “+” or “-”, followed by one or more decimal digits (“0” to “9”) and, optionally, a decimal point “.” followed by zero or more decimal digits.
More formally, the definition on Extended Backus-Naur Form is:
<digit> = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" ;
<number> = [ "+" | "-" ] { <digit> } <digit> [ "." { <digit> } ] ;
Examples: 0 +0. 1234 -1234 1234.56 +123456.7890123456
The decimal separator or decimal point or decimal comma is a symbol used to mark the boundary between the integral and the fractional parts of a decimal number in a positional numeral system. In the XBRL 2.1 recommendation, the period (.) it is used as the decimal separator.
A scale factor is a constant multiplier such as thousands, thousandths, etc. Scale factor MUST NOT be used (FRTA (2.7.5)). This means that is simply a matter of including enough zeroes before or after the decimal point so as to represent the fact correctly in the instance.
Percentages
Percentages should be rounded to four decimals. Rates, percentages and ratios should be reported using decimal rather than in percentages where the value has been multiplied by 100. As percentages are reported between 0 and 1, a ratio of 18,78% should be reported as 0.1878 with decimals="4".
Currency conversion
Currency conversion rates are not yet used in the EUROFILING reporting and the definition will be discussed when this topic comes up in the future. Common practice is the reporting of conversion rates with up to six significant digits, following the standard on Euro conversion rule for irrevocable rates.
Threshold/tolerance margin
To avoid rounding errors, tolerances must be applied. For the first case, so monetaryItemType (or types derived from this type), the tolerance should be set to 1000 Euro, implying that 12500 Euro is considered as anything between 11500 and 13500 Euro when executing business or calculation rules.
For percentages, the tolerance level is of course different. Here a tolerance of 0.0005 (0.05%) should be applied, implying that 0.1233 is equal to anything between 0.1228 and 0.1238 or 12.33% is considered as anything between 12.28% and 12.38% when executing business or calculation rules. If this seems too strict, 0.001 (0.1%) could be considered as a tolerance; this would imply that 0.1233 (12.33%) is considered as anything between 0.1223 (12.23%) and 0.1243 (12.43%).
Nil, null, zero and blank values
The nil attribute of XML Schema is used to allow facts to be reported with a "null" value to indicate that an information is unknown or an inapplicable information and this should be reported explicitly with an element.
The nil value doesn't appear as element content, instead an attribute is used to indicate that the content is nil. If the nil attribute is set to "true" in the XML schema than the attribute xsi:nil = "true" must appear in an element hat has no element text content.
In the actual COREP taxonomies all nil attributes are set to "true". This is also the recommendation of FRTA (2.1.6).
This table shows the different possible solutions to report zero, null and not applicable information:
| zero value | The value of the fact is "0". | <p-cm-ca:CapitalRequirements precision="INF" unitRef="EUR" contextRef="ctx_1">0</p-cm-ca:CapitalRequirements> |
| null value | The value of the fact is not known or can't be received. | <p-cm-ca:CapitalRequirements xsi:nil="true" unitRef="EUR" contextRef="ctx_1"></p-cm-ca:CapitalRequirements>
equivalent to: <p-cm-ca:CapitalRequirements xsi:nil="true" unitRef="EUR" contextRef="ctx_1" /> |
| not applicable information | The value is an inapplicable information. | The fact doesn't appear in the instance. |
Best Practice: It is recommended not to distinguish between unknown and inapplicable information in the CEBS reporting.
Numeric values including zero are to reporting as facts in an instance. Unknown or not applicable information should not be included in an instance. The according fact should be left out. If a fact with a nil attribute is sent then the value should be treated as not existing and to be ignored.
Non-numeric items: definition and values
Non-numeric items are items that are not numeric, as string, text block, boolean, date or other. The facts reported in an instance on basis of these items doesn't contain unitRef or precision/decimal attributes. All XBRL specific numeric and non-numeric item types are listed in the XBRL 2.1 Specification .
In COREP these items are used to put in codes which give a special meaning to a number. In many cases, reported information is to be used for further processing, like aggregation or filtering. Non-numeric values therefore should be limited as much as possible to an exhaustive list or restricted by a pattern. From the European Banking Supervision perspective only a few non-monetary item types are considered as useful.
Best Practice:
- stringItemType: This XBRL item type is based on the string datatype of W3. Defined at http://www.w3.org/TR/xmlschema-2/#string It is recommended to use only free string item types and maintain restrictions and other patterns in the Formula Linkbase. Changes on the validation won't have influence on the main taxonomy and the maintenance is more convenient in a linkbase.
- dateItemType: This XBRL item type is based on the date datatype of W3. Defined at http://www.w3.org/TR/xmlschema-2/#date
- timeItemType: This XBRL item type is based on the time datatype of W3. Defined at http://www.w3.org/TR/xmlschema-2/#time
- booleanItemType: This XBRL item type is based on the boolean datatype of W3. Defined at http://www.w3.org/TR/xmlschema-2/#boolean. According to W3 this datatype can contain the following values: "true" or "false"; "1" or "0". There is a need to be consistent here and the suggestion here is to follow the guidelines in http://www.w3.org/ for how to deal with issues such as the Boolean value being left blank. See http://www.w3.org/TR/xmlschema-2/#rf-whiteSpace
In case of the necessity to define additional types this topic will be discussed in the CEBS XBRL Network. The goal is to define a definite amount of data types to be used in the European Supervision context.
Reporting entity identification
The "Entity Code" in any COREP and FINREP XBRL instance document SHOULD be a valid "MFI ID code" in the ECB-MFI list, as published by the European Central Bank.
"Monetary Financial Institutions" (MFIs) are central banks, resident credit entities as defined in Community law, and other resident financial entities whose business is to receive deposits and/or close substitutes for deposits from entities other than MFIs and, for their own account (at least in economic terms), to grant credits and/or make investments in securities. For further details on definitions, please refer to www.ecb.int/stats/pdf/money/mfi/mfi_definitions.pdf.
The MFI ID code is unique to each entity listed in the List of MFIs. Each National Central Bank is responsible for allocating an unique MFI ID code for every MFI resident in their territory. Most of the reporting entities in Europe have a MFI ID code but there are also several entities that have to report their solvency data but they are not to be categorised as MFI, f.e. holding companies or asset management companies.
The MFI ID code convention is 2 characters -ISO code of the country of residence of the MFI- followed by up to 28 alphanumerical characters as asigned by the National Central Bank. The MFI ID lengths observed on 2010/12/12 are different country by country, and also inside a country, as follows: 3 (PT); 4 (PT); 5 (GR, IE, NL, PT); 6 (DK, ES, GB, GR, LT, NL); 7 (AT, DE, FR, IT, LT, PL, PT, SE); 8 (CY, DK, ES, HU, IE, LU, LV, MT, PT); 9 (DK, PT, RO, SI); 10 (BE, , BG, CZ, EE, FI, HU, IT, SK); 11 (EU); 12 (BE, FR, RO, SI); 13 (BE, LU); 14 (FI, RO, SK); 15 (SK); 17 (RO); 18 (RO). It was also observed that in an EU country the MFI ID is different of the respective National Supervisory Authority register, as in the examples (GB0040 vs. 114724) and (GB0075 vs. 204590)
The Joinup initiative European Commission has released the Core Business Vocabulary providing a minimum set of classes and properties for describing a legal entity. The vocabulary is closely integrated with the Person and Location Core Vocabularies.
The international Legal Entity Identifier (LEI) is an initiative of the Financial Stability Board.
Best Practice: If available, the "MFI ID code" should be used as value of the xbrli:identifier element in the instance to report on COREP and FINREP and additionally the value of the scheme attribute should refer to the ECB website: "http://www.ecb.eu/stats/money/mfi".
Example: <xbrli:identifier scheme="http://www.ecb.eu/stats/money/mfi">DE00002</xbrli:identifier>
In case that a "MFI ID code" doesn't exist, i.e. for Norway (not part of the EU), it is recommened to use a proprietary national id code with the scheme refering to the corresponding national central bank. <xbrli:identifier scheme="http://www.kredittilsynet.no">NO12345678</xbrli:identifier>
Report type (Solo, Consolidated, other options)
Most of the national supervisors use the same taxonomy for the discrimination of solo and consolidated. It is being done by adding a dimension in the segment or scenario element or by providing the information in the header of the file. As the reporting on solo or consolidated basis is a common information it should be integrated in the harmonised taxonomies for COREP. Proposal to distinguish the different status of consolidation:
- consolidated
- non consolidated head & branches
- non consolidated head
- non consolidated branch
Audit status
Several national central banks receive reports on basis on FINREP templates twice, before and after the audit of the report. It is proposed to include this information in the XBRL taxonomy or as part of the header information. Proposal to distinguish between the following audit status:
- provisional
- audited
ID and tagging of cells and (sub)totals
COREP and FINREP reports are traditionally form-driven. In an average series of reports, a preparer faces a multitude of forms which in the ideal case get sourced automatically from underlying data systems.
Mapping data structures to forms can only be as efficient as the coordinates which are given to each reported cell.
In order to avoid that each country authority or by the lack of, each preparer of that country, applies another set of coordinates, it is advisable that basic line and column numbering is applied in the forms which are released to the community.
Sample
Administrative data and feedback parameters
The CEBS XBRL taxonomies represent the content of the COREP and FINREP framework defined as templates that were agreed on European level. It does not contain organisational or general information that is often needed for the reporting between the national central banks and the credit institutes as well as investment firms.
In national supervisors have chosen different ways of implementing these information in their reporting. Several supervisors have extended the CEBS taxonomies to integrate those information, others have additional taxonomies or an XML envelope around the XBRL instance.
XBRL International has published the GCD (Global Common Document) taxonomy as Public Working Draft. It covers common information which may typically be required in business reporting but the draft exists since several years and the work seems to have stopped.
XBRL Spain published a first version of a taxonomy for general identification information (DGI Taxonomy) in 2005. This taxonomy is widely used in Spain and Latin America to add administrative data to XBRL instances. This taxonomy is regularly maintained and extended as well as proven by XBRL International. The last publication the version 2.3.2 was published in January 2008.
The DGI Taxonomy provides elements to identify the informing unit and the circumstances that define the context in which the XBRL instance is developed. In comparison to the GCD the DGI Taxonomy is much broader. Further information about the content and the structure of this taxonomy that was presented in the 19th XBRL International Conference in Paris can be found here.
Character codification (UTF-8 or others)
In most of the European countries that adopted the CEBS XBRL taxonomies the encoding UTF-8 is used to report XBRL instances. In a few countries they provide the opportunity to report also in the encoding ISO-8859-15.
The Unicode UTF-8 is a charset defined by the Unicode Consortium to build up all characters that exists world-wide. The most important encodings based on Unicode are UTF-8 and UTF-16 whereas UTF-8 is more used because it needs less space and it is also able to display all Unicode characters.
The differences between those character codification is that ISO-8859-15 include most of the west and middle European characters and also special characters. The ISO code 8859-15 is the ISO code 8859-1 extended by the Euro sign.
The ISO codes are frozen and no longer maintained because they are going to be replaced by a Unicode standard like UTF-8.
One argument to support this old-fashioned charset is that old systems might have problems to process Unicode charsets. A number of Character Set Converters are available for free use, converting from legacy Character Set to UTF-8 before sending the XBRL instance document.
Best Practice: It is recommended to use only "UTF-8" for the CEBS XBRL reporting.
