Christopher Whalen is co-founder of  Institutional Risk Analytics (IRA) and provides consulting services for auditors, regulators, and financial professionals. He edits The Institutional Risk Analyst, a weekly commentary on the institutions and financial markets that comprise the global political economy. He contributes often to publications like the New York Times and Barron’s and appears regularly on CNBC. He has testified before the US Congress 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 collected 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 stop 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 correct that the implementation of XBRL and other technologies by the FDIC has revolutionized the collection, validation, and distribution of bank Call Report information. But as my partner Dennis Santiago often notes in XBRL discussions, information collection 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 comes to public policy choices has no direct relation to using XBRL to increase data transparency and accessibility, which is still the exception rather than the rule in most countries. The FDIC’s data collection 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 Asia, 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 stop 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 collected 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 accused the financial community of this in his “Black Swan” indictments. The reality is the community conspired 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, collection, and distribution protocols of XBRL been adopted in areas such as residential and commercial 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 continue 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 concealment 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 construct of OTC derivatives and securities is ripe for revolution when it comes 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 community and for public policy in general, but this great technology is also a threat to many entrenched constituencies 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 collection and validation tasks are clearly a big winner and have saved [the FDIC] enormous amounts of money and man hours in terms of collecting 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 continue to hold to the view that the use case optimization of both “upstream” and “downstream” technologies follow separate discovery paths. This point is borne out in the real world. There is absolutely nothing wrong with insisting that regulatory reporting and data collection continue to become more structured via some organizing construct 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 collecting, validating, processing, and then distributing this data to a myriad of different consumer groups. If we trace the production and use case process, those benefits become 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 correct 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 cost in terms of personnel, and also improve accuracy to the point where input errors are basically eliminated. This issue of accuracy is of crucial importance to our firm, because we serve more than 20,000 retail consumers who use our automated bank ratings to inform their individual and corporate asset allocation choices in terms of bank depositories. It’s even more critical for bank counterparties who need to determine whether to extend business credit to a bank or demand payment in cash. And finally data completeness 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 consumption 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 desktop 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 commercial needs of external rating agencies like us as well as the research and policy needs of government agencies and educational 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 government 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 accounting compliance and categorization constructs of the XBRL collection 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 consumes the FDIC data, the point regarding upstream versus downstream benefits becomes 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 consume 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 collection has an enormous benefit here in terms of accuracy and timeliness, and has cut several weeks off of the waiting time for accessing 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 commercial grade for both institutional and consumer users. 

The second part of our data collection process involves the importation of the entire body of data from the FDIC in a legacy format which essentially recapitulates and confirms the CDR data we have already collected. 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 comments, it is the first week in February 2010 and we have collected 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 commentary with access to data about the condition of the US banking industry several weeks before the FDIC press conference. Since timeliness is the key data consumption priority  for most investors, the decrease in wait time due to the implementation of XBRL by the FDIC is a huge win for consumers of bank data and ratings.

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

Quarter Ending 12 09	A+	A	B	C	D	F
PRELIMINARY Sample count =7,278 Average BSI 8.00	2,066	1,421	704	810	64	2,108
Prior Quarter Ending 09 09 sample count = 8,543 Average BSI 4.44	3,308	1,481	410	429	77	2,337

Source: FDIC/IRA Bank Monitor

3. What is your overall opinion of the SEC’s XBRL mandate in terms of the burden it places on business and its usefulness to both agency personnel and end users?  

My view of the current tagging regime at SEC is that this is still a work in progress. As a bank analyst who covers over 20 publicly traded financial institutions, I don’t find nearly the same level of utility in the XBRL-tagged documents on the SEC website as I do using the bank level data from the FDIC, which as I’ve explained we have implemented into a complex model of metrics and ratings. In essence, all of my work in terms of bank unit analysis is “ready to eat” because of the way in which my partner Dennis has leveraged the upstream tagging and characterization power of XBRL to enable our downstream analysis systems. But by the time we reach the consumption phase, we are using tools like SQL to analyze subsets of the XBRL submissions, primarily the numeric values and pre-calculated metrics provided by the FDIC, instead of consuming the entire XBRL document.   

