A vision of XBRL

32px-Flag_of_FranceIn the towers and corridors of Frankfurt and Brussels there is a vision – a vision of a single channel of reporting from the firm all the way through to the European supervisory bodies. Along the way, the relevant data is channelled, aggregated, anonymised and repackaged for the national and European authorities as well as the ECB – for supervisory monitoring, statistical and macro prudential analysis. A reporting entity, be it an insurer or a bank, will send one set of electronic reports to its national supervisor and the system will do the rest. All this without human hands ‘contaminating’ the data along the way. And in real time.

The great enabler for this grand vision is eXtensible Business Reporting Language – XBRL.

Frankfurt 4

This, of course, is but a vision. It will take a while before such an ambitious goal is reached, if it ever is. Yet it is this sort of vision that is driving the XBRL reporting initiative in Europe.

Solvency II XBRL

In the Solvency II world another milestone towards this lofty goal was crossed on 27 March when EIOPA published the taxonomy and Data Point Model for the interim measures reporting.

For now, undertakings are not required to use XBRL, only National Supervisory Authorities (NSAs) and EIOPA (or the EBA and ESMA). However, it is expected that undertakings will see its benefits and in time adopt XBRL for their own use.

Working with the EBA

The banking sector has been trailblazing the XBRL path in Europe. The EBA, through a voluntary group called Eurofiling, has been collaborating on developing a taxonomy for FINREP and COREP reporting for the banking sector for some time. Once XBRL was chosen as the data transfer format for Solvency II, EIOPA joined the group, to increase its coordination work with the EBA (Solvency II Wire, 10 Feb 2012).

“Our first focus is to develop the taxonomy and have it ready at EIOPA level, Patrick Hoedjes, Director of Operations, EIOPA, told Solvency II Wire in an interview. “The second priority is to have the taxonomy in a coordinated way with the EBA. We are in a joint forum with them so we update each other on developments and make sure we are aligned in our taxonomies. We are also aligning ourselves with the ESMA and the LEI project. But up until now we are more observers there.”

The taxonomy architecture of the EBA and EIOPA is now very closely aligned, according to Derek De Brandt, Managing Partner at Aguilonius and Chair of the COREP/FINREP/SOLVENCY II Harmonisation Working Group at XBRL Europe. “The main outstanding area of work, aside from waiting for a political decision on Omnibus II, is standardisation of a component of the XBRL syntax to present tabular views. This work is imminent.”

Working with the ECB

Collaboration is also extending to the ECB. The two organisations have worked closely to reduce duplication in the reporting requirements for insurance undertakings (Solvency II Wire, 22 May 2013). In recent months, the ECB has proactively engaged with the European Supervisory Authorities about both its reporting requirements and data delivery formats.

Frankfurt 8The ECB uses Statistical Data and Metadata eXchange (SDMX) for its internal data collection and analysis. Both XBRL and SDMX are XML based but there are key differences in the structure of the data, born out of each format’s purpose. SDMX is especially suited for statistical data delivery, that is, relatively smaller data sets with a high recurring frequency. In contrast XBRL was designed to deliver detailed granular information.

“Despite these differences it could be possible to make the standards work very closely or even connect directly,” Michal Piechocki, CEO of BR-AG, said. An example of such a connection on the business layer has already been created – the BSI-MIR (Balance Sheet and Interest Rates Statistics) XBRL taxonomy is closely aligned to the SDMX respective coding.

A number of possible solutions could be used to exchange information between XBRL and SDMX. “Facilitating information transfer would require reconciling between the business definitions and a connection on the IT layer. Both of these are achievable,” Mr Piechocki said.

Mr Hoedjes believes that the take-up of XBRL may be expedited by the convergence of banking supervision across the EU. “We also have to see what will be the impact of the banking union or the Single Supervisory Mechanism taking place in the ECB. It will probably use the information collected by the EBA, implying that XBRL would be introduced at the ECB, which I think would be a good development.”

EIOPA 3

“I could envisage the Single Supervisory Mechanism will use XBRL, meaning that de facto it would be coming into the systems of the ECB, increasing the possibilities of further synergies of system development between the European Supervisory Institutions.”

EIOPA Taxonomy in detail

The EIOPA taxonomy is at an advanced stage and EIOPA plans to release both the full Solvency II taxonomy and a subset for the interim measures when the final draft of the Guidelines is published in the autumn. “The preparatory taxonomy will be a subset of the final taxonomy because we don’t want divergence between the two. There could be some divergence depending on the shape of the final Solvency II reporting package but it shouldn’t be a different set,” Mr Hoedjes said.
Producing the full taxonomy is also consistent with EIOPA’s aim of using the interim measures as a preparation phase for the final rules. “We specifically want to publish both taxonomies because we also want to give industry the option to have a ‘one go’ implementation even if they only have to report part of it,” Mr Hoedjes added.

XBRL (tool) for the masses

Although XBRL reporting is not currently mandatory for undertakings, EIOPA is keen to promote the use of its taxonomy and XBRL in general. “We want to use the preparatory phase as an opportunity for companies and supervisory authorities to prepare, but also as a way to gradually introduce XBRL and our taxonomy in the real world,” Mr Hoedjes said.

