XBRL accounting taxonomy design and categorisation – Part 3: Coherence

In this series of articles, we propose a categorisation of taxonomies based on different aspects of their design.  Using this categorisation we look at the evolution of taxonomy design through three generations.

What is taxonomy coherence?

Our dictionary provides two definitions for ‘coherence’: the quality of being logical and consistent; and the quality of forming a unified whole. Both should apply to the architecture and design of XBRL taxonomies.

We said in the introductory article of this series that by coherent we meant a taxonomy that “hangs together” to produce consistent and comparable instance documents. That’s actually extending the concept beyond the taxonomy itself to the instance documents that can be created with it, but if we can’t guarantee to produce documents with those qualities then what’s the point of a coherent taxonomy?

Hypercubes and dimensions

One useful way of comparing the coherence of taxonomies is demonstrated by the graph below, which plots dimensions per hypercube for each of the three taxonomies we are examining (note that both scales are logarithmic):

The number of dimensions per hypercube is a good measure of how extensively the taxonomy uses dimensional data modelling to provide a unified data model focused around the relationship between concepts and the data aspects that apply to them.

The difference between US GAAP (green) and IFRS (red) is simply one of magnitude – the US GAAP taxonomy (345 hypercubes, 272 unique dimensions) is approximately three times larger than the IFRS taxonomy (112 hypercubes, 113 unique dimensions). However their ‘dimensions per hypercube’ profiles are very similar, starting at a peak with one-dimensional hypercubes and diminishing quickly as the number of dimensions increases. There is a large majority (70%+) of hypercubes with one and two dimensions in both taxonomies.

The profile for UK FRS (purple) is strikingly different. There is just one hypercube with one dimension, and only ten hypercubes with two dimensions. This suggests a radically different approach to the design of the taxonomy (212 hypercubes, 115 unique dimensions) and in particular the use of hypercubes to represent highly-dimensional data.

The graph implies that, for US GAAP and IFRS, most concepts have been modelled in isolation with a small number of specialised dimensions. In contrast, the UK FRS taxonomy has been modelled comprehensively as a whole, with widely applicable dimensions being applied across numerous relevant concepts.

We will now explore in more detail the reasons behind the differences between the taxonomies.

The IFRS taxonomy

We’ve already seen that the architectural underpinnings of the IFRS taxonomy are derived from the International Financial Reporting Standards themselves.

The chief consequence of this on the design of the IFRS taxonomy is that users of it are at liberty to interpret the framework it provides very broadly. This can be to the detriment of instance document consistency and comparability.

The IFRS taxonomy is intended to act as a foundation for electronic reporting regimes in IFRS-using jurisdictions around the world. The primary ‘users’ of the taxonomy in this case are most likely taxonomy architects tasked with creating extended versions of the IFRS taxonomy suitable for local reporting purposes. This means that there is a considerable effort required on the part of the extension architects to implement a level of consistency on top of the IFRS taxonomy itself.

This “standards-first” approach shows itself in that the IFRS taxonomy has the lowest average number of dimensions per hypercube of the three taxonomies we’re examining, at just under two. This is surely the result of attempting to model the low-dimension, presentation-oriented tables commonly seen in standards documents and in the corresponding financial reports. The taxonomy also has dimensions not associated with any hypercube; and some reportable concepts are not associated with any hypercube.

By way of a small but illustrative example, consider the IFRS Earnings per share hypercube (table) which has six separate primary items and a single dimension.

Primary items:

• Basic and Diluted earnings (loss) per share from continuing operations (2 items)

 • Basic and Diluted earnings (loss) per share from discontinued operations (2 items)

• Totals for both Basic and Diluted earnings (loss) per share (2 items)


• Classes of Ordinary Shares

There is also a “floating” dimension (axis) not associated with any hypercube – Continuing and discontinued operations – for breaking down continuing versus discontinued operations, which wasn’t utilized in the Earnings per share hypercube. Had it been, the number of Earnings per share primary items in the structure could have been reduced from six to two (Basic and Diluted earnings concepts for each of continuing, discontinued and (default) total dimension members). This demonstrates that, if a data-centric approach had been taken to model the taxonomy, it would have simplified and improved its coherence.