When my analysis work turns to looking at the SEC filings for Citigroup or Goldman Sachs, for example, the tagged documents on the SEC website are fun to play with and provide some utility in terms of display. Ultimately, however, the tagging of footnotes and data elements in the XBRL files on the SEC site are not yet saving me much time in terms of overall work process. Compared with the highly automated analytics possible with the FDIC data, the SEC disclosure is what we call “chopped salad” in the financial data world. The key issue here is that XBRL and the related accounting taxonomy have not changed the fact that each bank I cover is allowed under GAAP rules to vary their presentation of results in some very significant ways. Whereas the FDIC bank unit data is tightly defined and reasonably consistent, the presentation of bank financials under GAAP is far more subjective – and deliberately so! Public disclosure is not a photograph or x-ray of a company’s financial performance, but instead is closer to an oil painting, with or without XBRL.   

So if I were to line up the most recent 10-Qs from Citi, Goldman, and Morgan Stanley side-by-side, you will find some very significant differences in how key elements are described, defined, and presented, such as off-balance-sheet vehicles and the way in which losses from these activities are disclosed. Some banks charge-off loss via the loss reserve account, others bury the losses as non-interest expense.  The fact of tagging of footnotes always is several quarters behind the current state of the art of investor relations at my banks. So since we cannot yet seem to keep the XBRL taxonomy current with the ways in which banks are allowed to disclose (or not disclose) material aspects of their financial performance in the current reporting period, the human brain and the Excel spreadsheet remain the most effective tools for working with SEC filings.

4. In his January 2009 whitepaper Bringing Transparency to the Mortgage-backed Securities Market, Philip Moyer of EDGAR Online describes the benefits he believes XBRL in a centralized MBS reporting system would bring, including better data quality, historical comparability, and reduced reporting costs (see pp. 17-18).

How useful do you think XBRL can be in bringing transparency to the MBS and other securities markets that have been at the heart of the financial crisis?

As I indicated in my earlier comments, the use of XBRL or perhaps another XML dialect is obviously attractive. My partner Dennis, who started his career in finance in the fixed income modeling world by installing an MBS software package in the Pasadena offices of Countrywide in 1991 after a decade at Rockwell International, thinks XBRL might be both overkill and undergunned for this purpose. He thinks a simpler XML structure suitable for easy integration by servicers would suffice for collateral data reporting in MBS.  And he thinks deal rule modeling — that can involve complex mathematics – might be better served by adapting from techniques pioneered by the Department of Defense community. Like most of his peers in the world of data operations, Dennis is pragmatic about using the right hammer for the right nail, because (1) cost and (2) production efficiency are the two key criteria in the world of big time securities clearing and data processing. 

Given the relatively less complex nature of the information to be gathered, you could probably develop an XML-variant that was both complex in its vocabulary but relatively easy to transport compared with say an XBRL document filed with the SEC by a public company. In fact, there are already a number of well-tested XML dialects in use in the world of securities trading and clearing, so my guess is that the DTCC and other financial institutions would default to the version of XML with the least overhead cost.  Remember that the Fedwire and private processing systems are part of a highly developed, highly-automated market where XML is very familiar and timeliness and per unit processing costs are the overwhelming priorities. So I would not suggest that XBRL US spend a lot of time trying to sell itself to the clearing community. 

5. Your December 2009 paper Is It Possible to Re-Privatize the US Financial System? traces the growing role of government in US banking over time and discusses the creation of an “Alliance of Convenience”:

  “…Our spendthrift government, the Federal Reserve System and the TBTF [too big to fail] banks together now comprise the paramount political tendency in America today… Until we break the Alliance of Convenience between the Congress, the Fed and the large, TBTF banks and force our public officials to embrace core American values regarding transparency, insolvency and accountability, we will not in my view find a way out of the crisis.

Clearly this muddle requires much more than an XBRL solution. But do you see a role for XBRL in helping to provide the required transparency?

No, the data from the Fed and Treasury is pretty transparent and is actually tagged already with some relatively simple versions of XML. The Fed, for example, makes all of its financial data available in a statistical version of XML. The one area where an XML dialect like XBRL might be useful is the OTC dealer community, but as already noted, the FPML dialect of XML has already been selected by the dealers for tagging OTC derivatives and complex structured securities.

