February 2, 2015 – By Deepak Aravindan, Implementation Architect
De Nederlandsche Bank (DNB) was one of a number of regulators that decided not to use XBRL when it implemented the European Banking Authority’s (EBA) Common Reporting (COREP) and Financial Reporting (FINREP) requirements last year. However, the DNB has indicated this is going to change, and Dutch banks now face important decisions about how they will adopt XBRL.
The beginning of XBRL reporting in many European countries last year marked a major change for banks: having previously used XML and other long-established formats, they had to quickly get their heads around three-dimensional taxonomies with embedded validation rules. Dutch banks that are now embarking on the same journey can learn a lot from the experiences of their counterparts in other countries.
I have worked on a number of XBRL projects in recent years and believe there are five important questions that banks in the Netherlands (or any other country, for that matter) should consider when adopting XBRL:
- Does your reporting solution support XBRL natively?
Many banks have struggled with COREP and FINREP reporting because XBRL functionality does not sit at the heart of their reporting tool; instead it has been bolted on as an additional component. If XBRL is not fully embedded in your reporting solution, it increases the likelihood of integration errors, reduces performance and leads to higher costs.
Performance is a particularly important consideration as the remittance periods for some EBA reports are being slashed. If the DNB chooses to mandate XBRL not only for COREP and FINREP, but also for Liquidity Coverage Ratio (LCR) and Net Stable Funding Ratio (NSFR) reporting, banks could be required to produce these reports on a daily basis (see my colleague Ed’s blog post on this topic ). This will be impossible unless they use a solution that offers native support for XBRL.
- How quickly can your reporting solution adapt to change?
Banks should not only consider their reporting solution’s business-as-usual performance, but also its ability to adapt quickly to changing requirements.
The EBA continually releases new versions of its XBRL taxonomy (the industry is already using version 2.2, and expects 2.3 imminently). Banks need to assess whether they have the vendor support (or internal resources) they need to manage these ongoing taxonomy changes.
The process of implementing taxonomy changes is made unnecessarily complicated if you use a solution that is composed of separate reporting and submission layers. Those who choose such a solution will find the individual layers must be updated separately, requiring more time and increasing the likelihood of errors. These issues can be avoided by using a solution with embedded XBRL functionality.
- Can you access previous versions of the EBA’s XBRL taxonomy?
In addition to adopting the latest iterations of the taxonomy, banks must retain access to the earlier versions because, when they are asked to resubmit a report, they must do so using the taxonomy version that was current on the date the report was originally submitted. A bank’s chosen platform should support this versioning natively.
- Is your reporting solution flexible and scalable?
The use of XBRL is gaining popularity beyond EBA reporting. As my colleague Bahar explained in this blog post, Banco de España is extending its use of the FINREP XBRL taxonomy to include domestic reporting requirements. As a result, when choosing a reporting tool, banks need to consider whether it offers the flexibility and scalability to support new, as-yet-unknown XBRL reporting requirements.
- Does your reporting solution support both XBRL and non-XBRL formats?
The DNB is yet to confirm the timetable for its migration to XBRL. The best way for banks to ensure a smooth transition from the incumbent XML reports to the new XBRL ones is by using a solution that supports both formats from the same taxonomy.
Even when the DNB switches to XBRL, it is likely to mandate validations that are not contained within the standard. Therefore banks must ensure their chosen reporting solution supports not only the validation rules that are embedded in the XBRL, but also any other rules the regulator defines.
The combination of XBRL and non-XBRL functionality is also important because local regulators (including the DNB) are increasingly querying discrepancies between EBA reports and those submitted as part of domestic requirements. There is now a strong possibility that validations between EBA (XBRL) and local (non-XBRL) reports will become mandatory. In order to manage these validations efficiently, banks will need a solution that supports multiple formats.
The adoption of XBRL has been a steep learning curve for some banks. By asking themselves the above questions, banks in the Netherlands can make the process easier for themselves.
For more information about XBRL, see this AxiomSL white paper on the subject:
AxiomSL XBRL Solution White Paper
To discuss this article further, please contact:email@example.com
COREP/FINREP reporting – CRD IV
AxiomSL assists firms in addressing all of the reporting challenges posed by the CRD IV (COREP, FINREP, LCR, LE, LR, NSFR) framework and XBRL taxonomy. Our robust data-driven solution operates from a single platform… To read more, click here.