In summary, the IFRS taxonomy is not as coherent as it might be, and that impacts the consistency and comparability of instance documents created to adhere to it.

The IFRS taxonomy

The US GAAP taxonomy is nearly three times the size of the IFRS taxonomy in nearly all respects, but it associates all dimensions with hypercubes, even if around one third of all reportable concepts are not associated with any hypercube. This is an approach with greater consistency than that of the IFRS taxonomy, dimensionally-speaking, even though it provides far too many degrees of freedom to instance document preparers when it comes to these “free” reportable concepts, leading to documents that may not be entirely consistent with each other or wholly comparable.

Interestingly, however, it is on a par with the IFRS taxonomy in one important respect: the average number of dimensions per hypercube is only slightly larger, at just over two. This suggests that the hypercubes (or tables in US vernacular) in the taxonomy are primarily modelling the kinds of two-dimensional tabular presentations (for human consumption!) that one might see in a financial report or defined in an accounting standard (e.g. an axis of ‘concepts’ plus one or two dimensional breakdowns).

The “document-centric” approach of US GAAP therefore tends to produce a taxonomy design that yields data structures that tend to represent the conventional tabular presentations prescribed or presented as exemplars in standards documents and in common usage by preparers of financial statements.

The rigorous architectural underpinnings of the US GAAP taxonomy have resulted in a coherent taxonomy design, although one that does not lend itself to ensuring similar consistency in instance documents, particularly due to the usage of filer taxonomy extensions, as we will discuss in a forthcoming blog.

The UK FRS taxonomy

The average number of dimensions per hypercube in the UK FRS taxonomy is much higher than either IFRS or US GAAP at just over eight. This is a key indicator of a radically different architectural approach in which data modelling has taken centre-stage. As if to emphasise this, all reportable concepts belong to a hypercube, which is a very strong indicator from the taxonomy’s architect to instance document preparers of what is expected of them. There is a coherent dimensional framework in which each and every reportable concept unambiguously sits.

The result is a collection of highly-dimensional hypercubes tightly bound to reportable concepts. With judicious use of dimensions with default members, in the main, the “tagging” task for any given reportable concept is not onerous, but at the same time the full expressive power of the hypercubes can be brought to bear when the need arises. Reportable concepts are only valid in certain well-defined circumstances, and those hypercubes have been equipped with all the necessary dimensions, whether they are actually needed in any given circumstance or not.

The UK FRS taxonomy design is based on a thorough analysis of the data that is required to be conveyed by financial statements. This results in a more coherent data model since all the potential aspects (or “dimensions”) of an item of data can be considered holistically and independently of any traditional or prescribed presentation requirements. In this approach, the typical presentations’ one- and two-dimensional hypercubes (tables) tend to be represented by one- and two-dimensional “slices” through higher-dimensional structures, and there is little or no need for preparers to expand the existing hypercubes – something that can only be achieved via entity-specific taxonomy extensions.

The coherence of the taxonomy naturally assures the consistency and comparability of instance documents. It is a consequence of the taxonomy’s design that places no unreasonable demands on the ingenuity of taxonomy extenders or instance document preparers.


We have seen how the different choices in taxonomy design have influenced the coherence of the taxonomies under study and how this is illustrated by the dimension-per-hypercube metric.

In general, a coherent taxonomy should have a complete, consistent data model with full hypercube coverage, broadly-applicable dimensions and no unnecessary duplication either for dimensions or concepts. We have seen that these goals are most readily achieved by taking a data-model-first approach to taxonomy design. A coherent taxonomy leads to clear, unambiguous tagging and therefore clear, comparable instance documents with less opportunity for error.

If a taxonomy has a less extensive dimensional model, this requires extenders and/or instance document preparers to provide more interpretation of the taxonomy and to work significantly harder to produce consistent, comparable instance documents. This is by no means impossible, but some of the burden has been transferred from the taxonomy authors to taxonomy extenders and/or instance document preparers, who are less able to produce coherent, comparable data if they’re not equipped with the tools to do so.

In the next blog post we’ll cover taxonomy extensibility.

Filing Rules – the good stuff

