XBRL accounting taxonomy design and categorisation – Part 5: Integrity

What is instance document integrity?

Any discussion about the capabilities of XBRL taxonomies would be incomplete without considering mechanisms that help to ensure the integrity of instance documents prepared in accordance with them. But what do we mean by ‘integrity’?

In this context integrity means the correctness and self-consistency (both arithmetic and logical) of the document data content itself. Do the financial statements make sense? Do all the fundamental relationships between accounting concepts hold? Does the Balance Sheet balance!?

The technical integrity of an instance document is of course the responsibility of XBRL-aware production software and can be validated by any XBRL Specification conformant validating processor – the taxonomy has little bearing on this.

Instance document integrity checking may be known to you by other names such as business validation, quality assurance, consistency checking or even auditing (of which it is but a small part).

The XBRL Specifications equip taxonomies with a couple of ways of specifying and applying integrity checks. First is the venerable Calculation Linkbase, which provides a means to express and visualise simple arithmetic relationships between concepts that have equivalent contexts. This has been part of the XBRL technology stack from the very beginning. Second is the more recent Formula Linkbase, which provides a means to express both logical and mathematical relationships between concepts regardless of their context.

The Formula Linkbase is by far the more powerful of the two, and to all intents and purposes provides a superset of the capabilities of the Calculation Linkbase. It is widely and heavily used in the financial regulatory reporting world to express business validation rules in the highly dimensional taxonomies used in the CRD IV and Solvency II regimes in Europe.

However, with power comes complexity! Formula Linkbase has not supplanted Calculation Linkbase in those cases where the latter is used to visualise and express the simple arithmetic relationships generally found in financial statements – its complexity and lack of visibility of relationships has prevented Formula Linkbase from becoming ubiquitous.  This is particularly true where extending calculation relationships is an integral part of entity-specific extensions.

Let’s look at what each of the three taxonomy examples provide and what, in addition, others have supplemented this with where relevant.

The IFRS taxonomy

The IASB has equipped the IFRS taxonomy with a Calculation Linkbase that expresses, where possible, arithmetic relationships that are also closely mirrored in the hierarchy of the Presentation Linkbase – a result of both being derived directly from the standards documents. These relationships are of course limited to items that have the same context (i.e. the same dimensions and period), which precludes dimensional aggregations and any cross-period calculations such as “roll forwards” (where adjustments are made during a period of time to an opening balance to arrive at a closing balance). The result is a series of calculation relationships (or networks) that encompass less than 50% of the line items defined in the IFRS taxonomy.

To address this deficiency in coverage IASB have also released an “unofficial” Formula Linkbase. It is intended to be an “add-on” to the IFRS taxonomy for those whose consistency and integrity checking needs are not met by the taxonomy Calculation Linkbase alone. It provides some generic “patterns” to enable roll-forwards, earnings-per-share calculations, dimensional aggregations, fact equivalence checks and negation checks to be applied to instance data. In conjunction with the Calculation Linkbase this provides reasonable coverage of an instance document, albeit in a rather fragmented fashion.

As is often the case with such after-thoughts, there are drawbacks. In order to provide generically applicable patterns the IFRS Formula Linkbase relies on recognising the content and format of labels and particular structures in the Presentation Linkbase – roll-forward adjustment concepts, for instance, must be positioned between the opening and closing concepts, which in turn must have labels of a particular format. This method of applying generic integrity-checking patterns seems very brittle and prone to disruption from innocent cosmetic changes to the Presentation Linkbase (spell “beginning” incorrectly, as they have done in the Preparers’ Guide example, and the pattern is not recognised and applied).

To summarise, the IASB have attempted to provide a reasonable level of arithmetic integrity-checking coverage for instance documents despite the limitations imposed by the taxonomy’s design and by the available XBRL “toolset”. The method by which Formulae are applied however leaves much to be desired.

The US GAAP taxonomy

Like the IFRS taxonomy, the US GAAP taxonomy comes complete with a Calculation Linkbase that expresses arithmetic relationships, though in the case of the US GAAP taxonomy this covers roughly 70% of the defined line items.

