Breakpoint Musings

Thursday, March 27, 2014

The Story of Three Miners

Once upon a time, there were three copper miners with nothing to their names but $100 each. They came upon a small mining town with a cozy little community and local government. With no other prospects, the three miners decided to try their luck here and see who could make the most money.

Needing supplies, they headed to the local supply shop to buy pickaxes, helmets, boots, flashlights and mustache combs. Each miner spent $50 on supplies in total, and on the way out of the shop, they noticed a sign: "Are you a copper miner? Apply for a subsidy from the local government today! Let us help you to grow our copper mining community!"

The first two miners were excited for a free handout to help them get started with their mining prospects, and ran straight to the municipal offices to apply for the subsidy. They were immediately approved, and were each given $50. The third miner followed a different principle. He refused to accept any financial help and was determined to make his own way in the world, without any government handouts. Now only having $50 and some supplies to his name, the third miner was already lagging behind the other two, who both had $100 and their supplies.

The first two miners work for a week and manage to mine about the same amount of copper each. The third miner (who refused to accept a handout) worked harder than the other two, and managed to mine double the amount of copper they did, in the same one-week period.

The first two miners are each able to sell their copper ore to a local refinery for $50. At the same copper price, the third miner profits $100. He attributes his skill and good fortune to having a bigger mustache than the other two miners. The balances of all three miners is now at $150.

Since the previous week, more miners have come to town and the industry is growing. The government continues to give copper miners a subsidy by giving money to them to help with the cost of supplies. Since the lack of a tax system has attracted many miners, and no one is willing to lend money to the government, the government resorts to simply printing more money into existence. They print enough money to double the current money supply in the local community, and use the proceeds to keep paying out subsidies to further stimulate the local mining industry.

The three miners notice at the end of the week that their supplies have all worn out, and they need to make another trip to the supply shop. Giant mustaches can be hard on those cheap plastic mustache combs! When the three miners arrive at the supply shop, they are surprised to find that the cost of supplies has doubled to $100! The miners ask the shopkeeper why prices have skyrocketed, to which he replies, "Well, the government just printed enough money to double the money supply and devalue the dollar by half! The way I see it, it's only fair that I double my prices, so that I still get a fair price for what I sell!"

Grudgingly, the miners can't argue with the shopkeeper's logic, so they agree to pay $100 each for more supplies. All three miners now have a balance of $50 each. Remembering the subsidy program, the first two miners head back over to the municipal offices, explain their harrowing experience at the supply shop, and each get another $50 payout to help with their costs.

At this point, the first two miners have $100, and a fresh set of supplies. The third miner worked twice as hard as anyone else, and had no financial help from the government, yet he is $50 behind the other two miners. Should the third miner not be wealthier, due to his producing double the copper of each of the other two? Even if the first two miners had not asked for a second government payout, they will have done less work than the third miner, and still have the same amount of money as him.

The key to this story is that the government used its printing press to create money out of thin air, and used that money to give handouts to a specific subset of the community. This money-printing led to price inflation, and rewarded some members of society at the expense of others. The first two miners accepted help and did less work and finished with $100, whereas the third miner did extra work with no help and only finished with $50. His misfortunes were due to the doubling of the cost of supplies.

What if the third miner were a nickel miner, and thus did not qualify for the copper mining subsidy? Rather than refusing help on principle, he may not have access to help at all. In this case, he has even less choice in the matter of money printing and price inflation.

This short story is obviously grossly over-simplified, and many other factors would come into play, if the story were to take place in the real world. However, the basic concepts of fiat money and its consequences are evident. In essence, the copper industry was not a truly free market, because the government intervened and wound up helping some people at the expense of others. Even though the government may have had good intentions, the fundamental forces of the free market were subverted, resulting in inaccurate allocation of wealth to individuals that had earned it. Furthermore, the third miner had no power to protect himself from this unfair scenario. He tried his hardest to get ahead, but resulted in being no better off than anyone else.

In essence, this story explains some of the most basic concepts of the Austrian School of economic thought. There is much more to Austrian School economics than can be explained in a single blog post, so I encourage you to read more on the topic. I found the book "Economics for Real People" quite illustrative, and I recommend reading some of the other material that is available from mises.org.