The real trouble here has nothing to do with the data itself or the structure. The problem is that the data is not public and the dealer banks do not want to standardize these financial instruments nor the XML-dialect used to report on them because doing so would impair their monopoly power over the OTC market. As in the case of SEC disclosure, it is always important to remember that the predominant tendency on the part of human beings is to limit disclosure and thereby increase pricing power. Increased disclosure is always bad for monopolies and this must be fought every step of the way. This is why I have been such a consistent critic of OTC derivatives. The lack of transparency and disclosure in OTC derivatives is unfair and violates the most basic American standards of openness in financial markets. The OTC derivatives market of 2010 is like a bucket-shop from the 1920s, but few Americans seem to appreciate such distinctions today.

6. In your speech last year to the American Enterprise Institute (AEI) and Professional Risk Managers International Association, you said:

Believe me when I say that we have seen the wild eyed, "don’t you get it" look from…our colleagues in the XBRL community. We love their idealism and their vision, and we share same. But we at IRA also live in the real world of operating and delivering decision support systems for investors and fiduciaries.

Could you expand on these thoughts? In what ways do you think the XBRL community is being “other worldly” in its goals and activities?

New technologies have an allure of transformation and value creation that makes people very excited until you actually try to implement and integrate it into the real world.  The creation and implementation of XML, for example, has been relatively successful in that regard.  We’ll see how it goes now that the initial invention phase has finished and — like all technology — the proof of the pudding turns to the tradeoffs of efficacy versus the cost of operations and maintenance.

At IRA, we like to always be mindful that there is nothing really new in technology. The basic building blocks of today’s software and hardware tools trace their legacies back to the origins of computing. Each step of the way, in terms of innovation, there are choices and tradeoffs. We like to always look at the technology innovation process as a quilt, where data and business case needs interact and the best choice, depending upon those business needs, makes itself apparent as part of the diligence process.  Each one of the client silos we serve – consumer, institutional, B2B – have different technical needs and business objectives, and different consumption requirements. We see the world of XML as important building blocks that enable data collection and interoperability between systems, but they do not address the entire solution in terms of consumption. We would not be so bold as to pre-judge how our consumers use the data and ratings we supply.  We prefer to listen, add our perspective, and then give the user the solution that makes the most sense for their needs.

7. In comments made to CFO.com back in 2006, you agreed that an XBRL mandate for financial reporting would expand coverage of smaller companies. Are you still optimistic that this will happen? Overall, given the difficulties of the equity research industry, how do you see the impact of XBRL on its business? Do you believe that, as advertised, XBRL will help the industry cut costs and expand coverage?

Possibly, but not because of the way the SEC or big accounting has handled the implementation to date. What we’ve heard from the smaller SEC registrants community is that XBRL is an extra step that one’s filing vendor does for you as part of preparing and submitting to the SEC. The tagging has not been internalized by the filer nor made part of their internal data collection and reporting process. 

The question about the data vendors that article addressed turns on whether the implementation at SEC results in a useful repository to power an operational downstream analysis solution like the FDIC’s architecture or will just be a demonstration facility. Or to put it in very blunt commercial terms, when I can download the XBRL documents or a subset thereof containing the numerical information in SEC filings, then the existing data vendor monopoly on structured financials will be near an end. The SEC has always taken an evolutionary approach to data collection and dissemination. I suggest that it is time for the SEC to target the distribution of full tagged financials, starting with income statements, balance sheets, and statement of cash flows, as the next practical goal in terms of EDGAR modernization. While the SEC data is still “chopped salad” in terms of accounting presentation, having the data in a consistently structured, “as filed” form would be helpful. Today analysts go to each corporate web site and download disparate Excel and Adobe files to perform analysis. 

8. In addressing the problem of extensions in taxonomies, Gerald Trites of XBRL Canada said:

….Too many extensions by different companies contribute to noncomparability, because each company is likely to do an extension for basically the same problem in a different way. So the results become difficult to compare. One way to address this is to develop very robust taxonomies, such as those in the United States. However, the problem this creates is that the more robust the taxonomy, the more difficult it is to do the mapping required. So robust taxonomies can be an impediment to adoption.

What are your thoughts on the extension issue? What do you see as the relative positives and negatives of a core US GAAP taxonomy with roughly 17,000 elements?