There is no equivalent, however, of the supplemental IFRS Formula Linkbase for the remainder. The arithmetic consistency and integrity of instance documents cannot be completely verified by the US GAAP taxonomy alone.

Since the US GAAP taxonomy is primarily used for a very specific purpose (i.e. filing quarterly and annual financial statements to the US SEC) it is supplemented by regime-specific filing validation (the EDGAR Filer Manual – EFM) and a couple of XBRL US-based initiatives: the Consistency Suite and the Data Quality Rules provided by the Data Quality Committee (DQC). The latter is a free service, but the former costs real money. The EFM rules are of a technical nature, a layer above XBRL validity if you like, but do not address instance document integrity.

There appears to be some overlap between the Consistency Suite (12,000 checks claimed) and the Data Quality Rules (30 or so rules currently), but the latter focus specifically and more deeply on particular primary statements – the Statement of Cashflow, for instance, seems particularly well served by the rules released so far.

The majority of these additional rules are arithmetic in nature, provided to plug the gap left by Calculation Linkbase’s inability to express cross-dimensional and cross-period relationships, but a minority also provide checks for logical consistency and integrity that go beyond arithmetic consistency.

FASB, in association with XBRL US, have made a good stab at covering the arithmetic consistency of instance documents through a combination of the Calculation Linkbase and one or other (or even both) of the separate XBRL US consistency/data quality checks, and this is clearly an on-going process as more rules are added.

The UK FRS taxonomy

As a result of the highly dimensional nature of the UK FRS taxonomy the authors declined to provide a Calculation Linkbase at all on the grounds that it would be of extremely limited value. Instead, the Financial Reporting Council (FRC) provided, along with the taxonomy, a representative set of consistency check definitions for line item summation and cross-dimensional summation written in structured form in Excel workbooks. These cover several “subject” areas, such as Biological Assets, Intangibles, Inventories, PPE, Trade and Other Payables, and Trade and Other Receivables. In addition, there is a set of logical relationship checks.

These rules are intended to be implemented in a suitable form by the developers of instance document preparation applications, independent quality assurance services and consumers of instance documents.

An implementation as a Formula Linkbase would certainly be possible but perhaps because the FRC do not regard these as validation checks (hard and fast rules to be passed or failed) but as consistency checks to measure instance document integrity and quality against, they declined to provide one as part of the official taxonomy.

Nevertheless, the FRC consistency checks have been implemented in various forms by various vendors, preparers and service providers to enable those with sufficient motivation to assess the arithmetic and logical integrity of instance documents (always Inline XBRL instance documents in a UK context) against a single official benchmark set of rules.


The “owners” of all three taxonomies, as we have seen, provide the means in one form or another for users of their taxonomies to apply arithmetic and logical integrity checks to their instance documents. There is certainly a commonality of purpose, if not consistency in the provision of capability.

Both IASB and FASB rely on the limited Calculation Linkbase for basic arithmetic consistency to one extent or another, but recognise its shortcomings and supplement it with alternate means that further its coverage and go beyond it into the realms of checking logical consistency and integrity. This creates a somewhat fragmented but nevertheless viable solution in both cases.

The FRC have at least provided a single coherent set of consistency checks, but chose not to provide an implementation themselves, for whatever reason, preferring instead to leave that to others (the same could be said of FASB too, leaving the definition and implementation of consistency and quality rules to XBRL US/DQC).

We seem to have reached a point in the evolution of taxonomy design that we have been exploring in this series beyond which taxonomy architects and designers cannot pass unless and until the XBRL standard itself (in the form of XII) lends a hand with newer and better taxonomy-based capabilities.

There are two obvious avenues to explore: a better and more approachable way of constructing a Formula Linkbase that makes explicit the relationships between concepts; or, an improved version of the Calculation Linkbase that overcomes the limitations of the present one and provides the same severity-reporting options (i.e. not just pass or fail) that the Formula Linkbase does.