CoreFiling’s Katherine Haigh and Joe Leeman are active contributors to XII’s Filing Rules Working Group. In this interview, we find out what motivated them and what insights they’ve gained that are useful either to regulators, filers or both.

Why did you join the Filing Rules Working Group?

Katherine: Part of my responsibility as Head of Quality Assurance is to check filing rules and filing manuals for our clients, so I have a good understanding of the things that work and the things that don’t. Any contribution we can make to improve the consistency and quality of filing rules not only benefits the market, but helps me in my job!

What does the Working Group do?

Joe: We’re analysing several filing manuals from a broad range of organisations in order to understand the current market practice. This work gives us a good insight into both the structure of filing manuals and also the content, the sort of rules that get included and how they are described.

Katherine: In addition, we’re looking for evidence and opportunities to automate the processing of filing rules as much as possible.

That’s interesting Katherine, what’s the reason for that?

Katherine: So, well-structured filing manuals and well-written filing rules lend themselves to automatic testing of reports and submissions. Having these processes automated not only builds consistency, it reduces the manual effort required by report preparers by giving them the opportunity to automatically test their reports prior to submission. It increases the level of first-time correct filings, reducing the workload on the regulator’s incoming processes.

Joe: Here at CoreFiling we offer validation modules to our customers that provide exactly that service – it’s much easier to write these and keep them current if we’re relying on well-structured manuals and well-composed filing rules. As Katherine said, this service enhances the reports preparation and submissions processes for our filer customers. In some cases, we provide the same automated validation software to both the regulator and their filers, meaning the filers can have 100% confidence of the validity of each report before submitting.

What other insights have you got from this work?

Joe: Interestingly, we’ve found a few anomalies that are potentially embarrassing for regulators and publishers of filing manuals!

Can you give some examples?

Katherine: Yes, we’ve seen examples where a regulator has clearly just copied content from another filing manual with no understanding of what the rule is supposed to achieve. It’s simply a copy-paste exercise. This is bad for the filer community, since it imposes an unnecessary constraint on their report, adding to the cost and effort, but adding no value to the filer or to the regulator.

Another example occurs in the Eurofiling space, where the supra-national regulator imposes a set of “should” rules in their filing manual. These rules might be, for example, to capture some useful statistical information that is not essential to the regulator. The National Competent Authority (NCA) then increases the severity of this rule to a “must” rule. All the organisations filing to that NCA are then required to submit the requested information in their reports or suffer having their report rejected.

As above, this process adds more effort and cost to the filers without creating any benefit to either filer or reporter. Though the supra-national regulator does always get the extra information they want.

So, there are definitely issues with current practice in filing manuals. Is it all bad?

Joe: Fortunately, no, it’s not all bad. We’ve seen some examples of great practice that, to be frank, should be adopted by all publishers of filing manuals. For example, those manuals that include a description of the goals, objectives and context for the filing rules are far easier to interpret and comply with. Rules that are properly arranged in a logical structure are also much easier to implement. For example, EBA categorise their rules into 5 classifications: filing syntax, instance syntax, context-related, fact-related and other. By doing this they allow the filer to see immediately where each rule should be applied.

Other examples are to have a consistent numbering system. Again, the EBA chooses a particular numbering system for its rules. Some NCAs just copy this numbering scheme, which we would support. Others choose to create a completely new numbering scheme, which adds to confusion and makes it difficult to compare rules and very difficult to automate them.

Katherine: We’d also strongly support the approach of differentiating the XBRL validation rules away from the guidance rules and rules relating to constraints in the submissions portal. This goes along with the idea that XBRL validation rules can easily be automated in the filing process. Guidance rules are more difficult, in that they can be difficult to resolve into clear “pass – fail” expressions. By separating out the constraints imposed by the submissions portal, it prevents some of the copy-paste rules being carried over unnecessarily.

Joe: And while we’re on the topic of good practice, I’d like to see proper versioning in filing manuals so it’s obvious what has changed when a new version of a filing manual is published. Ideally we’d see a consistent identification scheme where each rule is assigned a unique reference, whether a number or an error code, for life. This makes for ease in version control and change management.

In summary then, what guidance can you give to publishers of filing manuals and to the communities of filers that need to comply with the rules?

