Chrisher Whalen is -founder of  Institutional Risk Analytics (IRA) and provides nsulting services for auditors, regulators, and financial professionals. He edits The Institutional Risk Analyst, a weekly mmentary on the institutions and financial markets that mprise the global political enomy. He ntributes often to publications like the New York Times and Barron’s and appears regularly on BC. He has testified before the US ngress on a variety of financial issues.

1. In an interview with this blog about a year ago, Neal Hannon said:

The biggest underreported story about XBRL in the US is the FDIC. During the recent financial crisis, the almost two years’ worth of quarterly data llected in the XBRL format has given the Treasury Department valuable insight into which financial institutions have suspect holdings.

Others have taken a more skeptical view, which at the extreme may be stated as “If the FDIC implementation was so great, why didn’t it do anything to s the financial crisis?”

What do you think? What are reasonable expectations for the role data standards in general and XBRL specifically can play in providing stability to financial systems?

Neal Hannon is entirely rrect that the implementation of XBRL and other technologies by the FDIC has revolutionized the llection, validation, and distribution of bank Call Report information. But as my partner Dennis Santiago often notes in XBRL discussions, information llection is only half the job. Analysis, judgments, and decisions still need to be made downstream of the data repository. Whether or not regulators and politicians in Washington do the right thing when it mes to public policy choices has no direct relation to using XBRL to increase data transparency and aessibility, which is still the exception rather than the rule in most untries. The FDIC’s data llection effort inclusive of XBRL is the finest such public data resource in the world and is virtually free of errors. Sadly, this is the exception to the general state of non-disclosure in many industrial nations,  even major nation states in Europe and , where there is no public right to know. The FDIC data is a very unique resource, and XBRL is just one of many tools employed by the FDIC to make it truly world class. 

I don’t understand the objections raised by people that say “XBRL didn’t do anything to s the financial crisis.” Such statements reveal an uninformed and self-serving world view that is refuted by the facts. Dennis and I have been looking at and analyzing superbly llected and disseminated FDIC bank data since 2003; but it must be said that the FDIC’s attention to data quality has been around a long time, decades in fact. Anyone who follows our work knows that we, along with many others, have been calling attention to the problems in data quality in many financial markets. Not everyone was deluded by the sloppiness. Nassim Taleb rightly aused the financial mmunity of this in his “Black Swan” indictments. The reality is the mmunity nspired to make the markets even more opaque and less transparent, thwarting the basic premise behind efforts such as XBRL, namely that everyone wants greater transparency.

For example, had the data tagging, llection, and distribution protols of XBRL been adopted in areas such as residential and mmercial mortgage loan securitization and OTC derivatives, they might indeed have been made more apparent and large portions of the financial crisis might have been averted. But that wasn’t in the business interest of the purveyors of these instruments. Remember, virtually all of these toxic securities were brought out as “private placements” via Rule 144A and are thus not registered with the SEC. So criticisms of XBRL for not helping to prevent the financial crisis in this respect are quite outrageous. My hope is that in the future, perhaps through the adoption of new regulations on bank securitization by the FDIC, we will see mandated public disclosure of all OTC securities and derivatives.

These problems of opportunistic opacity ntinue to this day. Look at the way that the International Swaps and Derivatives Association (ISDA) and the OTC dealers are dragging their feet on the standardization of FPML, the XML dialect chosen for tagging OTC derivatives transactions, and you can see the root of the problem. We have created a culture of deception and ncealment in our financial industry that seeks to hide price and other data from the public to maximize monopoly profits from trading OTC securities and derivatives. The entire retrograde nstruct of OTC derivatives and securities is ripe for revolution when it mes to using XML dialects such as XBRL to make these data sets available to investors and the public. I think that is a very exciting and positive message for the XBRL mmunity and for public policy in general, but this great technology is also a threat to many entrenched nstituencies in the banking world who hate transparency and fear greater openness. 

2. In a post you wrote for this blog about three years ago, you did discuss the benefits of the FFIEC implementation of XBRL for Call Reports and noted that “…the data llection and validation tasks are clearly a big winner and have saved [the FDIC] enormous amounts of money and man hours in terms of llecting financial statement data from US banks.”

But you also said that the argument for XBRL was strongest at the “upstream,” agency level; in relative  terms, the business use case at the “downstream,” end-user level was “not yet mature enough and powerful enough to withstand the critical scrutiny of business case needs.”

With respect to the FDIC, do you still hold that view?

Yes we certainly do ntinue to hold to the view that the use case optimization of both “upstream” and “downstream” technologies follow separate disvery paths. This point is borne out in the real world. There is absolutely nothing wrong with insisting that regulatory reporting and data llection ntinue to beme more structured via some anizing nstruct like XBRL while at the same time insisting that the downstream delivery of information from those central libraries to the many types of analytical engines used to support decisions remain as diverse and multilingual as possible.