If the power of the Formula Linkbase can be tamed then it is capable of doing everything that even an improved Calculation Linkbase can do, and a lot more besides. However, as a means of expressing simple arithmetic relationships (and doing that one thing well) the Calculation Linkbase has a lot going for it. It is transparent and understandable, and if it can retain those traits whilst being enhanced to deal with dimensions, periods and flexible severities then it might just be the right tool for the job.

Finally, it is worth noting that whilst the arithmetic used in financial statement integrity rules is generally straightforward, the applicability of those rules is not. There is huge variability in the presentation and content of financial statements for all sorts of reasons. Different sizes and types of entity give rise to varying disclosure requirements, and often preparers can also exercise some choice over how financial statements are presented, which in turn impacts the content.

Unless such factors can be determined automatically from the content, and it’s not clear that they always can be, some “rules” will never achieve universal applicability. For this reason consistency and data quality “rules” should be regarded as an aid to integrity-checking and not as an absolute measure of integrity.


XBRL accounting taxonomy design and categorisation – Part 4: Extensibility

What is taxonomy extensibility?

To recap from the first post in this series, “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”.

It may be that a reporting requirement can be explicitly and completely stated a priori, in which case the regulator’s taxonomy is all that is required. However, not all reporting requirements are so clear-cut. In particular, company financial statements can be very diverse, reflecting the diversity of companies and company accounting in general. Therefore, unless some other aspect of the reporting regime restricts what needs to be reported in XBRL to the concepts in the taxonomy, accounting taxonomies sometimes or always need to be extended in practice.

The ‘X’ in XBRL stands for ‘eXtensible’ of course; technical extensibility is built in to XBRL from the ground up, enabling a ‘base’ taxonomy to be extended, possibly multiple times, by parties other than the original author. Whether a taxonomy should be or needs to be extended in practice, however, is a matter for the regulator and the manner in which the regime operates.

Therefore, all three taxonomies we’re considering are capable of being extended, but they are designed for environments where the requirement to extend or the need to extend is very different.

The IFRS taxonomy

The IASB’s philosophy is that its IFRS Taxonomy provides building blocks that users (both taxonomy extenders, such as regulators, and instance document preparers) can employ in extension taxonomies to represent the data they want to report.

The default position from the outset is that extension is the norm (because the taxonomy as it stands is not adequate for most practical purposes), but there is no effective control over how the building blocks are used and how extension is undertaken. Users have total freedom to extend.

This is likely to result in poor comparability between instance documents that utilise different extensions unless extension in a given jurisdiction is rigorously enforced over the preparers in that regime. Even then, any reasonable degree of comparability would be restricted to that jurisdiction.

Only relatively recently has the IASB issued guidance for regulators that contains “best practice” advice on extension style and architecture, but this only goes so far to avoid filing system implementations that are incompatible with each other, somewhat destroying the intent and benefits of an international standard. It almost certainly won’t result in consistency and comparability between instance documents produced in different jurisdictions.

Even more recently the IASB has issued guidance for preparers but it has little to say on maintaining the consistency and comparability of instance documents when preparer extension is permitted in a given jurisdiction, threatening even comparability between instance documents within a jurisdiction.

The US GAAP taxonomy

The US GAAP Taxonomy was designed with preparer extension in mind, whilst at the same time pursing a goal of limiting the need for extensions to facilitate period-to-period and cross-industry comparability. This approach is reflected in the large number of reportable concepts and dimension members in the taxonomy, which is in part an attempt to cover the broadest possible range of information within the bounds of practicality (as well as a consequence of the sheer breadth of US GAAP itself). Nevertheless, experience has shown that the majority of SEC filers find it necessary to provide their own additional concepts (as part of the mandatory filer extension taxonomy) to supplement their instance documents. The goal of general comparability has clearly not been met (as yet).

