XBRL Queries, Inference Channels & the Inadvertent Disclosure Problem


CautionGirlAs we’ve discussed so often in related RVA_CFES Chapter posts,  prior to the passage of the US Sarbanes-Oxley Act, control assurance professionals like auditors and fraud examiners could review data principally only at discrete points in time.  With continuous SEC mandated XBRL supported reporting, we’re now operating with a reporting model in which detailed financial transaction data are more or less continuously available for query on corporate websites.  In the face of the hard fact that investors, analysts, insider-traders and fraudsters can all forcefully make the case that these systems improve the quality of their decisions, ethical or unethical, there needs to be some corporate review of the level of detail that should be made publicly available.   As the available web based data expand to include all operational information, there’s certainly a benefit to legitimate investors and analysts as they delve into the intricacies of the firm.  The technology to support this vision is upon us but, I would argue, there needs to be a critical review of the query systems that provide the interface between investors and the underlying corporate data; one such critical issue is the display of query results.  The type of powerful query systems envisioned by the SEC, have access to most, if not all, of the firm’s data.  Rather than simply responding to requests, such systems must be able to balance the requests for information with the need to protect sensitive corporate information.   For example, if the system responds to multiple queries about sales grouped by states or regions (or other types of grouping), if enough queries are asked of the system, the value of sales for a particular store or even for a particular customer can be determined.

The ability to time XBRL queries may also lead to inadvertent disclosure.  For example, if an unauthorized person knows that a corporate employee is about to be made manager of a division, then requesting wage information for  the division before and after the appointment can disclose the target’s salary.  Even responding inappropriately can provide unintended information; a response of  “that information cannot be provided” to a query asking whether a certain project is confidential  will have the unintended consequence of providing the requested information.

Fraud examiners need to be aware of the concept of inference channels when discussing problems related to inadvertent XBRL disclosure with our clients.    An inference channel is an identified set of information that would allow someone to infer a piece of knowledge.  The assumption is that a user knows the piece of knowledge once that part of the channel is traversed.  Users are assigned a set of virtual tokens that are assigned to that user as each piece of information is acquired from the system.  The tokens for the inference channel are used before the user is allowed to acquire the final piece of information in the channel.  Knowledge protection is performed by identifying the individual pieces of information that make up a channel or path to the protected or sensitive knowledge set and assigning tokens to those pieces.  The tokens essentially make up the charges to traverse the channel and protection is achieved by keeping the number of tokens below the number necessary to get to the final information the firm wishes to safeguard; i.e., if you’ve asked for this and this and then this, you can’t get access to this.

The bottom line is that, if enough uncontrolled queries are allowed, the user can eventually discover all the underlying data.  This becomes an even greater problem with the XBRL-GL model, in which even the underlying transactions are tagged in a machine readable form and are available for disclosure.  What every corporate XBRL SEC filer needs as part of its fraud risk assessment is a clear set of criteria that will provide a precise definition of the nature of the interface between its web based financial reporting system and the user.   Management has to approve whatever standards for the control of queries that its IT and assurance units (internal audit, external audit, fraud examiners, etc.) come up with. These standards have to specify precisely what level of system response to query chains is acceptable and what levels are not so that instances of inadvertent disclosure can be prevented.

Please make plans to join us on April 16-17th, 2014 for the Central Virginia Chapter’s seminar on the Topic of Introduction to Fraud Examination for 16 CPE ($200.00 for early Registration)! For details see our Prior Post entitled, “Save the Date”!


  1. Interesting that XBRL GL was raised as introducing new/increased risk in inadvertent disclosure.

    I do have to question the situation that ” the underlying transactions are tagged in a machine readable form AND ARE AVAILABLE FOR DISCLOSURE”. Nothing makes XBRL GL tagged ERP data any _more_ available for disclosure than existing proprietary formats with which ERP data is represented to bridge systems for data integration, data migration, consolidation or archival purposes. There is no “XBRL GL model” of mandated disclosure in the US, no access to XBRL GL content outside the firewall other than that desired (or “leaked”).

    The broad topic of continuous reporting/audit, queries, and inadvertent disclosure is certainly thought-provoking; I have heard Prof. Graham Gal of Isenberg School of Management speak on this topic with some conviction at the Rutgers Continuous Auditing conferences.

    Every change brings trade-offs and potential loss; introducing a standard like XBRL GL may mean some existing issues are exacerbated, for sure. But does a variety of non-standard formats bring greater benefit by protecting private company data through obscurity, diversity and format-challenges, or are the efficiencies of XBRL GL worth risks that may easily be remediated? Do the potential benefits of a single, global, standardized, holistic, generic format. XML-based standards offset any potential incremental risks?

    With XML standards like XBRL GL, you can leverage new, granular security and access mechanisms like XML Signature and XML Encryption for selective unfolding of content that is secured in transit, not just at the ends.

    Standardization and simplification mean you can bring greater transparency and facilitate oversight of handling and transport. When you can more easily query your own data for, say, personally identifiable information standardized with XBRL GL, that means you can comply with rules. Yes – it does mean that systems that are not properly secured can be queried more effectively. Understand the risks and benefits and develop controls to minimize the risks while gaining the benefits.

    Standardization can reduce need for manual intervention, improve or eliminate spreadsheet spaghetti,