Digital Financial Reporting

Wired Magazine published an article, Algorithms Take Control of Wall Street, which explains how Wall Street is ruled by thousands of little algorithms. You can listen to an interview with one of the authors, Felix Salmon, on National Public Radio's Fresh Air: How High-Frequency Trading Is Changing Wall Street, (about 20 minutes).

Per the Wired article, by some estimates computer-aided high-frequency trading now accounts for approximately 70 percent of stock market total trade volume.

What drives these computers, these little algorithms? Information.

The article points out that Dow Jones launched a new data service called Lexicon which sends real-time financial news to professional investors. Many of the "professional investors" which subscribe to Lexicon are not humans, rather they are these computer algorithms.

Will these algorithms find the SEC XBRL information beneficial? Maybe. I would even go as far as saying probably at least a little. After all the information is only released quarterly. I am no expert on what information drives Wall Street decisions, time will tell if this information is helpful. But if 70 percent of the trades are made by computers rather than humans, could it be the case that the type of information needed might change?  Are financial statements as we know them obsolete, perhaps to be replaced by Twitter tweets of thousands of fragments of information which investor relations departments use to disclose company information? How will that information be audited? Who knows, but this is certainly interesting stuff which raises a lot of questions in my mind.

And what about this.  I have worked in two other "markets": specialty lumber and produce.  Both were quite interesting and had different dynamics. Few of us realize or pay much attention to the fact that the price of a box of lettuce can fluctuate between $3 a box and $26 a box and how that fluctuation can impact consumers and others in the supply chain.

The stock markets have probably spent millions, if not billions on all the infrastructure to make that supply chain work, to get to the point where automated computer driven trading is even possible. What if the costs of this infrastructure dropped substantially so that other markets, such as specialty lumber and produce, could afford such technology?

That is exactly what XBRL does. When I worked in the produce industry, the little company I worked for created some pretty impressive stuff using PCAnywhere, dial up phone connections, CSV data formats, and Microsoft Access 1.0. We still had lots of additional opportunities and lots of tasks where we interfaced with the outside world was done via FAX machines and telephone calls, but internally we had it together more than most.  But this was in the early 1990s.  I would love to go back there now and see what I could do using the Internet, web servers, XBRL, and all these other new tools we have at our disposal.

In chapter 7 of my book XBRL for Dummies I talk about business information supply chains. If this stuff is interesting to you there is a lot more information there.  XBRL is making automated computer business information exchange more cost effective for more than just financial reporting. These little algorithms will be working in lots of other industries performing lots of mundane tasks which humans perform today because it is not cost effective to automate those processes.  XBRL changes that. Not all processes will be automated, just the ones which make sense or the parts of processes where human judgement is not necessary.

What can you automate in your supply chain?

Jon Rowden and Mike Willis of PricewaterhouseCoopers have writen a white paper for the Financial Executives Research Foundation (FERF) titled Making Sense of XBRL In the US and the UK. This is a summary of what the paper discusses:

There can be no doubt that XBRL (eXtensible Business Reporting Language) has become a hot topic for financial executives in the U.S. and also overseas. Many are already familiar, perhaps painfully so, with the SEC's XBRL reporting mandate for issuers and the requirements relating to 10-K annual reports and quarterly filings. This article from Financial Executives Research Foundation looks at what is happening in the United Kingdom, where the tax authorities have introduced an XBRL requirement that affects all companies required to file a tax return. In this article, Jon Rowden and Mike Willis from PwC highlight how the UK mandate differs in some key aspects from the SEC requirement, how the UK requirements are being addressed and outline a wider agenda of considerations for financial executives in the U.S. and elsewhere, prompted by the introduction of XBRL by regulators around the globe.

With 1.6 million legal entities affected by this requirement for accounting periods after April 1, 2010, the use of XBRL takes yet another step forward following the lead of the US SEC, US FDIC, and many others around the globe. The white paper is worth reading discussing the "last mile" of reporting processes, why XBRL and iXBRL are a catalyst for change, common pushbacks and the wider agenda for CFOs and audit committees.