Since the Austrian School disagrees with the concept of fiat money and government deficit spending (known as Keynesian economics), one of the proposals of the Austrian School is that the government should not have a monopoly on currency. One or more currencies should be chosen by the free market (as gold was chosen as currency throughout history). No one individual, corporation or government should have the immensely powerful ability to print money. Unfortunately, this is obviously not the case in today's world.

However, there is still hope! Nothing prevents the general public from using something other than fiat money as currency. In fact, many communities have already developed their own local currency:

http://en.wikipedia.org/wiki/List_of_Canadian_community_currencies
http://en.wikipedia.org/wiki/List_of_community_currencies_in_the_United_States

Additionally, a fascinating new phenomenon known as "cryptocurrencies" has arisen in the online community over the past few years, and is just recently gaining significant popularity. The most popular of these cryptocurrencies is Bitcoin, although many similar currencies exist, some with different properties than others. Coins are "mined" using computational power, and can be spent, bought, sold and saved in a distributed fashion.

I believe that the concept of a cryptocurrency presents a vast and important opportunity for the general public of the world. It has been a century or more since the old days when countries of the world did not have a central bank or a fiat money system. No one alive today would remember what trade, commerce and the economy were like in the absence of fiat money. The message from central banks today is that they play a very important role in the economy, and their elimination would be catastrophic.

But what if we could conduct an experimental return to free market economics, without having to change any existing monetary systems that are currently in place? I believe that truly decentralized and unregulated cryptocurrencies offer the opportunity to once again experience a free market economy, except it would take place only in the online world. The advantages and disadvantages of a free market economy could be safely explored and recognized, without changing anything "in the real world".

Not only that, cryptocurrencies fundamentally cannot be inflated. Banks cannot take in cryptocoin deposits and lend out more coins than they have on hand, as a traditional fractional reserve bank would do with fiat money. Central banks cannot simply "print" more cryptocoins to fund government projects. Properly storing cryptocoins in a wallet on your local computer ensures that your money will always be on hand when you need it, never being susceptible to a bank run.

An important issue in the cryptocurrency world is that those with vast resources can purchase what are called ASIC machines, or Application-Specific Integrated Circuit machines. These machines are purpose-built to do one and only one thing: mine Bitcoins. When this is allowed to happen, the people with ASICs have a vastly disproportionate advantage over small miners with relatively low-powered GPUs.

I feel that a cryptocurrency should be made as intrinsically fair as possible. One of the most important requirements of a universal currency is that it can be easily obtained, traded, and used by the common man. For this reason, I feel that Vertcoin has the best chance at being that currency, due to its anti-ASIC properties.

The rise and fall of many different cryptocoins and their daily prices is a fascinating glimpse at how a completely unregulated free market behaves. Although there are security and technical issues with many (if not, all) cryptocurrencies, I believe that it is the responsibility of not just cryptocoin nerds, but of all members of society to participate in the great cryptocurrency experiment. My GPU is so slow that I likely mine Vertcoins at a loss, but I still want to participate in the community, and help the cryptocurrency market grow and evolve as much as possible. Even if you choose to mine a different cryptocoin, by all means do so! Anything that advances the industry will help evolution improve upon what has already been created and tested. I'm excited to see what cryptocurrencies look like in the next ten years, and I hope that everyone else is too! Together, we can once again experiment with a free market and let it exist alongside the real economies of today. If we like what we see, maybe it will spill over "into the real world"!

Saturday, October 12, 2013

My Concerns with XBRL

Over the past two or so years, I have been toying around, on and off, with a technology called XBRL. The following is the definition of XBRL from its Wikipedia page:

“XBRL (eXtensible Business Reporting Language) is a freely available and global standard for exchanging business information. XBRL allows the expression of semantic meaning commonly required in business reporting. The language is XML-based and uses the XML syntax and related XML technologies such as XML Schema, XLink, XPath, and Namespaces. One use of XBRL is to define and exchange financial information, such as a financial statement. The XBRL Specification is developed and published by XBRL International, Inc. (XII).”

XBRL is slowly gaining adoption among more and more public companies for mandated financial reporting. As a value investor, I am interested in analyzing public companies by their fundamentals and financial statements. As a professional software developer, I loved the idea of automating this analysis, and XBRL seemed like the perfect tool for gathering information that was already available. After several significant efforts on my part to understand and use XBRL via XML libraries and my own custom programming, my excitement quickly turned to disappointment. While I admittedly don’t have a wealth of experience in financial reporting or the use of XBRL, I can say with certainty as a software developer that XBRL is not easy to jump into and start programming with.

