Best Practices on Data Definitions

From XBRLWiki

Revision as of 08:36, 2 March 2009; Katrin (Talk | contribs)
(diff) ←Older revision | Current revision | Newer revision→ (diff)
Jump to: navigation, search

Image:Corep_finrep_logo.gif

Contribution dated 2009-01-14

ALL TOPICS ARE STILL ON DISCUSSION!

Contents

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

Currency conversion

The conversion rates between currencies should be reported with up to six significant digits (decimals="6"), following the standard on Euro conversion rule for irrevocable rates.

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


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:

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

"Monetary Financial Institutions" (MFIs) are central banks, resident credit institutions as defined in Community law, and other resident financial institutions 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 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.

Most of the reporting entities in Europe have a MFI ID code but there are also several institutions that have to report their solvency data but they are not to be categorised as MFI, f.e. holding companies or asset management companies. It would be useful for an harmonised reporting to have an unique identifier in Europe also for those companies. The ECB intends to regularly update and publish a "List of Investment Funds" and a "List of Financial Vehicle Corporations" from mid/late-2009 onwards. These lists could help to close the gab of missing id codes.

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

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 Image:DDB_coo.jpg

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

Overview of the Best Practice agreements

Precision and decimal attributes ---
Threshold/tolerance margin ---
Nil, null, zero and blank values ---
Non-numeric items: definition and values ---
Reporting institution identification ---
Report type (Solo, Consolidated, other options) ---
ID and tagging of cells and (sub)totals ---
Administrative data and feedback parameters ---
Character codification (UTF-8 or others) It is recommended to use only "UTF-8" for the CEBS XBRL reporting.
Retrieved from "http://xbrlwiki.info/index.php?title=Best_Practices_on_Data_Definitions"
Personal tools