“Design for extension” is incorporated in the taxonomy’s Logical Model, a key principle of which is “Disciplined Extensions”. This appears to be based on design rules that ensure an internally consistent taxonomy that others will need to extend. However, this is a necessary but not sufficient principle to ensure disciplined extension. What is needed are rules or guidelines for extenders to follow, but this is precisely what is not offered by the taxonomy architecture: It is beyond the scope of the architecture to create a formal expression of extension rules to facilitate “disciplined” or “channelled” or “managed” extensions within systems that use it. (from section 1.3, Logical Model). Instead it is left to implementers of software systems to build such formal expressions, so it is little surprise that the approach has met with limited success.

The UK FRS taxonomy

The UK FRS Taxonomy provides no specific support for extension, nor any encouragement for it, but equally it does not preclude it. The coherent nature of its data model, as we have already seen, along with the inclusion of exemplars of the use of typed analysis and grouping dimensions, suggests particular ways in which the taxonomy could logically be extended.

The presence of the analysis (“breakdown”) and grouping dimensions and the way in which they are employed in the taxonomy may well preclude the need for private extensions in the first place if the primary goal of an extension is to provide more detail (as opposed to new reportable concepts or different arrangements of dimensions). However, this is an approach that goes hand in hand with other aspects that may not always be practicable or available in a given jurisdiction.

The UK FRS Taxonomy has been created for use in an environment where Inline XBRL is used for company financial reporting. As a consequence, the ability to extend is not one of its primary goals. Experience has shown that in the presence of Inline XBRL, preparers and filers have not felt the need to extend the scope of the marked-up data that they disclose, preferring instead to disclose such information in the human-readable view only. Given this, the ability to extend is not promoted by the UK FRS taxonomy documentation in the same way as it is with the other taxonomies.


Again, we see a spectrum of capabilities that reflect the growing experience of taxonomy designers over the generations, this time in terms of extensibility. The oldest taxonomy design is the most promiscuous – just about anything goes with the IFRS taxonomy but the IASB has at least issued guidance and best practice advice. Both later taxonomies each take a much more controlled approach in their own way and to suit their intended audience.

As a single-jurisdiction taxonomy US GAAP is more likely to be subject to private rather than public extension, for the purposes of entity-specific disclosure. Its disciplined extension approach is designed to constrain extensions in an attempt to preserve comparability as much as possible, but it lacks any kind of policing to enforce it.

The UK FRS taxonomy is designed to operate in an environment where entity-specific disclosure is not, in general, expected to be tagged as XBRL, but instead made available to human consumers as HTML content. Entity-specific extensions are therefore largely unnecessary and very uncommon. It does, however, provide capabilities for entities to extend tagging to provide more detailed breakdowns or to provide arbitrary groupings of facts without the need for entity-specific taxonomy extension.

With each generation, taxonomy designers learn more about the uses to which their taxonomies are put and develop or acquire techniques to steer extenders in a direction that helps to preserve the underlying comparability and consistency of data.



A simple law of numbers to identify fraud… Benford’s Analyser

By Ben Russell,

Specialist Sales Consultant

Chair of Taxonomy Architecture Guidance Task Force, XBRL International

As part of our drive to showcase how innovative apps can be built on the True North® data platform, we’ve released a new at-a-glance fraud indicator tool. And it’s free on our website!

The design team behind this app were inspired by the principles of Benford’s law. This is an observation about the frequency distribution of leading digits in many real-life sets of numerical data, including financial accounts. In data that follows Benford’s law, leading digits are more likely to be low than high. So, given a large enough sample of financial data, numbers will start with a 9 on average 5% of the time, whereas numbers will start with a 1 more than 30% of the time.


This is an example of a good fit to Benford’s law:

To show this in action, the team created Benford’s Analyser app, a quick, high level check that can be used to help detect fraud through analysis of the numbers in financial statements. The free version allows you to apply the rule to leading digits in the latest filing for companies that submit annual and quarterly accounts to the Securities Exchange Commission (SEC).

As a statistical check, those using Benford’s law need to be aware of the implications of the results. Firstly, small sets of numbers are unsuitable for statistical analysis; secondly, a bad fit is not an indicator that there is fraud, rather that the numbers are not what would typically be expected. There are many company-specific reasons why this might be the case, of which fraud is just one. Those regulators, government agencies and auditors using the law may use this to decide where to look further.