Katherine: I think for the publishers there are two key messages: firstly, to treat the creation of filing rules with the same rigour that is applied to taxonomy development and publication. The second is to walk a mile in the filer’s shoes, to better understand the limitations, confusion and wasted effort that occur when irrelevant or over-severe rules regimes are applied.

Joe: And for the filer community, it’s not to be complacent. Filers should require their regulators and authorities to provide clear unambiguous filing manuals containing only the rules required to assure successful submission and no more. Also to participate in reviews of any draft manuals published by the regulators, to question any rules that are not clear, and to put the onus on the regulator to explain the need for any specific rules to be applied.

Thanks for the insight, Katherine and Joe – I’m sure that is useful information for publishers and consumers of filing manuals. What’s next for you two?

Katherine: We still have some more filing manuals to review, and a recommendations and guidance paper to publish, hopefully in time for the Data Amplified Conference in November.

Joe: I’d really like to use the insights we have gained in this exercise to help publishers of filing manuals improve their practices and processes in filing rules. I can see the benefit that would bring to the publisher and, as importantly, to their filing community.

Announced: Seahorse® is the T4U Successor

After the recent EIOPA announcement that the XBRL reporting tool T4U will be decommissioned next month, many filers are now looking for a quick solution to keep their submissions compliant.

At CoreFiling, it’s our business to keep you compliant – that’s why we are proud to announce that we are offering a free trial to our cloud-based regulatory filing platform, Seahorse®. The successor to T4U.

This free trial gives you the opportunity to create one complete filing to submit to a regulator – and even better, users will have three months to explore the software before submitting their filing. Here are just some of the ways in which Seahorse® can help your organisation:

The Benefits

  • Seahorse® lets you create fast, error-free XBRL filings. Unlike T4U, its data rendering is XBRL-based, so the reports you send will never have data conversion errors or approximations. The data is 100% accurate every time.
  • Seahorse® is hosted in the cloud. Its architecture lets you update taxonomies instantly, with no tedious installations. You can create and view your filings anywhere, any time.
  • Seahorse® allows you to easily create XBRL filings in the familiar environment of Microsoft Excel.

How do I sign up?

Trial access is available to anyone. To claim your trial, simply visit our website and fill out the sign up form.

XBRL accounting taxonomy design and categorisation – Part 2: Architecture

In this series of articles, we propose a categorisation of taxonomies based on three aspects of their design: architecture, coherence and extensibility.  Using this categorisation we look at the evolution of taxonomy design through three generations.

1. An example of three taxonomy generations

In this article we look at the architecture of three taxonomies that are good examples of each generation:

2. What is architecture?

The ancient Greeks bequeathed us the word they used for the “chief builder” – architect.  Good architecture manifests itself in perceived simplicity, elegance, or consistency of form; making the best or even inspired use of the available materials and prevailing building techniques; enhancing, working with or at least complementing the environment in which it resides; and performing its intended function effectively and reliably.

In the modern world architecture doesn’t just apply to physical structures. In the software world, it can be applied to any moderately complex logical structure. There is little doubt that an XBRL taxonomy qualifies in this regard, so it is reasonable to apply the principles of good architecture to taxonomies.

3. First generation: standards based – the IFRS taxonomy

The International Accounting Standards Board’s IFRS taxonomy has been in existence for over ten years – its latest incarnation is for 2016. By that measure alone it might be regarded as a first generation taxonomy.

Its architecture is derived from the structure and content of the International Financial Reporting Standards. These standards were drawn up without the knowledge that an XBRL taxonomy would be based upon them.

The IASB was breaking new ground when it first developed its IFRS taxonomy, and to provide the taxonomy with authority it was essential to model the underlying standard as closely as possible.  The design focused on ensuring that each concept in the taxonomy mapped directly into IFRS standard which, while being a good way of reflecting the precise structure of the standard, was not able to benefit from the elements of normalisation common to modern IT data design.  The result is a taxonomy that contains silos of repetitive concept definitions, labels and dimensions.  It is also dimensionally incomplete, using dimensions only where they are absolutely necessary to fully describe data relationships.