I posted a comment to the XBRL-Public mailing list relating to the UK's Financial Reporting Council calling for financial reporting to move from paper to the Web (which I also posted to my blog). My post led to a number of comments from others and a very good discussion relating to using the Web for distribution of financial reports. (If you are not on the XBRL-Public mailing list I would encourage you to join the list.)

During that discussion someone made the statement:

I actually think that iXBRL will eventually "take over the world" of XBRL reporting, simply because it supports what humans do - consume information through their eyes.

While I have not always been that hot on Inline XBRL (some people refer to it as iXBRL) because I have been convinced that it is a red herring trying to solve a problem that did not exist and because of the potential abuses of Inline XBRL to work around bad data modeling within an XBRL taxonomy. However, I am changing my mind and realizing that Inline XBRL, if properly used, could be of substantial benefit in ways which had not occurred to me before.

Here is why I am changing my mind and going as far as predicting that the US SEC may follow the lead of the UK and move to Inline XBRL and encouraging others to both be aware of this possibility and consider the Inline XBRL option when and if they implement XBRL:

• Document of record. Inline XBRL offers the possibility of having a "document of record" which is readable by both humans (i.e. the HTML aspect of Inline XBRL) and computers (i.e. the XBRL aspect of Inline XBRL). One does need to be careful to ensure that the information communicated and viewed as HTML is identical to the information a computer application reads, both should be in sync. But that does not seem that challenging and it is certainly easier than what SEC XBRL filers have to do which is keep separate HTML and XBRL documents in sync.
• Evolutionary path. Inline XBRL seems to offer a nice evolutionary path which a lot of people seem to need.  Personally, I am very confident that most people will eventually never use that HTML rendering in favor of the dynamic or "interactive" aspects of XBRL. For example, consider what I call the "hypercube jumping" (really has more to do with dimensions) and discuss in this blog post. But Inline XBRL does not take away the possibility of these dynamic features, they are still there to use, even if the XBRL is buried in an HTML document.
• Decouples presentation and data model. Using Inline XBRL allows for the "decoupling" of two things which, when dealt with together, cause problems. Inline XBRL allows the HTML aspect to deal with presentation, and therefore the creator of the data model is free to create a good data model and not try and get the presentation they are seeking by using the XBRL taxonomy. For example, SEC XBRL filers seek a certain presentation and to get that they leverage the only thing they think they have at their disposal with is the XBRL taxonomy. Using Inline XBRL for the presentation gives one precise control of the presentation. Not having to worry about the differences in presentation and presentation nuances allows for more "freedom" in creating a sound data model.
• Zero difference between XBRL and Inline XBRL. To a computer application trying to read the information, there is zero difference between a plain ole XBRL instance and an Inline XBRL document (instance, not sure what to call it). From the computer's perspective, they are 100%
  interchangeable. Now, I am sure that there are probably interoperability issues and bugs which might need working through, but that is all part of the process of getting things to work on a global scale.

So those are the positive aspects of Inline XBRL.  What about the downside? One thing which could be considered a downside is the fact that the software vendors who are building software to support creation of SEC XBRL filings are already going down a certain path.  Will they want to change that path, moving from supporting plain ole XBRL to also support Inline XBRL?  Well, the UK is already using Inline XBRL so software already exists for that.  This could provide an advantage for software vendors who are supporting Inline XBRL for the UK and a disadvantage for current software vendors supporting the SEC. Not sure how this dynamic will come into play.

Another dynamic which I am even less clear about is the actual creating the HTML and XBRL.  It is hard enough to put in the XBRL information.  How is creating both the HTML and the XBRL at the same time going to work out?  Again, I think the UK will provide some clues.  They are already doing this.

Finally, Inline XBRL is specific to supported rendering formats.  Currently Inline XBRL only works with HTML 4.  HTML 5 is really picking up steam.  The SEC uses an older version of HTML.  Not sure how the version of HTML plays into this or if there is a better rendering format than HTML, maybe PDF via XSL-FO.

Who knows how all this will turn out, but it seems to me that the advantages of Inline XBRL are significant enough that those working with SEC XBRL filings need to be aware of this and keep this possibility on their radar screens.

What do you think about the probability that the SEC might move to Inline XBRL? I cannot imagine that the SEC would do this any time soon.