As shown in the images below, Benford’s Analyser creates a chart from filings that shows the anticipated distribution of first digits – based on Benford’s law – using the numbers reported in the company’s quarterly and annual financial statements.


This is an example where the numbers do not fit Benford’s law:

In this platform tool, a chi-square value above 20.09 indicates that the numbers are only one per cent likely to appear in a normal set of accounts. The value shown (61.32) needs investigating to establish if fraud has taken place.

This is an example where there were too few numbers in the financial statement to apply this type of statistical analysis:

We’ve already had some great feedback for Benford’s Analyser from our latest rounds of innovation and customer outreach. Users were impressed with the immediacy of the model in creating tables for the filings under investigation.

Why not have a go via the link below?


Tagged financial data, such as XBRL reports, has become more readily available. CoreFiling is responding. We’re listening to our customers, bringing other automated checks to the market.

This is an exciting innovation and a testament to the creativity of the designers at CoreFiling.


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 US GAAP 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.

I’d like to thank Tom Ford for his contribution to this post.

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.

Artificial Intelligence: Applications Today, Not Tomorrow.

From reports of the DeepMind scandal a few weeks ago, to several talking spots at this year’s London Fintech week, July has arguably become Artificial Intelligence Month in the Fintech world. But while there has been a great deal of interest in future applications of AI, it seems that less attention is being paid to the AI solutions already out in the wild. Let’s take a look at the state of play for AI today.

Why the rise of AI?

It’s no secret that as computers get more powerful, and society gets more connected, organisations across all industries are feeling the pressure of too much data. Whether you’re gathering it, storing it, or trying to use it, modern data volumes present vast operational challenges. For example, Walmart, the world’s largest retailer, is reportedly building a private cloud that will process 2.5 petabytes of information each hour. That’s one company processing the equivalent of over half a million DVDs (or the estimated memory capacity of the human brain) each hour, every day.

The problem is bandwidth: a human being can only process so much information at once. Using Artificial Intelligence is a good way of dealing with such staggering amounts of data – and although we haven’t quite reached the I, Robot scenario, research into everything from deep learning to artificial neural networks continues to gather pace.

Applications today, not tomorrow.

One way that AI is helping to conquer the data mountain right now is through automation. The advantage of AI in this area is scalability – in theory, AI can learn how to recognise complex patterns of information that would normally require human understanding; AI-based pattern recognition has already been used to build surveillance cameras that can distinguish between people, objects, and even events.

At CoreFiling, we recognise that potential. That’s why we built AI-based automation right into our XBRL document creation tool, Seahorse. Seahorse learns how to interpret the fields in forms, and automatically tags the information, thanks to a form of machine learning called Logistic Regression. And because it’s hosted in the cloud, Seahorse benefits from every filing. Each and every document scanned refines its detection method, allowing Seahorse to achieve incredible levels of accuracy.

Click here to learn more about Seahorse.

A Wealth of Potential: Interview with Ian Hicks

Last week, CoreFiling’s Ian Hicks took part in the FRC’s Digital Future: Data round table, and discussed ways to combat the current “under-performance” of financial data. After the event, we sat down with Ian to talk about the benefits and challenges of using XBRL for Digital Future.

DAN: Is XBRL right for Digital Future?

IAN: Oh, absolutely. XBRL has applications around the world, and it’s flexible enough to meet the main goal of Digital Future, which to me is data versatility. The nice thing about XBRL is that it creates a kind of blank canvas with data, from which you can start to create solutions that meet the specific needs of each client or industry – that could be data automation, integration with other reporting media, and so on. That doesn’t mean it’s a perfect fit, though!

DAN: How so?

IAN: XBRL is a powerful standard, but it needs to be better at hiding complexity. CoreFiling already helped to address this in some instances when Philip Allen developed iXBRL, but XBRL itself still needs specialist applications to be useful.

DAN: You currently chair the XBRL Best Practices Board. Is reducing complexity something you focus on?