Secondly, in limiting the content of the IFRS taxonomy strictly to the scope of the underlying standard, it was unable to provide guidance to the builders of other taxonomies based on IFRS until the creation in 2014 of the IFRS Taxonomy Consultative Group (ITCG).  One consequence of this approach is that taxonomies already derived and extended from the IFRS taxonomy vary markedly from jurisdiction to jurisdiction.  This design freedom has turned out to have a critical side effect, which is that it makes it more difficult to compare financial data drawn up against different IFRS-based taxonomies.

4. Second generation: document based – the US GAAP taxonomy

The US GAAP taxonomy has a rigorous and well-documented three-layer architecture comprising a domain model, a logical model and a physical model, with clean separation between the layers.

Similar to the IFRS taxonomy, the US GAAP taxonomy is the embodiment of a set of accounting standards.  It was modelled on the various kinds of documents that arise from the practical application of a set of accounting standards rather than the standards themselves.

The taxonomy is characteristic of architectures that have to cater for, and are developed by, numerous stakeholders.  Each of these stakeholders works with a variety of different documents each of which need to be modelled by the taxonomy leading to an unavoidable loss of focus.

This document-centric model has influenced the taxonomy in a number of ways. These include a proliferation of one- and two-dimensional hypercubes that closely resemble the tables that typically appear in documents and a requirement for HTML-marked-up “text block” data items.

5. Third generation: data model based – the UK FRS taxonomy

The UK FRS taxonomy is primarily based on the International Financial Reporting Standards (though not the IFRS taxonomy) so one might expect similarities with the IASB’s IFRS taxonomy. However, the architecture is very different.

The UK FRS taxonomy has no formally documented architecture, but nevertheless it does have a design that is modular and consistent.  The approach has been to model the data defined by the standards rather than the documents. This allows the taxonomy to focus on the data rather than document structure or presentation.  The key is in understanding the data and its potential dimensionality.

The taxonomy team at the FRC expended a considerable amount of time working with preparers and consumers to analyse over eight million Inline XBRL financial reports that had been produced in the UK since 2011, tapping into their experience to understand how the data is collected, organised and used. This has resulted in a data-centric architecture with a complete and comprehensive dimensional model.

6. Conclusion

We’ve described three contemporary taxonomies in terms of their architecture and indicated why we think each of them are good exemplars of the changing architectural approaches that characterise each of the three generations.

With each generation the foundation of the taxonomy’s architecture has become deeper and more analytical, moving from a model based on standards, to documents, and then to data. In the process, presentation, as an architectural concern at least, has been stripped away.

In following articles we’ll discuss other aspects of these three taxonomies that reinforce this characterisation.

7. A final thought

It is worth noting that you can arrive at substantially the same conclusion by different architectural routes.

If you look at the Presentation Linkbases of these three taxonomies you’ll see much the same document-centric, IFRS-oriented structure, thanks in part to the alignment of reporting terminology.  However, the underlying architectures differ significantly.

Despite this, the architects of these three taxonomies have arranged for users to see and browse the reporting structures with which they are familiar.  It wasn’t necessary to follow one particular method of deriving a taxonomy to do this.  This is a powerful demonstration that presentation is neither a by-product of design, nor something that has to be “designed in” from the outset.

XBRL accounting taxonomy design and categorisation

1. The future of taxonomy design

This is the first in a series of articles in which I propose a novel categorisation of accounting taxonomies based on three aspects of taxonomy design: Architecture, Coherence and Extensibility.

In this first overview article I will introduce the three design aspects. In future articles I will cover these aspects in more detail and examine how they apply to the US GAAP, IFRS and UK FRS taxonomies. The series will conclude with a discussion of how I’ve categorised these taxonomies and how this categorisation might inform the current direction of taxonomy design.

2. Why are taxonomies so important?