To that end EIOPA plans to release an XBRL reporting tool for undertakings by the end of the year. The tool, which is designed for small and medium size undertakings and NSAs, will help to generate XBRL instances. Mr Hoedjes was keen to stress that it was not meant to replace market solutions, but simply to help smooth the take up of XBRL.

The development of the XBRL tool is indicative of what some believe is a major challenge facing EIOPA, and to an extent the EBA, in ensuring successful take up of XBRL by NSAs and market participants.

According to Anne Leslie-Bini, Head of International Development at Invoke, it is important for EIOPA to achieve a critical mass in the take up of XBRL across Europe. “EIOPA has a key role to play in encouraging harmonized implementation of Solvency II across countries, and this includes encouraging as many national supervisors and regulated firms as possible to adopt XBRL. The EIOPA XBRL tool is a gesture to the market to help make that process easier.”

Ms Leslie-Bini believes that much of the successful adoption of XBRL will depend on the approach taken by national supervisors. “We are seeing some countries such as France and The Netherlands where interest from supervisors has been substantial and the supervisor is proactively pushing the use of the standard. In other countries, the market has been left to its own devices to find appropriate solutions.”

Lukewarm adoption across the pond

XBRL is not without its critics. The enthusiasm of European agencies may, in part, be due to the lukewarm reception XBRL received in the United States where it has been used both by the Securities and Exchange Commission (SEC) and the Federal Deposit Insurance Corporation (FDIC).

Frankfurt 6The SEC introduced mandatory XBRL reporting of financial statement information in 2009; a voluntary programme has been running since 2005. The usefulness of XBRL data for investors and analysts has been questioned in a recent study by academics at The Center for Excellence in Accounting and Security Analysis (CEASA) at Columbia Business School.

In the study, An Evaluation of the Current State and Future of XBRL and Interactive Data for Investors and Analysts, Trevor Harris and Suzanne Morsfield argue that, in the SEC experience, “XBRL has promised more than it has delivered” so far, and is at risk of becoming obsolete for most analysts and investors unless their concerns are addressed.

While the authors argue that the initiative has succeeded in providing freely available information of the reported data, they express “numerous reservations” about its future unless stakeholders improve the usability and data quality. Questions are also raised about the simplicity and stability of the taxonomy and a lack of user tools to help make the most of the data.

For XBRL to succeed the researchers conclude that in addition to reducing the error rate, “XBRL technology development needs to be taken over and run by technologists, rather than accountants and regulators.”

The SEC experience is in sharp contrast to that of other US agencies. In 2005 the FDIC, together with the Office of the Comptroller of the Currency, and the Federal Reserve System introduced XBRL reporting for regulatory reporting, which went almost unnoticed.

According to a 2006 report by the agencies, the introduction of XBRL resulted in a marked improvement in the quality and timeliness of the reported data. Data cleanliness improved from 66% to 95%, and 100% of data received met mathematical requirements, as opposed to 70% prior to introducing XBRL. Data accesses and inflows also increased significantly and staff productivity increased, allowing staff to handle between 10%-33% more cases.

Frankfurt 7

These figures are impressive both in scope and the speed in which they took effect. Alan Deaton, Acting Associate Director, Statistics Branch, FDIC Division of Insurance and Research, confirmed these metrics were still applicable today. “XBRL played a significant role in the data quality and accuracy improvement by supporting changes in our business processes and the flow of information between the regulators and the filing entities,” he added.

It’s all about the end users

A significant difference between the SEC and FDIC experiences is their respective target audience and proposed use. The SEC reporting is intended for a wide range of market participants while the FDIC reporting is designed for a narrowly defined regulatory audience. The latter is much closer to the European scenario.

Despite these differences there are important lessons for Europe. Suzanne Morsfield, co-author of the CEASA report, told Solvency II Wire, ”One of the key lessons from the SEC filing experience has been the need to understand as much as possible how end users will use the data.”

It was also important to get the right balance between the accounting and technology people, she said. “It is vital to get the best thinking around the table and make sure neither party dominates the process.”

Frankfurt 5

Alternatives to XBRL

XBRL is not the only game in town. There are other data exchange formats as well as innovations in the related fields, such as big data analytics and web ontologies, that may be applicable.

According to Ms Morsfield, deciding to use XBRL in a regulatory or other setting, as opposed to simpler solutions for structuring data and making it machine readable and interactive, should be done carefully. “Regulators should not assume XBRL is always the only or best solution for this end goal. In our view machine readable structured data should be provided to regulators. The question remains what is the best format for the data transfer.”

EIOPA recognises the limitations of XBRL. As Mr Hoedjes explained, “From a consumer of information point of view, XBRL by itself has not solved the long lasting concerns of semantics, quality, granularity and comparability of available data. Properly addressing these concerns was considered key in the supervisor’s minds even before we selected XBRL as a building block on which to implement our supervisory reporting framework.”

The grand vision and you

