Private Mortgage Insurance Endgame: Stuff the Taxpayer; Dan Roberts on the Past and Future of XBRL at the Securities and Exchange Commission
April 12, 2011
IRA Launches XBRL Dynamic Renderer Test Site
As Dan discusses in his comment, much effort is being expended to get companies prepared to submit these filings. As this happens, the downstream analysis community must begin our work to actually make use of this repository of machine readable public data. Theoretically anyone will then be able to download and use these evidentiary grade documents, either for visual inspection via the web or to electronically harvest the numeric information in a machine-to-machine transfer.
Prior to this, machine readable public filings data came via 3rd party vendors and with all of the attendant errors and proprietary formatting that comes with human intervention. There is a reason why people are no longer even allowed inside the most advanced manufacturing facilities except to conduct maintenance. The direct path to the SEC's data offers the potential of a far more direct and reliable connection for consumers of EDGAR data and with the enabledment of machine-to-machine data transmission in real time. The in-depth look at companies for both investment analytics and regulatory purposes enabled by XBRL should help both investors and the SEC itself do a better job of understanding data by harnessing the power of machines to read the data.
http://us1.institutionalriskanalytics.com/xbrl_parser/index.aspYou are looking at actual SEC filings requested from the EDGAR servers via the IRA SEC Catalog tool. Remember the XBRL Dynamic Renderer is an engineering version - bugs and all. Not all SEC filers are submitting XBRL files and there is still no final standard for many of the data elements "tagged" in this dialect of XML. But like many things IRA, we are inviting you to participate in our work to understand the nuances of dealing with the many soft and squishy details of seamlessly read filings from any submitter.
Like last year's innovation phenomenon, the IRA "Move Your Money" zip code bank finder tool that powered the Huffington Post's consumer education campaign, this tool is all about making SEC data available broadly and transparently to the public. This year IRA is also focusing on coding approaches anticipating the increasing migration of internet users to mobile apps.
The methodology behind our experiment goes beyond just looking at the SEC's servers. This tool is also meant to be useful for testing filings still being prepared at a vendor or company to do readability confirmations and usability tests prior to official submittal. IRA's XBRL Dynamic Renderer is also meant to work with privately stored libraries of exhibits, something we are discovering is needed outside the United States where corporate documents are not typically stored in government owned public domain servers.
Private Mortgage Insurance Endgame: Stuff Fannie, Freddie and the Taxpayer?
Now we turn to a feature by Dan Roberts, the past Chairman of the XBRL US Steering Committee and member of the XBRL International Assurance Working Group. He has been active at the heart of XBRL since 2003. He is the CEO of raas-XBRL, an XBRL production company that takes the complexity out of compliance with the SEC's XBRL mandate. Dan can be reached at email@example.com, or you can visit the company site at www.raas-XBRL.com. He blogs on XBRL and Sustainability issues at http://raasconsulting.blogspot.com.
Looking back, looking forward - the SEC's XBRL program
The US Department of Homeland Security now requires all airlines to provide a list of all US bound passengers before the airplane takes off from its originating airport. Why? Because waiting until the plane arrives to screen for potential terrorists or threats is wasteful. The information upon arrival may be accurate and complete, but it is no longer timely.
Financial reporting to the markets is much the same, with audited annual reports and quarterly reports being provided to the SEC (and through them to the investor community) - in effect after the plane has landed. By the time the information is provided to the SEC, it may be accurate and complete, but it is no longer timely. The immediate buy-sell-hold recommendations and actions have already taken place at the time of the earnings release, and sometime before. In fact it is difficult to find anyone that actually looks at a 10-K in detail.
In 2008 the SEC proposed a rule requiring registrants to provide XBRL (eXtensible Business Reporting Language) versions of their annual and quarterly reports (10K and 10Q) and for foreign filers to provide XBRL versions of their 20-F or 40-F filings. In 2009 the final rule was passed (33-9002) ( http://www.sec.gov/rules/final/2009/33-9002.pdf ) that created a three-year phase-in based on market capitalization and filing status of each registrant.
This new reporting requirement was sold by the SEC as a step forward for the investors, by reducing the effort required to consume information (no more parsing of HTML or text documents) and improving quality of information reported (by removing manual re-keying errors). After all, if information can be consumed at the data element level, with a 'tag' telling the consuming computer what that piece of data is, then the entire process becomes quicker, cheaper and more accurate.
The dream is great, the reality is additional reporting burden and cost for little visible benefit. And this is where the SEC can and should be focusing its efforts - demonstrate and communicating the benefits of XBRL, and push for greater adoption earlier in the reporting process. Because "Interactive Data" as the SEC calls XBRL, can deliver real time and cost saving, companies should be looking for ways to exploit the additional reporting power that XBRL provides, and the SEC should be fine tuning their program.
A Short History
To find the origins of the SEC's XBRL program we need to go back to the grim days after Enron and Worldcom and the introduction of the "Full Employment in the Accounting, Auditing and Consulting Professions Act", also known as Sarbanes-Oxley (SOX). Numbers - 302 and 404 - became the newest form of torture out of Washington. CEO/CFO certifications of the effectiveness of Internal Controls ensured that no matter the economy, the auditors (and consultants) would be busy, for at least a few years through implementation and the first couple of years of operations.
But buried in SOX was another number - Section 408 - which requires the SEC to review all filers not less than one every three years, and many filers every year. The highly manual (all right, manual takes on a new meaning when it means copying and pasting data from documents into spreadsheets, but none the less, by today's standards that is manual) processes at the SEC meant that these review requirements were simply unachievable. Something was needed, and the idea of tagged data, directly consumable by systems to automatically populate analytic engines looked, and still looks like just the answer to this problem.
As an aside, when I asked a senior SEC official what they would say if Congress asked them if they were complying with section 408, he answered "Dan, we would look them in the eyes and say 'Yes, of course we are complying'." Then he smiled.
Of course, the SEC didn't need SOX 408 to know that they needed to do something. They wanted to find the next Enron or Worldcom before a whistleblower or counterparty discovered it for them, the hard way. They knew they needed to do something, and the forward looking leadership began to press for improving the use of the information they already receive, or changing if necessary the format of the information received.
At the same time, Jon Wisnieski at the FDIC (in conjunction with the FFIEC and OCC) was developing the new CDR project to upgrade the Call Report process. This project pushed XBRL out into the Call Report production software used, at that time, by 8200 banks across the United States for their quarterly reporting.
The XBRL component of the CDR project went live in late 2005 and saw immediate benefits in terms of the quality of information reported to the FDIC, and dramatically reduced the overheads at the FDIC for analysis of banks. Reporting times dropped, data quality jumped almost overnight, with the number of banks that received queries from the FDIC each quarter dropping from around 35% to 5%.
The same information, or a subset of that information, was then made available to the investor community through feeds from the FDIC, in one of three data formats, two compact legacy formats as well as the full XBRL document. IRA uses those feeds from the FDIC (but not in the XBRL format) to populate their database and feed their bank analytics and ratings. The key here is that the fact of XBRL in gathering, characterizing and validating the bank reports enables a multiplicity of data output choices for consumers.
So in the heady days after the successful FDIC implementation, Barry Melancon at the AICPA received a call from Chairman Cox asking for a letter outlining the steps the SEC could and should take to implement an XBRL program.
The timing could not have been better, as on the day of the call, an internal meeting at the AICPA took place in which one of the discussion items (informal of course) was when and how to wind up the AICPA's direct involvement in XBRL and when to sack the AICPA's Director of XBRL. It does not take much to imagine a possible change in tone, from "how do we reduce this overhead" to "how do we maintain control over the XBRL movement".
As Chairman of the XBRL US Steering Committee at the time, the change was easy to see. One week the question from the AICPA was "can we spin off XBRL in 6 to 9 months?" Soon that had morphed into "we think it might take a couple of years to spin off XBRL into an independent entity." So a letter was written to Chairman Cox outlining the steps that the SEC could take to position itself to implement XBRL.
The first and most important step was completion of the US GAAP taxonomy, which at the time was being built by dedicated volunteers, and simply was not ready. As Liv Watson of EDGAR Online said, an "Industrial Strength Taxonomy" was required.
And so it was.
In September 2006 Chairman Cox again called Melancon and this time asked how soon an independent XBRL entity could be established to be the contractor to build that industrial strength taxonomy, and could that new entity provide a proposal to the SEC for the development of the taxonomy.
I've left out a number of steps that took place in between the letter and the call, including a meeting at the SEC in which I was asked how much the taxonomy would cost. My answer then was that I had been told by the Taxonomy Working Group that it would cost $4.5 million. The answer I got was "That's too bad, if it was a hundred million it would be easier to get appropriated than $5 million - that's just the way Washington works."
None the less, as part of an EDGAR system upgrade program, the SEC budgeted $5.5 million for the XBRL US GAAP taxonomy, with the contract to be fulfilled by the newly created XBRL US Inc.
With the coming change in administration at the White House, or at least an assumption of a coming change, it was clear that if Chairman Cox was going to get the credit for modernizing the reporting environment, an XBRL proposed rule would be needed, and a final rule voted on by the Commission by late 2008.
The clock was ticking.
At the same time, the Pozen Committee, while supporting the introduction of XBRL, recommended a phased in approach. The Committee's concerns turned out to be spot-on. Was there adequate software available in the market to use pure XBRL documents? Were there an adequate pool of resources that understood XBRL file creation? Most important, would the cost to filers be comensurate with the benefits and thus acceptable? But the ghost of SOX haunted the program.
So now the largest 1500 public companies companies across America are producing and providing XBRL versions of their financial statements to the SEC. In addition, some companies are using XBRL as the opportunity to improve their internal reporting processes, pushing XBRL farther back into their reporting systems. United Technologies ("UTX") is a good example, having used XBRL as the catalyst to improve their external reporting processes, saving over 800 person hours per quarter (before the detailed tagging requirement, but that is a different issue).
The other 8700 companies (the number estimated by the SEC in the "final rule") will be providing XBRL for the first time with their second quarter 2011 filings - their 10Qs due on August 15th. Foreign filers filing in IFRS will be providing their 20-F or 40-F filings in XBRL starting with their 2011 annual reports, provided the SEC approves the IFRS taxonomy.
So other than those companies using XBRL to re-engineer their external reporting process, the primary beneficiary today is the SEC. As mentioned in the introduction, the investor community has yet to demonstrate significant interest (other than pockets here and there) in XBRL, simply because the information while complete and accurate, is not timely. It is timely for the SEC, as their analysis is based on the audited and reviewed financial statements, not on the earnings release. Of note, a separate mandate requires Mutual Funds to provide the risk and return summary in XBRL, beginning January 2011. These filing are already arriving at the SEC.
I'm not certain if the SEC is happy that the mandate is coming to full fruition, or if this actually fills them with greater trepidation. After all, it is now expected that they will find the next Enron, Worldcom or Madoff, and that means they need to actually exploit the data that they now collect. The current budget crunch at the SEC is severely impacting their ability to impement the systems that will enable Corp Fin to actually take full advantage of the XBRL tagged data. Mind you, we have also been hearing for years that "Corp Fin" is THE roadblock to effective exploitation of the data. Too many vested interests, and too little vision.
So today the primary beneficiary of XBRL, if there internal processes are keeping pace with the data, should be the SEC.
Who pays, and how much?
Of course the SEC's benefit is not coming for free, and businesses are having to pay for it, in the form of production of XBRL versions of their filings. Estimates run anywhere up to $40,000+ for external providers to produce the XBRL, exclusive of internal time. One vendor is telling companies to expect up to 125 person hours of external resource support, plus internal resources.
At the other extreme, there is software on the market for as little as $995, though who knows how much actual time and self training will be required to produce an acceptable set of XBRL documents using that software.
As Douglas Chia, Assistant General Counsel and Corporate Secretary at Johnson & Johnson ("JNJ") said in his letter the SEC (19 Oct, 2010. "Our first-hand observation is that the time and expense for registrants to comply with these requirements have gone far beyond what anyone expected in 2008 and the benefits of XBRL have yet to be measured. We urge the Commission to conduct the study necessary to understand what, if any, benefit there has been to investors from XBRL and, if there has been a benefit, who has been the primary beneficiary."
And in terms of Investor use of XBRL, the recent letter from Hallador Energy ("HNRG") CFO Andy Bishop is far harsher, almost to the point of being worth reading as a bit of humor. At one point he says: "Our company is not followed by any analysts and I doubt if any of the other 5,000 companies are either. Investors who are interested in purchasing our shares could give a rat's rear-end about whether or not we file using XBRL." And this in a letter to the SEC.
Let me go a step further - the only beneficiaries of detailed tagging (as much as a ten fold increase in data tagged, and a reported six tiems the cost for some files) are the consultants who are engaged to produce the mapping and tagging. Until the SEC can demonstrate the benefit that is achieved in greater transparency and usability of the data, it is a waste. For example, can anyone provide any demonstration of any value from a detail-tagged filing by Goldman Sachs ("GS"/Q4 2010 Bank Stress Rating: "A+") in which 67% of all reported data elements are custom extensions to the US GAAP taxonomy?
Basically, the provider pays, and the users benefit. But then, this is a regulatory mandate, and that does seem to be the way with regulator mandates. The only good news is that prices will come down, the capability will be built into virtually all software in the coming years, and it is possible to find ways to use this transition to improve the quality of companies' reporting.
The bad news is that the SEC is not making enough noise about demonstrating the benefits that they are achieving through this mandated additional burden. And with the SEC's budget being limited, and with inadequate investment in information technology, it would be scary if the XBRL program did not receive the funding needed to actually deliver on the promise.
The way forward
So I'll propose some ideas that I hope will improve the adoption and utility of XBRL (or Interactive Data) and the mandate.
1. The SEC should communicate the efficiencies that they are achieving through the collection and use of XBRL tagged 10-K and 10-Q (and Mutual Fund) data. The FDIC was able to clearly demonstrate the benefits they achieved in reduced error rates and increased number of institutions per analyst. The SEC should be able to communicate the benefits they are achieving.
2. The SEC should be looking for mechanism to reduce the cost to the provider of the data, and push the costs onto those that benefit from the XBRL - the analyst community. This means providing the ability to purchase full data-sets of XBRL data for all filers, with feeds that provide a constant update of the database. This conflicts with the idea that the information is public, so free public access must be maintained, as it currently exists through twitter / RSS feeds announcing each XBRL filing, and through the EDGAR system. While there may seem to be a conflict, bulk consumers of data are different from retail consumers, and they should carry a different cost for the data. That income could then be used to offset some of the production costs, either through a reduction in the SEC levy or through direct financial incentives for early filing - for example.
3. Scrap, or at minimum defer the detailed tagging requirement for smaller filers - the "group 3" or "year 3" filers. Already the first and second year filers are providing "detail tagged" data, and the market is seeing a 6+ fold increase in the workload required to create these filings. When one considers that the cost today is around $20,000, that pushed costs up well over $100,000 per filer. That is a burden that smaller filer simply cannot afford.
4. Expand the US GAAP taxonomy to include all information in the 10-K and 10-Q (and other mandated filings). Provide full taxonomy coverage for the MD&A for example. and the auditors report. Also, to a point made often by IRA in their work with EDGAR, include all corporate filers in group 1 & 2 to provide coverage of unlisted companies and other filers investors, auditors and other consumers do care about but commercial feeds largely ignore.
5. Require assurance over the XBRL, but work with the AICPA and the market to create realistic assurance options that will not add the $25,000 - $50,000 that we are seeing for an "Agreed Upon Procedures" review (not even an audit) of the XBRL. Until such assurance is possible at a far more reasonable price, extend the compliance relief by an additional 1 or 2 years.
6. As above, additional data streams should be brought online to make the EDGAR data tagging effort comprehensive and thus economically viable for SEC and vendors to invest in enabling technologies. Eventually, the full range of SEC filings and forms should all be provided in the most business case efficient XML dialect. On the one hand this would seem to be a call for additional costs to business, but in the medium to longer term will drive down costs by encouraging consolidated compliance environments.
7. Expand the US GAAP Taxonomy to include the information that is included in Earning Releases, and encourage companies to provide XBRL instance documents with their earnings release. After all, it is not good enough for the data to be complete and accurate, it must be timely.
The bottom line is that the utility of XBRL is as much about helping the SEC do its job better, cheaper and faster than current tehcnology allows. By using the type of simple survey methods used by IRA in their bank and non-bank tools, the SEC could actually identify outlier behavior in real time. This is not the holy grail, merely the logical application of contemporary technology to meet a public policy goal and enable the SEC's work process in such a way to get that job done.
IRA offers advanced analytics for risk surveillance and investment research via subscription products such as the IRA Bank Monitor for Professionals covering the US banking industry and the IRA Corporate Monitor covering public companies. For a trial subscription or an on-line demonstration, please register here.
IRA Advisory Services including our channel research and diligence support services are available to qualified clients. For more information, please contact our offices.IRA for Consumers
IRA provides consumers easy to buy online reports to independently check on their banks via our How's My Bank? system.IRA on Web 2.0
For updates during the week please follow IRA www.twitter.com/IRABankMonitor.
The Institutional Risk Analyst is published by Lord, Whalen LLC (LW) and may not be reproduced, disseminated, or distributed, in part or in whole, by any means, outside of the recipient's organization without express written authorization from LW. It is a violation of federal copyright law to reproduce all or part of this publication or its contents by any means. This material does not constitute a solicitation for the purchase or sale of any securities or investments. The opinions expressed herein are based on publicly available information and are considered reliable. However, LW makes NO WARRANTIES OR REPRESENTATIONS OF ANY SORT with respect to this report. Any person using this material does so solely at their own risk and LW and/or its employees shall be under no liability whatsoever in any respect thereof.
A Professional Services Organization
Copyright 2013 - Lord, Whalen LLC - All Rights Reserved
371 Van Ness Way, Suite 110 Torrance, California 90501 310.676.3300 firstname.lastname@example.org