In this issue of The Institutional Risk Analyst we feature a comment on the XBRL pilot program at the Securities and Exchange Commission by Daniel Roberts CEO of raas-XBRL. First let's focus briefly on some related technical developments at the IRA HQ in Torrance, CA. Both of these data points directly impact investors, regulators and other consumers of financial data. And we feature a reader comment on the endgame of the private mortgage insurers at Fannie Mae and Freddie Mac, namely stuff the taxpayer.

IRA Launches XBRL Dynamic Renderer Test Site

The month of June 2011 marks when the US will begin the next wave of financial transparency. Under the SEC rule, a much expanded number of public companies will begin filing Forms 10-K, 10-Q and 20-F financial reports with Exhibit 101 Schedule supplements. That's the SEC descriptor for machine-to-machine data, also known as eXtensible Business Reporting Language or "XBRL."

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.

Experimenting to risk manage the technical path to making use of this treasure trove is the order of the day. There are already enough Exhibit 101's filed with the SEC to develop practical solutions, but usage has so far been low because of the immaturity of the data technology and subset coverage of SEC filers.

Institutional Risk Analytics has already worked with other machine-based data using the FDIC's Central Data Repository (CDR), which is already displaying dozens of Q1 2011 call reports for US banks just two weeks after the quarter close. Users of the IRA Bank Monitor see these filings and the related analytics in real time, including a preliminary rating. That same basic functionality hopefully will soon be realize by all users of SEC data.

We've been waiting for SEC Exhibit 101's to mature sufficiently to tackle this natural next piece of the puzzle. The time for live testing has arrived. The proof of the pudding in terms of the benefit of XBRL isn't in the talk, it's in the doing. And we are announcing that we have developed and brought to engineering test status our first software to generically render these SEC documents. The test site for the XBRL Dynamic Renderer is here:

http://us1.institutionalriskanalytics.com/xbrl_parser/index.asp

You 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.

And because we know consumers of financial information don't care how it got there, our technical design rule is that opening a document to read is limited to one-click maximum per drill in step. End users ultimately never need see the gymnastics of getting public data into their hands, not do they need to be told how to consume this data. That is the key dichotomy that the SEC must understand to make XBRL a success for filers, investors and also the agency itself. It is the enforcement and surveillance functions of SEC which are perhaps the most important consumers of SEC filings.

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.

Give IRA CEO Dennis Santiago a call at our HQ if you want to discuss solutions for testing or creating these documents. IRA has a growing number of relationships with companies that create compliant XBRL documents.

Private Mortgage Insurance Endgame: Stuff Fannie, Freddie and the Taxpayer?

We continue to get a lot of mail about our past two comments on private mortgage insurance. About 90% of the comments are negative with respect to the private MI sector generally and the banks with which they co-exist. Indeed, the banks get the worst of it. And as we noted before, the large banks are essentially driving the bus when it comes to the MIs fate. In that regard, this was by far the most interesting and best argued reader comment from an industry professional:

I know you have been critical of the Mortgage Insurance industry, for good reason I believe. I want to bring something to your attention that has more "hair" on it than it might appear at first glance.

On Friday (4/1/11) Freddie Mac put out a memo that warns seller/servicers about arrangements with mortgage insurers where the MI agrees not to rescind future claims and/or settles past rescissions under dispute in exchange for the seller/servicer agreeing to share in MI claims costs. See the link below.

http://www.freddiemac.com/sell/guide/bulletins/pdf/iltr040111.pdf

On the surface, this seems rather innocuous. However, I have some insight into the seller/service motivations in entering into these agreements. The benefit to the seller/servicer basically comes at the expense of the US taxpayer.

On the surface, this seems rather innocuous. However, I have some insight into the seller/service motivations in entering into these agreements. The benefit to the seller/servicer basically comes at the expense of the US taxpayer.

For some background, MGIC Investment Corp. ("MTG") revealed in a 10-Q filing last year that they had entered into such an agreement with a seller/servicer. I do not know who that seller/servicer is, though I have my suspicions, and to my knowledge this is the only such agreement entered into between any MI and seller/servicer so far. If there are any others, they must be with small seller/servicers. I would have heard about them and/or they would have been disclosed.