I slowly became convinced that XBRL was impossible to use on a large scale in its current form, without significant resources and development effort on my part. My disappointment only deepened when I found that a small start-up had already done what I set out to do: Gather XBRL into a database and expose a query interface for that data via the web. The website to which I am referring is www.calcbench.com. They seem to have built a very powerful system for ingesting, processing and presenting XBRL data, for which I give them credit, given my understanding of how complicated XBRL can be. Calcbench even admits to the complexity of XBRL themselves: “Priceless data being created, BUT extremely complicated to decipher.”

Not only is XBRL complicated, it also seems to be fraught with incorrect data. Calcbench claims to: “Use advanced computing techniques to identify and correct errors (close to half a million corrections made so far)”. It is somewhat worrying to me that such a large number of errors exist in the official financial data of public companies. There is no clue as to what the total sample size was for that number, but in any case, the accuracy of XBRL data is likely nowhere near 100%. This is not to discredit Calcbench; I am simply illustrating one of the issues with XBRL itself and its surrounding infrastructure.

Now that you have a summary of some of the deficiencies of XBRL, I will go into more detail regarding my experience in trying to use the standard. First of all, the Securities and Exchange Commission in the United States has mandated the use of XBRL in public company financial reporting. You can view their main XBRL web page at http://xbrl.sec.gov. To allow scripts, programs or human beings access to the full XBRL data store, the SEC has set up an FTP server that allows anonymous login. See http://www.sec.gov/edgar/searchedgar/ftpusers.htm for details. As far as I know, this is the only official source of XBRL data in the U.S. Due to that fact, the server is often slow, and downloading data (especially in bulk) can be very time consuming or sometimes not possible at all. Without reliable data availability, it is difficult for any software to ingest an initial data set in bulk.

The XBRL files that are stored on the SEC FTP server are not quite what a software developer would expect. Rather than an XML file containing only XBRL, files from the SEC seem to contain XBRL files within them, but are surrounded by additional SEC-specific data. For example, the typical format of a file may look something like the following:

<SEC-DOCUMENT>
     <SEC-HEADER>
        ...
        </SEC-HEADER>
        <DOCUMENT>
        ...
        </DOCUMENT>
        <DOCUMENT>
                <XBRL>
               (XBRL file)
               </XBRL>
        </DOCUMENT>
        ...
</SEC-DOCUMENT>

Source: ftp://ftp.sec.gov/edgar/data/1002427/0001104659-13-074521.txt

This format isn’t especially complicated, and wouldn’t be a concern other than the fact that these documents don’t even seem to constitute valid XML at times, let alone valid XBRL. Error correction is already necessary, despite not even having attempted to process XBRL data yet. When XBRL files are being extracted from this format, the type of each XBRL document must be detected and each file likely needs to be written out separately for better ease of use.

My concerns so far have only been minor concerns. One of my biggest concerns is that XBRL is too extensible, and that definitions of reporting standards are not coherent. One could say that a sort of meta-standard is needed, in order to regulate how standards are defined. For example, the US-GAAP and IFRS reporting standards are different in many respects, as you might expect. But if both are to use XBRL to define their standards, they should have commonalities when it comes to definitions and processing. In my view, this does not seem to be the case. Each uses XBRL in a different manner to mandate how reporting data should be formatted. On top of a variety of reporting standards being built on top of an overly-extensible data format standard, each XBRL reporting software suite interprets these reporting standards differently, resulting in a multiplicative number of XBRL interpretations and dialects. This places a large burden on software that is meant to ingest XBRL data, as that software must support a multitude of XBRL dialects and somehow convert each dialect to a common format.

For example, look at the following definitions of a “context” that defines a reporting period, as defined by four different XBRL software suites:

<xbrldi:explicitMember dimension="dei:LegalEntityAxis">ck0001002427:S000002337Member</xbrldi:explicitMember>

<xbrldi:explicitMember dimension="rr:ProspectusShareClassAxis">ck0001002427:C000006127Member</xbrldi:explicitMember>

</segment>

</entity>

</period>

</context>

