Best Practices on Data Definitions

From XBRLWiki

(Difference between revisions)

Revision as of 13:42, 21 January 2009

Contribution dated 2009-01-14

ALL TOPICS ARE STILL ON DISCUSSION!

Introdruction

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 recent questionnaire , answered by most of the EU supervisors, shows the need for further harmonisation of IT details.

The XBRL Network Working Group 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 XBRL 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, Scale, 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 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:

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.

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

Scale

Concepts with monetaryItemType (or types derived from this type) should be reported with attribute decimals = "2", so no scaling is allowed, implying that all figures will be reported in cents as follows 1755.89, which equals 1755.89 Euro, or 1755 Euro and 89 Cents. Percentages should be rounded to four decimals.

Percentages

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

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.

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

Non numeric elements: definition and values

Reporting institution identification

The "Institution 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. The MFI ID code is unique to each institution listed in the List of MFIs. Each national central bank of the EU is responsible for allocating an unique MFI ID code for every MFI, resident in their territory. Concerning the convention for the MFI ID code, this has been set by the ECB in agreement with the NCBs. The convention is as follows: the MFI ID code can be alphanumerical, with the first two digits being the two-digit ISO code for the country of residence of the MFI and the remaining number of digits (no limit has been specified) can be any combination of alphanumerical characters.

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.

ID and tagging of cells and (sub)totals

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 13th XBRL International Conference in Madrid 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 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 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 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.

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