Best Practices on Data Definitions
From XBRLWiki
(diff) ←Older revision | Current revision | Newer revision→ (diff)
Contribution dated 2009-01-14
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".
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%).