<xbrli:context id="P04_01_2011To06_30_2011">

<xbrli:entity>

<xbrli:identifier scheme="http://www.sec.gov/CIK">0001301991</xbrli:identifier>

</xbrli:entity>

<xbrli:period>

<xbrli:startDate>2011-04-01</xbrli:startDate>

<xbrli:endDate>2011-06-30</xbrli:endDate>

</xbrli:period>

</xbrli:context>

</entity>

</period>

</context>

<xbrldi:explicitMember dimension="us-gaap:PropertyPlantAndEquipmentByTypeAxis">us-gaap:BuildingAndBuildingImprovementsMember</xbrldi:explicitMember>

<xbrldi:explicitMember dimension="us-gaap:RangeAxis">us-gaap:MaximumMember</xbrldi:explicitMember>

</segment>

</entity>

</period>

</context>

In each example, namespaces may or may not be used, XBRL Dimensions may or may not be used, and the context id fields follow wildly different formats between XBRL tools, some of which are indecipherable. These illustrated differences just scratch the surface of how different each XBRL tool output can be.

Upon realizing the difference between tools, I went in search of information, to see if anyone else shared my opinions. I was surprised to find that the “Father of XBRL” himself had written a whitepaper in 2008 on the growing problem of the emergence of different XBRL dialects.

From the whitepaper: “XBRLS: how a simpler XBRL can make a better XBRL”, by Raynier A. van Egmond and Charles Hoffman:

“Additionally, there is an ever-increasing number of “dialects” of XBRL being created. For example, the IFRS-GP, COREP, FINREP, US GAAP, and the FDIC taxonomy each has a different architecture.”

“Because of the missing solution components, each implementation of XBRL creates the missing components of the overall solution themselves, and usually in a different way. This causes the differences among dialects of XBRL.”

“XBRL runs the risk of fragmenting into a number of different dialects. While they will likely remain interoperable – because they are all structured information, but just structured differently – it will come at a high cost of consulting and development fees to achieve this interoperability in order to convert one dialect or architecture to another.”

Source: http://xbrl.squarespace.com/storage/xbrls/XBRLS-How-simpler-can-be-better-2008-03-11.pdf

The above opinions nicely summarize my own concerns with XBRL. From the “Business Reporting Logical Model” category on Charles Hoffman’s blog:

“I have been pushing the idea of using a logical model above XBRL's syntax and application profiles to make using XBRL easier for business users.”

Source: http://xbrl.squarespace.com/journal/2010/10/7/xbrl-for-the-future-xsb-releases-strategic-initiatives.html

This blog post was written in 2010 (3 years ago, as of this writing), which is 2 years after the initial whitepaper. I hope that progress has been made toward the goal of building a logical model on top of XBRL, but I find it difficult to ascertain the status of the XBRL industry, and the evidence I’ve shown from 2013 seems to indicate that this is not the case.

After reading a summary on each XBRL tool mentioned above, I’ve found that each tool claims to be easy to use, without any knowledge of XBRL. This is most likely true for those that need to use XBRL for reporting purposes. As long as each tool uses some dialect of XBRL and reports XBRL filings to the SEC, no other requirements are enforced. This situation results in no consideration for those that need to write systems to ingest all these different formats of XBRL, to be able to actually use the reported data.

Regarding the reporting standard definitions themselves, I feel like XML concepts are not being applied properly. For example, here are some XML tags defined in the US-GAAP XSD:

In some cases, would it not make more sense to apply the typical hierarchical model commonly found in nearly every markup language? For example, instead of these US-GAAP tags:

Could one not instead use a much more readable and practical hierarchy such as:

</AccountBalance>

</Operations>

</Investments>

</AccountBalance>

</Liabilities>

</ClosedBlock>

The above is by no means my suggestion of a real standard (since I’m not an accountant), but rather to illustrate that proper XML hierarchy could be applied in nearly any fashion and still be an improvement over the flat, overly-descriptive tag names, as shown above.

As you can imagine, the complexity of XBRL does not allow best practices to be intuitive or obvious to users of XBRL. There exists an XBRL Best Practices Committee, which publishes monthly updates to the most recent best practices guidelines for using XBRL. The latest best practices can be found here: http://xbrl.us/research/Documents/Resolutions-BPC.pdf. If you open the document, you will find (as of this writing) that the best practices document is 118 pages long. To me, this is a sign that a problem exists with the ease of use of XBRL, because of the need for such a long document on best practices.