I agree with Mr. Trites’s statement. The way to make XBRL relevant to investors and analysts would be to start with the basic reporting template available from the commercial data vendors and build a very simple data delivery function that expands the completeness of numeric data from income statements, balance sheets, and cash flows. The current SEC data implementation leaves the data monopoly of the large commercial vendors intact, thus no progress in terms of innovation by downstream users.  

The other point that must be made is that complexity of the XBRL taxonomy is a function of the business case needs of the audit profession and has very little to do with how institutional investors consume data. Remember that most of the people who work on Wall Street are focused on quantitative analysis and don’t have a clue how to perform the fundamental analysis of a bank or company. When you look at the size of the XBRL taxonomy, the only reasonable conclusion is that the audit firms are trying via stealth to turn the relatively subjective world of public company reporting into a more deterministic exercise requiring the constant services of a FASB rulings subject matter expert. Anyone who has read the Securities Act of 1934 and is familiar with the legal mandate of the SEC vis-à-vis public company reporting knows this result, apparently sought by the audit firms, is impossible in practical terms, unlikely in political terms, and conflicts with the SEC’s mission of making it possible for ordinary people to actually see and understand what’s happening in the public securities markets.

9. There has been much discussion about the potential of XBRL for internal management reporting.  Actual implementations, however, are few. As the SEC’s XBRL mandate proceeds, do you think XBRL’s use for internal reporting will increase substantially?

No, as my previous comments suggest. The audit firms would like to see XBRL extended to internal reporting, but for many practical reasons companies are going to fight creating an explicit link between internal management systems and external reporting. In every bank that I cover, there is a set of GAAP books and a set of “managed” books. The two worlds only meet in the CFO’s office when it is time to make public disclosure. The same goes for commercial manufacturing, retail, and service businesses. The reality is that management systems technologies such as ERP are light years ahead of accounting innovations like XBRL. There’s a strong case for CFOs of companies to internally opt to tack on reporting modules to their existing ERP instead of replacing these mission critical solutions with an auditor recommended one that changes both internal forms of corporate governance and control. 

10. XBRL initiatives are now being pursued in a wide range of areas, including corporate actions,  sustainability reporting, and microfinance. What uses of XBRL that go beyond the usual sphere of financial reporting and company accounting systems seem most promising to you?

All of these are promising areas, but the two key questions to ask are: (1) is the data collected going to be made public, and (2) is there any standardization of the data to make it useful in terms of downstream analysis?  In the US, for example, there is a push among many states and municipalities to make property records electronic.  But there is no state-by-state or national template for this effort. This is a huge potential opportunity, but getting the states, the realtors and the courts to agree on a standard is another matter.

11. XBRL has now been implemented for financial reporting in most or all of the major economies, including Japan, France, and Italy, as well as smaller nations like Chile and Denmark. What can the US learn from other countries in implementing XBRL? What can other countries learn from the US adoption?

There are big lessons to learn from the two “wins” in terms of US adoption, FDIC and SEC. The FDIC effort is a success because it represents a standardized, tightly defined implementation that meets specific, legally mandated public reporting requirements.  In the case of the SEC, the benefits are less clear because the task is so much more diffuse and the ability of the SEC to impose standardization is non-existent under GAAP.  That is the key difference between the FDIC and SEC business case paths for XBRL adoption.

Making SEC reporting as deterministic and standardized as FDIC bank reporting is neither possible nor desirable, but that does not lessen the utility of XBRL at the SEC.  Once we accept that reality, then the utility and development path for the SEC adoption of XBRL will become easier and the necessary choices will become much clearer.  The world of public company reporting is always changing as the economy and markets change.  

Staying entirely current with the state of the art in terms of GAAP reporting and investor relations spin is a daunting and probably impossible task given current law and resource constraints. Indeed, it is impossible. The effort to describe and add to the XBRL US GAAP taxonomy reminds me of Franz Kafka’s 1917 essay, “The Great Wall of China,” where he describes how generations of people over hundreds of years worked on sections of the Great Wall, but most never saw it completed nor knew the enormous extent of the entire task. Just as public company reporting evolves continuously and in response to many different internal and external forces, so too the adoption of XBRL will need to remain flexible and be aware that the target is constantly moving. 

 

Add to Del.icio.us | Digg this

This entry was posted on Thursday, February 18th, 2010 at 10:29 am and is filed under General, . You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.