So what of the grand vision of a single channel of reporting? Much like Solvency II did for risk management, it has propelled the discussion on data transfer formats and has become a catalyst for developing thinking about machine readable structured data. And much like Solvency II, its fate remains unknown.

For now firms should take note that the vision is alive and well. “Once Solvency II is in place, the idea is that EIOPA will issue guidelines on the use of XBRL by undertakings,” Mr Hoedjes said. “While the decision ultimately remains at the national level they still have to respond on a comply-or-explain basis.”

European Parliament 1

Related posts:

  1 comment for “A vision of XBRL

  1. Catalin Lungu
    April 26, 2015 at 21:42

    All below is my opinion, my assumptions, my suppositions, my thoughts:
    In fact, what is the real added value of xbrl or xml alike data reporting comparing to old style (i.e. various tabular formats uploaded “as they were” to the supervisor)? Here’s my humble answer: validation layers together with achieving a high reporting efficiency (single return). Yes, I think xml/xbrl brings more benefits to the equation if everything is done right, which means those simple conditions achieved: all the stakeholders to do their job right and to be fully aware of the requirements. That’s why I think a succesful outcome on this matter can only be achieved through a “close relationship” between the IT and business units.
    As some claimed in the above article, there might be issues with data quality. So, where can the chain break, when and how could it be possible?
    Let’s review a bit the hypothesis and assume (purely hypothetical) we have the following market reporting conditions:
    1) reporting entities have to submit a set of templates in the xbrl format and they have to comply with technical specs and data checks, all specified in the legal framework (let’s say, very similar to annex II, VI, and the other annexes from the S2 preparatory SoI guidelines);
    2) there are multiple xbrl reporting software solutions/providers available;
    3) legal framework defines all the filling rules, technical and business validations but it doesn’t state anything about the entities’ obligation to deliver the xbrl instances accordingly to a given taxonomy;
    4) the regulator develops its own xbrl taxonomy which includes all the layers of validations as specified in the legal framework as well as an IT infrustructure to import, view and validate the input from the market participants;
    5) the supervised entities develop locally/buy from providers aswell an it xbrl reporting solution and a taxonomy having all the required validations included. This way they can create, modify, view, validate and finally export the xbrl instances.
    All the chain links seems to be fitted properly. Undertakings are creating the xbrl instances, they validate it locally and if green light, they upload them to the regulators’s xbrl reporting framework. Next step, we have two situations:
    – the user waits from green light from regulator who validates the instance too: if green, user is happy, red means retry (failed the taxonomy validation);
    – the regulator checks the instance by itself and if any problems (red light) it rejects the package and let the user know.
    And, again, the process is restarted.
    So, again, WHERE can this chain break?And WHY, HOW can be possible?
    Maybe the answer could be related to the internal IT algoritms and specific procedures underlying the developed taxonomies, both at regulator and entity level. This way irregularities and errors in reporting&validation could prove material for the session. Plus, even if the legal framework did provide a taxonomy, how could we be sure it was implemented properly by the local (entity level) IT departments? Add to the mix that business units may have not been able to provide accurate figures, we may be facing a material exposure to operational risk. Also, since the reporting xbrl solution is not standarlised, multiple products can deliver errors aswell and again, uploading/importing the instances at regulator’ s can be difficult.
    The very important task is that the filling rules together with technical/business validations is crucial to be brought together by a single taxonomy which all the xbrl solutions (including regulator’s) on the market should append to. This brings us one step closer to error-free.
    Luckily for the preparatory phase, Eiopa’s delivered also the taxonomy which diminishes this kind of risk but is it enough? If agreement at management/local level to report in xbrl for preparatory phase, did those jurisdictions formally let their entities know to report according to Eiopa’s taxonomy validations?If yes, did they also let them know which version to use? Do those jurisdictions have proper IT xbrl reporting solutions in place&ready?
    Again, in the case the reporting legal obligation is not limited to xbrl, material errors could arise due to the lack of internal business expertise and internal validation systems against the given technical specifications (point 3 above) and again, we come back to the supporting IT procedures&software. Plus, in this case, validation could prove difficult at the regulator’s level since it has to be done manually by the off-site experts, in the absence of the xbrl stream.
    Will the industry/supervisors manage to overcome all material Pillar 3 related milestones in due time? I guess we’ll find out soon enough since the reporting deadlines are closing in fast. Not to mention we have also Eurozone and outside-Eurozone, ECB, ESRB, financial stability, public disclosure, 3CB and statistical purposes incoming reporting requirements.
    Since this article is also about harmonisation EU wide, I would also like to take this oportunity and mention, although it’s a bit offtopic, I know and i apologize, that harmonisation&disclosure could also lead to various benefits, of which one can be a EU level disclosure of all the risks impacting at entity level – an European Risk Register, publically available and updated regularly in terms of risks and also developed modelling methodologies for each of the risks, if agreed by all the stakeholders. What i’m thinking of is way beyond capital requirements, a real … source of intel for the risk managers and overall, a true harmonisation of the risk management process.

    Catalin Lungu
    Bucharest,Romania

Leave a Reply

Your email address will not be published. Required fields are marked *

64 + = 71