IAN: Oh absolutely, yes. But that relies on more than just developing XBRL. To reduce the complexity of an XBRL-based system, you need to take a holistic approach – develop working methods and processes that enhance customer experience, for example, or take advantage of new technologies.

DAN: What would be on your wish list for XBRL development?

IAN: I think the most useful thing for all applications, including Digital Future Reporting, would be to make XBRL a little more visual – more “renderable” – outside of specialist tools. Similar to how Microsoft plug-ins can be embedded in a browser. We’ve already started to address this with our Beacon platform, which renders XBRL instance data and displays it in a format that users can engage with.

From a more technical standpoint, I’d like to see features such as non-repudiation of instances – i.e. was the instance created by an authorized person, have its contents changed, is the date stamp correct, etc. More widespread use of auto-tagging would also be a great benefit to the preparer, accountancy and audit communities, both from an XBRL perspective and from the point of choosing the most appropriate concept.

DAN: How would those advances relate to Digital Future Reporting?

IAN: The Digital Future Reporting model is all about taking advantage of technology. The advantage of using XBRL is that it already supports features like auto-tagging – that’s how CoreFiling’s instance creation tool, Seahorse, is able to auto-tag filing documents, for example. The challenge is just to maximise the usage of these features.

DAN: Do you think XBRL is under-used in the fintech industry?

IAN: XBRL itself has an enormous user base around the world, but I do think its more advanced features are overlooked – which is why the Digital Future Reporting model is so key. But I think the most important thing is to deploy XBRL where it can be of maximum use. There was an interesting discussion in Dublin regarding “NOXBRL” – not a rejection of XBRL as it might imply, but rather the idea of “Not Only” XBRL. This discussion was around hiding the complexity of XBRL reporting from filers. It went on to cover the idea that XBRL is fundamental, but that other technologies should be included to meet the overall regulatory reporting need.

To give you one example, investment analysts have already developed sophisticated systems sourcing data in a multitude of ways, like “web-scraping”. XBRL has the capability to massively enhance these processes through its ability to rapidly and effectively analyse large sets of structured and unstructured data – this ability to enhance other technologies is what makes XBRL so useful. We’re already seeing this in practice in other industry sectors.

Linked Data is another example. Linked Data and XBRL appear to have progressed in parallel: there needs to be closer co-operation to benefit from using both technologies. This co-operation could result in massive benefits to the analyst community by simplifying the process of comparing information from seemingly disparate data sets.

DAN: What about outside fintech?

IAN: Extending XBRL beyond finance isn’t just possible, it’s already happening, and I fully encourage it!

DAN: Can you give us an example?

IAN: Non-financial data looks to me to be the next ideal candidate for XBRL. We’ve already seen something similar in the US, with the SunShot Initiative’s Orange Button Programme – XBRL is going to be used for solar data gathering and analysis. It’s a great idea, because solar data comes from so many different sources across America. You need to keep data like that in a single, consistent format to make it useful. Equally, organisations like AECA in Spain are pioneering the reporting and analysis of sustainability data using XBRL.

DAN: Do you have any advice for people already working with XBRL?

IAN: I think taxonomy developers should broaden their approach when developing a taxonomy. Rather than thinking just about the regulation to be met, they should also consider and take into account, far more thoroughly, the needs of the groups who will be consuming and analysing the data.

I’d also advise the filer communities to require the solution vendors to provide the means to simplify XBRL filing, to hide the complexity from users and report preparers. This could only encourage a more widespread adoption of XBRL in digital reporting.

DAN: Thanks Ian!

IAN: Happy to help.

To find out more about the FRC’s financial reporting lab, and the goals of the future data model, click here. And for information on CoreFiling’s XBRL services, click here.

EDITOR’S NOTE: parts of this interview have been shortened for clarity.

CoreFiling at the FRC’s Digital Future Round Table

This week, CoreFiling’s Ian Hicks joined over 20 other industry representatives in London for the Digital Future: Data round table, hosted by the FRC’s Financial Reporting Lab. Discussions focused on how XBRL can help facilitate Digital Future Reporting: a 12-step model proposed by the FRC that uses technology to combat the current “under-performance” of financial data – read more about Digital Future Reporting here.