The actual operational implementation of the Central Data Repository (CDR) by the FDIC validates our judgment about the benefits of XBRL to the process of llecting, validating, processing, and then distributing this data to a myriad of different nsumer groups. If we trace the production and use case process, those benefits beme obvious. Upstream the benefits are equally dramatic. They manifest as efficiency and quality improvements.

First, think of the FDIC-insured banks using the XBRL template to submit their Call Reports to the FDIC. The logic in the XBRL taxonomy allows the supervisory personnel at the FDIC to identify and rrect any errors that may be made in the filing process.  Anomalies are flagged and, where appropriate, are then subject to additional supervisory review. The process is transparent enough that we can observe it in real-time on the FDIC web services system. The benefit of XBRL has been to greatly increase the productivity of the review process and decrease st in terms of personnel, and also improve auracy to the point where input errors are basically eliminated. This issue of auracy is of crucial importance to our firm, because we serve more than 20,000 retail nsumers who use our automated bank ratings to inform their individual and rporate asset allocation choices in terms of bank depositories. It’s even more critical for bank unterparties who need to determine whether to extend business credit to a bank or demand payment in cash. And finally data mpleteness and timeliness at one regulatory agency, the FDIC, is what enables us to deliver powerful benchmarking services to other agencies, such as the SEC, to perform their mission.

Next, there is internal processing to meet a variety of internal and external nsumption needs. The data in the XBRL files is parsed into numeric data to support several dozen internal supervisory and reporting applications within the FDIC and other agencies in the FFIEC. Some of these use cases involve modern desk applications for data analysis, while others feed legacy mainframe data applications that literally go back a quarter of  a century and often feed single use case needs that are driven by law and regulation. Then we have several version of the data, including XBRL documents and legacy CSV outputs that are tailored to meet the specific mmercial needs of external rating agencies like us as well as the research and policy needs of ernment agencies and cational institutions. The FFIEC CDR downstream service layer supports PDF, CSV with a filename suffix of .SDF, and XBRL. Of interest, my partner Dennis notes that the downstream delivery standard evolving across the multiple ernment agencies we keep track of these days is steadily headed in the direction of PDF for reading by humans and flavors of CSV for interfacing machine-to-machine. Additional popular flavors include XLS for small data sets, SAS XPT for statisticians, and plain vanilla-XML as a verbose substitute for CSV.  In all cases, the downstream analyzers have little need for the perfect acunting mpliance and categorization nstructs of the XBRL llection layer. These users quite reasonably demand the data is cleaned of such overhead before it ever gets to them so they can perform their work with optimum productivity.

Finally, there is public distribution. If you look at the way in which a firm like ours nsumes the FDIC data, the point regarding upstream versus downstream benefits bemes clear. Our primary need regarding the use of FDIC data is the calculation of arithmetic relationships and metrics to drive our bank performance and ratings model, The IRA Bank Monitor. We nsume the FDIC data in two ways. 

First, we gather the bank Call Reports dynamically from the FDIC CDR facility in real time and harvest the data into a database structure that allows us to calculate preliminary ratings for a particular bank unit. The enablement by XBRL-based data llection has an enormous benefit here in terms of auracy and timeliness, and has cut several weeks off of the waiting time for aessing many bank Call Reports. The preliminaries appear in the same timeframe as the SEC K/Q filings. We actually use the CSV output format from the FDIC.  It’s purely a machine efficiency decision. Given known good data, one is actually indifferent to the format in which it’s delivered.  The processing time is easily an order of magnitude faster for database injections with CSV than with XML. Remember that our firm is running individual and peer group level analytics on thousands of banks per quarter in an SQL environment, so the efficiency of the data transport and calculation regime is critical to providing a data analytics product that is up to mmercial grade for both institutional and nsumer users. 

The send part of our data llection process involves the importation of the entire body of data from the FDIC in a legacy format which essentially recapitulates and nfirms the CDR data we have already llected. We process all of the data, metrics, and ratings for the entire universe of FDIC-insured banks and then finalize the results for that quarter.  As I write these mments, it is the first week in February 2010 and we have llected about 7,500 Call Reports from the FDIC CDR. Of interest, the CDR also enables us to calculate and publish a preliminary Bank Stress Index (BSI) rating for all of the banks which have reported to far, providing our clients and readers of our free mmentary with aess to data about the ndition of the US banking industry several weeks before the FDIC press nference. Since timeliness is the key data nsumption priority  for most investors, the decrease in wait time due to the implementation of XBRL by the FDIC is a huge win for nsumers of bank data and ratings.

IRA Preliminary Bank Stress Index (BSI) Grade Distributions — Q4 2009