Deutsche Bank’s response to the European Banking Authority’s Consultation Paper on the XBRL Taxonomy related to the EBA final draft Implementing Technical Standards on Supervisory Reporting Requirements (EBA/CP/2013/36)
Deutsche Bank (DB) welcomes the opportunity to comment on the EBA’s consultation paper on the XBRL Taxonomy for supervisory reporting requirements.
We appreciate the use of XBRL for FinRep/CoRep submissions and we would support the usage of XBRL by all National Supervisory Authorities.
The well-known standard has many benefits as a unique reporting format in Europe and abroad. The newly introduced Table Linkbase Specification 1.0 in particular adds more value to XBRL as an electronic way to express forms and data. We are also pleased that the EBA and the EIOPA are working together on similar technical bases. We would urge all the European NSAs to also make use of the XBRL taxonomy, and for any new reporting framework in the EU to adopt the same XBRL technology.
However, during our tests with the EBA taxonomy we have discovered a few technical challenges. In the comments below we address all aspects which we believe need to be resolved for the XBRL Taxonomy to be properly functional and to ensure a successful implementation of a reporting system.
Yours sincerely,
Andrew Procter
Global Head of Compliance, Government and
Regulatory Affairs
Further comments:
Geographical Area
We note that, as currently designed, in the “Geographical Area” hierarchy all countries appear as a sub-category of “Albania.” Please see Image 1 in the attached Annex.
General XBRL Taxonomy Architecture
The table Linkbase specification is still not final, and is subject to frequent on going changes. We strongly support its use, but we need time to implement the latest specification changes into our software. We request that the EBA do not mandate banks to file before the Table Linkbase Specification is in a final state.
Additionally, we have concerns about the fact that the Table Linkbase makes heavy usage of XPath 2.0 expressions, due to its use of the XBRL Formula Linkbase Variable Specification. Whilst this provides for an easy way to render XBRL instance documents, it becomes very complicated if the table view is used for data entry, which is clearly defined as a use case within the specification. We request that the EBA do not rely too heavily on XPath expressions to enable the use of the Table Linkbase without having an XML instance document in place. We will provide further input on this topic to the XBRL Table Linkbase working group. The same is true for the Formula Linkbase validation rules, see our comments below.
In general, we appreciate a XBRL taxonomy package with multiple entry-points. During our FINREP projects, we found that the currently used local caching, usually leads to deployment problems. The rewrite options that are added to the taxonomy package can solve this, but not for a single entry point. Furthermore, having all these files online, would lead to a massive file downloading during XBRL DTS resolving process. To resolve this, we suggest not to make use of taxonomy/schema references pointing to online resources (or at least minimise this), and instead use locally referenced files, where this is not already the case.
We would also support a more detailed general description and/or recommendation about the XBRL taxonomy and instance document architecture. This is in line with the documents provided by the CEN/WS working group of the Eurofiling initiative.
Data Point Model and XBRL Taxonomy
The table ID that is used to identify a FINREP/COREP table with the XBRL Role URI, is very important for many scenarios. It allows us to map certain data to a table identified by the table ID. Our experience with the previous taxonomies is that it is extremely important not to continually change the table IDs. We request that the EBA provide a unique, stable, table ID, and a proper versioning of the tables for future taxonomies that are not completely changed tables; this would be very helpful.
In this section we also saw tables which are divided into different parts (these can be identified by an appendix, e.g. “F_08.01.a” or “F_08.01.b”). These tables were defined as single tables in previous Excel reports of the table views, which could create confusion for business users, who expect the same table view whether in the Excel report or the XBRL taxonomy.
Furthermore we request that table sizes be limited to a maximum of 1000 value cells; otherwise viewing, editing and printing the tables can be complicated.
Validation of Table Values
The FINREP/COREP taxonomy includes a XBRL Formula Linkbase with many value assertions. In general, we appreciate the use of existing XBRL specifications, but the Formula Linkbase assertions are a massive and complex way to express that cell value “c = a + b”.
We are not convinced that it is optimal to ship an Excel workbook containing all formulas in a simple grammar additionally to the taxonomy. Instead we managed to develop a very small expression parser that can parse these kinds of formulas, and validate them on the table model object that is generated by the XBRL processing engine. We would be happy to discuss this with you in more detail.
Another disadvantage of the Formula Linkbase for validation purpose is the missing link of the table cells generated according to the Table Linkbase Specification and the formula variables. In our view a good software tool should display the validation results directly attached to a cell, and not as a flat list that is available for the whole filing. This currently seems quite complex to achieve. Please see in Image 2 in the attached Annex a screenshot of our custom developed validation engine that is processed on the normal XBRL Table Linkbase model object. This solution is also used for custom validations, which can be easily set up by our business users.
Following this, we would be appreciative if the EBA could add the Excel validation file as a regular extension to the taxonomy for future releases, and think about a further integration of table value cell validations.
Open “Typed Dimension” Tables
The use of typed dimensions within the taxonomy seems reasonable and necessary for a certain tables. However, we recommend the use of these be limited as follows: Please avoid “nested XML typed dimension values” (XML complex schema types) as typed dimension values. This is well defined by the XBRL specification, but it makes it complex to identify a certain table line. The uses of simple types for typed dimension values will ease the mapping process for these tables.
Additionally, we request that the EBA avoid multiple typed dimension filters (Formula Dimension Filters) per axis, in order to keep its use limited and easy.