In reading various XBRL websites over the past few years, I’ve noticed that some software development conferences or competitions have been held, in order to generate interest in the concept and prototype some workable software to encourage XBRL adoption. Calcbench was the winner of one such challenge: http://www.prnewswire.com/news-releases/xbrl-us-announces-grand-prize-winner-of-xbrl-challenge-developer-contest-140919833.html.

While it is good that there seems to be some interest in developing processing-side XBRL software (as opposed to reporting-side software used by reporting companies), I expected that after over 10 years of development, XBRL would be more widespread and well known. I can’t speak for other software developers that have attempted or succeeded in developing processing-side XBRL software, but I can say that for me personally, my motivation to use the standard could not overcome the standard’s complexity, incoherency, and difficulty of use. This could be one of the reasons that XBRL is less well known than I would expect, even though it is now mandatory in the United States.

When I gave some thought to what I think XBRL should be, I came up with a few ideas. In my opinion, first and foremost, XBRL should be more standardized than it currently is. Reporting standards should be standardized, XBRL extensions should be approved by a standards oversight body of some kind, and more commonly-used strategies and practices should be readily available out-of-the-box, as Charles Hoffman alludes to in his whitepaper. Each tool that claims to conform to XBRL standards should have to pass some sort of certification, to ensure that truly standardized output is produced by the tool. Reported XBRL data should be verifiable, and could possibly incorporate some sort of public key cryptography for authenticity purposes. Lastly, it would be highly useful to standardize on some sort of object-relational mapping to be used for converting XBRL data in XML form into a standardized database format, such as SQL. For more information on XML and ORM, see http://docs.jboss.org/hibernate/core/3.3/reference/en/html/xml.html and/or https://code.google.com/p/joxm/.

In conclusion, I feel that I’ve nicely summarized my concerns with XBRL. It is my opinion that the XBRL standards in their current form are not in a “production-ready” state that would be used for mandatory filings. I feel that XBRL needs further work and consolidation, and using it in production systems before that happens will only cause further pain down the road. There are data modelling practices that I feel could still be incorporated into XBRL to improve the deficiencies that I’ve mentioned in this blog post. I may write more in-depth blog posts in the future on the topic of XBRL, and I hope that the future is bright for digital financial reporting. XBRL is a powerful concept, and I hope that it will continually improve, to help reporters, processors, and developers of XBRL and its associated software.

Monday, October 7, 2013

Rules

If you haven't read this blog's "About" page, I encourage you to do so as a good starting point. The "About" page explains how I arrived at where I am today, in terms of blogging and lessons learned. Now that I've described (and you've hopefully read) how I got here, I'll explain a little about who I am and how I intend to write blog posts on this blog in the future.

My name is Mike, I hold a Bachelor of Computer Science degree with High Honours, and I am currently employed full-time as a software developer. As of October 2013, I have close to 4 years of experience in the software development industry. While this isn't much compared to some people, I feel that it will help to keep my career path in mind while reading the posts on this blog. It provides context in the sense that I'm relatively young and new to the industry, but have enough experience to not make a complete fool of myself with naive notions. My focus so far in the industry has been on C and the Microsoft Windows operating system. I also have some experience with C++, enterprise-level Java, and Python development. I've touched various other languages and technologies that aren't worth enumerating here, but may come up in future blog posts.

As I mentioned on the "About" page, I also have experience in value investing and the stock market. While this interest is more of a hobby and has never been supported by formal education, I look forward to including investing and finance topics in my blog posts on technology.

With my background out of the way, I want to state some rules for posts on this blog. These rules are more for myself, to be used as a self-check to make sure I'm sticking to my goals. I'll list them in point form below:

Blog posts must be coherent with a defined beginning, middle and end (rather than short posts with no insight or value).
Blog posts must be researched and contain citations to sources, where appropriate.
Blog posts must have a position or statement of opinion, if applicable.

I may add to this list in the future. I realize that there are a number of caveats that allow for wiggle room ("where appropriate" and "if applicable"), but the rules should hold in most cases.

Now that I'm ready to start writing blog posts, I wish myself luck and I hope that you find something worth spending your valuable time reading.