The event was a great success, attracting attendees from key fintech organisations (including Vizor, IFRS, Workiva, the FRC, and the Bank of England). CoreFiling was on hand to provide important insights about XBRL and its capabilities – and as chair of the XBRL Best Practices Board, Ian also outlined how to follow best practice when implementing it.

 XBRL and the Digital Future model

As an open source technology, XBRL is a good fit for Digital Future, because it isn’t constrained to a single supplier. The standard is also well established, with many examples of large-scale implementation across the world (including tax ecosystems in the UK, Middle East, and now the USA); XBRL provides a proven framework for creating simple, cost-effective solutions, without needing to “reinvent the wheel” or develop brand new technologies.

As IFRS’s Rita Ogun-Clijmans noted during the discussion, “XBRL should focus on where it fits best into the Digital Future Reporting model” – CoreFiling agrees, as the strength of XBRL lies in its inherent auditability, data provenance, and versatility; XBRL can be linked with other reporting media to assist compatibility.

For more information about XBRL, iXBRL, and CoreFiling’s solutions, visit corefiling.com.

UK Government Joins the Party at London Fintech Week 2017

London Fintech Week is back for 2017, with a new line-up of conferences, workshops, exhibitions  and meet-ups for financial innovators. For those who haven’t attended before, London Fintech Week is a 7-day event designed to act as a hub for international financial professionals, held across the City of London, Canary Wharf and East London’s “Tech City”.

The event has gone from strength to strength since its inception in 2014 – and this year’s conference is the biggest yet. Starting on 7th July, London Fintech Week 2017 will host the UK government’s first International Fintech Conference. The conference aims to attract investors to the UK’s “high growth fintech centre”. Click here to read a comprehensive overview of the event by Liam Fox (Department for International Trade) on GOV.UK

Ready. Set. Innovate.

At CoreFiling, we know that developing new technologies is key to the success of the fintech industry – so here are the top 4 events we’re looking forward to most at this year’s London Fintech Week:

  • Regulatory Sandbox Panel. Barclays, Santander and Credit Suisse meet to unlock the potential of regulatory reporting. As experts in regulatory reporting technology, we’ll be watching with interest.
  • Blockchain & Cyber Security Showcase. Blockchain is set to be the next evolution in financial security – but how far can we trust the hype? Thomson Reuters, the Linux Foundation and Applied Blockchain investigate.
  • Machine Learning & AI: Is it OK to Panic Yet? With the recent Deep Mind scandal still fresh in our minds, we look forward to seeing this panel’s take on an important emerging technology.
  • The FCA’s Regtech Update & Innovation Hub Workshop. Innovation is at the heart of what we do at CoreFiling, and as long-time supporters of the FCA, we anticipate big things from this workshop.

A Bright Future for Orange Button & Solar Energy

CoreFiling recently joined XBRL US, the SunSpec Alliance, Wells Fargo and the US Department of Energy’s SunShot Initiative, to co-host the “Orange Button” webinar. This webinar focused on the role of XBRL in the US DoE’s Orange Button program – a solar energy development plan aimed at reducing solar energy costs (and growing the US solar industry).

Mark Goodhand, Head of Research at CoreFiling and a global authority on XBRL specifications, was on hand to give attendees expert advice about XBRL and its features. Solar energy is already big business in America, and a data-led approach is key to its growth; Mark showed that adopting XBRL will simplify and standardise solar data, aiding (and in some cases enabling) all aspects of the SunShot Initiative. The discussion of XBRL’s benefits covered everything from improved feasibility studies and financial projections, to better planning, smarter construction, and support for future research.

Chris Mills then put theory into practice, by taking the audience through a detailed demonstration of CoreFiling’s taxonomy development suite, Yeti.

The webinar was a real success, and gave the audience an exciting look at the bright future of solar development. Click here to watch the webinar on YouTube, or read a write-up on the XBRL US page. You can also get involved with solar energy by attending the InterSolar conference in July.