However, MTG has been very aggressive in pitching these agreements since the beginning of the year (I am not clear as to why, but I have heard from many top-10 seller/servicers that they have been approached by MTG in recent months). As far as I know, none of the other MIs are contemplating such arrangements, but if MTG is successful they are sure to consider them IMHO.

As Freddie's letter indicates, the basic pitch is this: MTG will agree to limit rescissions in exchange for the seller/servicer agreeing to share MI claims costs. Now, why would a seller/servicer find this attractive?

Basically, what MTG and the seller/servicer are betting on is that the investor (i.e. Fannie/Freddie), in the absence of the MIs oversight, will not have the resources to investigate the loan file and force a buy back. That's the big payoff.

Again, remember that the seller/servicer is not exposed directly to the MI rescission, their exposure is only a result of the subsequent buyback. Thus, eliminate the buyback and you save money.

As it works now, Fannie and Freddie automatically force a buyback when insurance coverage is rescinded on the argument that the loan no longer meets eligibility requirements without MI coverage. Often they don't even bother to investigate for fraud themselves. Fair enough - MI coverage is a loan requirement.

So that puts the seller/servicers in dispute with the MIs, over the appropriateness of the rescission.

By agreeing to curtail rescissions, the bet is that the buybacks stop, that Fannie and Freddie won't have the resources to investigate the defaulted loans themselves for fraud/misrep, thereby saving the seller/servicer money.

So in a nutshell, the MI saves money, the seller/servicer saves money, and the taxpayer is on the hook for a loss where fraud/misrep has occurred. Nice.

Besides the blatant ripoff of the taxpayer, there are several other issues I see with these arrangements. First, as you have pointed out before, where the hell are the state regulators?

The industry line the MIs have been towing in rescinding so many claims is that they are not statutorily permitted to cover fraud losses. Fair enough. So now how do they explain arrangements that blatantly pitch the fact that they will rescind less?

Sure, they may claim that they are not "knowingly" paying on fraud, because they are just not investigating as many loans, but that is a charade in my view, nothing more.

Second, the MIs are now fighting for their future in the QRM guidelines, with one of their arguments being they provide a "second set of eyes" on the origination and servicing of loans. But then they enter into agreements where they volunteer not to investigate loans? Am I missing something here?

Finally, this whole mess further highlights the prisoner's dilemma type messes that occur when you have multiple parties involved in the transaction. If there were only a seller and an investor, the relationship would be simpler. Once a third party like an MI is involved, you can have side deals like this occur where two parties try to screw the other parties involved, to their own benefit. The less parties involved the better, IMHO.

Anyway, I thought you might find this background interesting, as Freddie's announcement in and of itself was pretty obscure to the outside observer. What Fannie is really trying to address in my view is an attempt by MTG to rip off the GSEs and therefore the taxpayers.

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 daniel.roberts@raas-xbrl.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
By Daniel Roberts

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.

As SEC Chairman Christopher Cox can into office, with budget constraints and a system that was moving too slowly, he found an existing program in place exploring the concept of "tagged" data. Conrad Hewitt was an early supporter of the concept, and Jeff Naumann had already been brought over from the AICPA to explore the concept and if possible, provide a set of recommendations on how to move forward.

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.

And the SEC could only have been watching the FDIC with envy.

Mandate

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.

In 2008, the proposed rule was issued and subsequently voted on to become the final rule, with it's three year phase-in. In 2009 the first XBRL instance documents began to arrive at the SEC. Giving the SEC credit, the estimated cost of implementation per company for first year (non-detailed tagged data) was up to $80,000. A review after the first year found the experiences of companies to be very close to that level of cost. The SEC had no idea what the cost of detailed tagging would be. In the two years since the first companies provided XBRL, costs have come down, the software has become much better, but there remains a chronic shortage of skilled XBRL specialists.

Who benefits?

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.

If we help the markets to identify the Madoff, Enron and WorldCom outliers before they cause too much damage, just like the TSA attempt to stop the terrorists from getting on the planes in the first place, then we have moved the ball forward in terms of preventing negative events in the marketplace that truely functional transparency might help avoid.

Questions? Comments? info@institutionalriskanalytics.com