XBRL taxonomies are the key components of any electronic financial or business reporting system. An XBRL taxonomy is the formal definition of a financial or business reporting vocabulary for a given jurisdiction or reporting domain, imparting meaning to the concepts which describe the facts being reported and providing a framework within which reports are structured. It defines, the “contract” between reporter and regulator.
Just as importantly, it defines what is not permitted, except insofar as “locally negotiated” extensions allow. A taxonomy also defines relationships between reporting concepts, meaning that the “contract” not only defines the reporting vocabulary (the “what”) but also the grammar (the “how”) – how reported concepts can legitimately be combined and related to each other.
It is for these reasons that taxonomies matter in an electronic world. They are fundamental to any financial or business reporting regime and their design exerts a direct influence on the capabilities and expressive power of reporting and analysis tools.
XBRL tools and technologies are still evolving to suit the market’s needs. Experience has shown that deploying XBRL solutions takes a considerable amount of time and effort, and a large portion of this is invested in taxonomy design and development. Taxonomy authors are continually developing new ways to address the complex challenges of financial and business reporting.
It’s clear that XBRL taxonomies are currently undergoing a period of rapid evolution as they colonise a number of new financial niches, with new taxonomies building on the successes – and avoiding the perceived failures – of previous generations. I’m proposing the establishment of a new classification system for taxonomy evolution, with the hope of illuminating the future of taxonomy design.

3. Taxonomy evolution

In the family tree of taxonomies, those concerned with company financial statements can be broadly classified according to three key aspects. This has resulted in taxonomies that can be classified as belonging to one of three generations.

3.1 Aspects of taxonomy design

3.1.1 Architecture

Some taxonomies model the applicable accounting or financial standards; some model the required reporting documents; and some model the underlying data.

3.1.2 Coherence

‘Coherence’ is the degree to which a taxonomy “hangs together” and permits the creation of a body of instance documents that are consistent and comparable. At one extreme some taxonomies give the freedom to combine reportable concepts with any dimensions and to combine dimensions freely. At the other extreme such combinations are carefully controlled by the taxonomy.

3.1.3 Extensibility

Some taxonomies are very permissive when it comes to extension, to the point that “anything goes”; some taxonomies provide specific extension points so that extension can be controlled, if not actually defined; and some taxonomies provide specific mechanisms to support extension.

3.2 Taxonomy classification

3.2.1 First generation

First generation taxonomies are literal interpretations of accounting or financial standards, where the filer can do pretty much whatever they please with the base taxonomy, and any additional structured information can be captured as a privately-defined but uncontrolled extension.

3.2.2 Second generation

Second generation taxonomies model not the accounting or financial standards themselves but the regime’s required document structures derived from the applicable accounting or financial standards. Additional structured information can be captured in a private extension that should follow certain rules or guidelines laid down by the taxonomy author.

3.2.3 Third generation

Third generation taxonomies move away from an architecture derived from the accounting/financial standards or reporting document structures and instead simply model the data within the taxonomy. Additional structured data can be captured by ‘extension’ mechanisms built in to the data model of the base taxonomy itself.

All three generations exhibit convergent evolution in that they all provide a document-oriented browsing and presentation view that will be familiar to preparers and accountants, but each is derived in a fundamentally different way.

4. A new taxonomy classification system

The key taxonomy design aspects that categorise taxonomy evolution are summarised as follows:

Taxonomy Classification

5. Next article

In the next article in this series I will discuss the Architecture aspect of taxonomy design in depth, with reference to the US GAAP, IFRS and UK FRS taxonomies.

I would like to also thank Andy Greener for his contributions.

Life after the removal of Excel-based CRD IV reporting in Portugal

In June 2014, to ease the transition to its new CRD IV reporting regime, the Bank of Portugal introduced a free reporting system based upon the completion of Excel spreadsheets. Not surprisingly, very many Portuguese financial institutions took this easy way out and for the past year have been filing their CRD IV returns using this method.

Only XBRL accepted from the end of June 2015

However, as was fully explained at the time, reporting in Excel was introduced as an interim step only, and the ability to use the spreadsheet-based system is about to disappear. From the end of June 2015 the large number of filers currently using the Excel-based reporting application will have to find an alternative approach.

Seahorse, the XBRL lifeline

Seahorse®, CoreFiling’s cloud-based XBRL conversion software, will provide a lifeline to Portuguese financial institutions now that they need to find ways of converting their spreadsheet data into fully validated XBRL instance documents before submission to the Bank of Portugal. Seahorse provides an easy to use, risk-free solution to the problem of complying with the CRD IV XBRL mandate. It is a SaaS-based application, readily accessible from any internet browser. There is no software to install or maintain, and Seahorse requires no effort on the part of the user when taxonomy changes occur, as these are handled behind the scenes.

Continue reading “Life after the removal of Excel-based CRD IV reporting in Portugal”

The count-down to Solvency II Pillar 3 reporting – 5

How do I keep up to date with XBRL taxonomy changes?

The whole process of gathering relevant data and implementing an effective workflow to turn that data into valid XBRL reports is daunting enough, but the challenges do not stop there. What happens when the underlying XBRL taxonomy changes, as it undoubtedly will? What solutions are available to help smooth the reporting process?

The impact of Solvency II taxonomy changes

Without specialist insight into the taxonomy structure it is difficult to understand what changes have occurred from one version to the next and, more significantly, how the changes might impact both technical considerations and the preparation of XBRL reports.

Compliance with EIOPA business rules

The business rules imposed by EIOPA and the NCAs may also be amended from time to time, and this could have a profound effect on the data that needs to be reported. How will your reporting systems cope with frequent updates? How will you make sure that your systems remain current, producing totally valid XBRL documents that will not be rejected at the point of submission?

Some systems rely on hard-coding and may prove inflexible, so you would do well to make sure that you will not incur massive system and cost overheads just to bring your reporting into line each time.

Continue reading “The count-down to Solvency II Pillar 3 reporting – 5”

The count-down to Solvency II Pillar 3 reporting – 4

How do I report to my NCA?

Although it remains at the discretion of the individual NCA, many regulated firms will find that they must now submit their quantitative reports in XBRL, which may be an unfamiliar format presenting a new set of challenges, particularly since there is now so much more data to be handled (at a recent conference estimates were quoted at over 10K data items for solo reporting, and 200K for group reporting during the preparatory phase, increasing to around 40K and 800K data items respectively when full scope reporting arrives in January 2016).

Integration or standalone?

How to handle the data is a key issue. Many insurers will have existing workflow and security processes in place, but must now integrate them with the less familiar requirements of XBRL preparation, validation and rendering, so both the IT department and the business will need to engage to ensure that the relevant data can be captured and turned into the required reports.

Decisions need to be made: whether to create a standalone environment or embed reporting into current architecture; whether to rely on process professionals to provide the specialist XBRL capabilities (which may be outside their core competence), or to seek help from a dedicated XBRL technology company.

Continue reading “The count-down to Solvency II Pillar 3 reporting – 4”

The count-down to Solvency II Pillar 3 reporting – 3

What do I report?

As mentioned in the previous Blog Post, even firms that begin reporting during the Solvency II preparatory phase will notice a hefty increase in the number of templates they need to complete when full scope reporting arrives in January 2016.

Quantitative and qualitative reporting

Solvency II Pillar 3 brings a huge increase in the amount of data that needs to be reported. For example, for the first time detailed asset data must be included. Firms will also need to take into account a new set of reporting requirements, relating to both quantitative and qualitative disclosures. Under Pillar 3, the main focus is on two particular reports, which require both qualitative and quantitative data:

  • SFCR – Solvency and Financial Condition Report
  • RSR – Report to Supervisors

Public vs private reporting

Reporting also occurs on two levels – public and private. For example, a few of the quantitative templates and qualitative data will be made public in the SFCR, whereas all quantitative templates and a detailed set of qualitative data must be reported privately to the regulator in the RSR.
Continue reading “The count-down to Solvency II Pillar 3 reporting – 3”

The count-down to Solvency II reporting – 2

Do I need to report and when?

In the second of our blog series, we examine which insurance undertakings will have to begin reporting under the preparatory phase that EIOPA has introduced as a precursor to full Solvency II reporting which finally takes effect in January 2016.

While all insurers are expected at least to start preparing for the full implementation of the Solvency II regime, only certain organisations meeting prescribed thresholds will need to report to their NCA during the preparatory phase, but this is due to begin in June 2015, so time is very short.

Interpretation of the EIOPA thresholds

The thresholds specified by EIOPA are:

  • Individual annual reporting for firms representing at least 80% of the national market share
  • Individual quarterly reporting for firms representing at least 50% of the national market share
  • Group quarterly or annual reporting for firms with more than EUR 12 billion (period ending during 2012)

Continue reading “The count-down to Solvency II reporting – 2”