February 12, 2010
Collaborating on Data
The year has well and truly started, and my other commitments (aka my real job!) are preventing me from devoting as much time to intellectual interests as I would like to spend. In spite of this, however, I did manage to read a couple of papers by Allan Grody where he lays out a compelling vision for a common reference data management utility dubbed the Central Counterparty for Data Management (CCDM) - you can read all about it here and here. Allan is a well-known figure in the industry and has been working on data issues for some time. His basic thesis is that while reference data is expensive to manage and difficult to maintain, hoarding it and specializing in its conformance brings no lasting competitive advantage to any specific financial institution. This is especially true where reference data is critical in enabling the connections between them such as in the settlements process. Therefore he advocates creating a central clearinghouse for reference data which is managed as a cooperative utility by the largest financial institutions.
I think the idea has merit. In the information fabric of a financial organization, reference data is like the Force (to throw in a Star Wars reference) - everything we know about the business is seen through the lens of reference data but business people (usually) don't realize it's even there. Managing reference data is a complex, expensive business - but since its benefits are hard to visualize it's often seen as an drain of resources rather than the asset it really is. The other interesting feature of reference data is that usually it does not contain much useful information in itself. This makes it a perfect case study for sharing it the costs of managing it - these costs can be amortized across a number of financial institutions without their losing competitive advantage in the process. The work to standardize reference data is an effort worthy of Sisyphus - the job is never done. Semantic differences and dynamic markets introduce not only new data (such as new securities) to the marketplace with amazing regularity, but also new types of reference data. The high costs, and the comparatively boring nature of managing reference data, should be sufficient to suppress most of the political problems that tend to sink such cooperative efforts.
The very term "reference data" (also otherwise known as Master Data) is hard to define with any precision (I recall having spirited discussions in the banks where I worked on the subject 10 years ago). Here are some common definitions:
- Reference data can literally be described as the data that is used for referential purposes to summarize business information. For example, a sales report could contain sales figures aggregated by Product, which is a kind of reference data. Reporting could also be done by Geography, Business Unit or Time, each of which could be considered reference data. In this sense, any kind of dimension data (if this sounds like jargon, see here for a short description of dimensional modeling) can be considered reference data.
- Another definition for reference data is any data that is (comparatively) slowly-changing. Customer lists, product masters and internal organizational hierarchies would all be easily recognized as falling under this definition (though admittedly in some companies the last may change more quickly than to most people's liking!).
- A third way to define reference data is in the negative - reference data is any data that is not transactional. Of course this merely punts on defining what a transaction is, but does bring some additional types of data to the fold. For example, market prices are definitely not slowly changing, and they are usually not used to as tools for aggregation. But they are often lumped into the reference data bucket in common literature - this is the definition has the advantage that it would identify prices and rates as reference data.
My own opinion of a data utilitiy such as the CCDM is that it would be an integral part, but only a part, of a lasting solution to the problems of data in the financial industry. First, there are some kinds of reference data that are guarded as crown jewels by corporations - as anyone who has tried to standardize customer lists in a large bank will attest (Financial Advisors heartily resist sharing their customers with the rest of the bank, for example). There are other kinds of key reference data types that are firm-specific - an internal organizational hierarchy is the most common example.
But I have a bigger issue with focusing solely on reference data in the context of risk management. It has become abundantly clear that a blinkered view of a firm's own exposures can leave the firm, and in a larger sense the overall financial system, dangerously exposed. Clearly there is need for some kind of transparency into systemic exposures of firms in the financial industry so that any firm can transact with another confident in the knowledge that its risk measurement will not be invalidated by some unforeseen systemic event. Setting aside, for the moment, the question of
who would be responsible for figuring out the condition of systemically important firms, let's look at what information would be critical to answer this question.
Let's say that you are responsible for reporting risk exposures that large firm has to a particular counter-party - for argument's sake assume this is Lehman Brothers. You'll need to aggregate exposures that are not only directly to Lehman Brothers Holdings Inc, but also to its subsidiaries (many of whom have names that have nothing to do with Lehman such as SIB Mortgage and Eagle Energy Partners). This means that the firm will need to keep an up-to-date roster of all of Lehman's subsidiaries. The problem is actually worse than this, since the actual legal relationship between parent and subsidiary is important in bankruptcy situations (after all this is where the counter-party rubber hits the road!). It's conceivable that such reference data (termed Business Entity Identification or BEI - see Allan's paper for details) could be aggregated by a co-operative entity such as the CCDM. This is especially true since there is little competitive advantage to the firm in hoarding such information, and lots of advantage in learning what everyone else knows about a counter-party.
Let's drill down deeper. There are other types reference data that will not be appropriate for a shared data utility. In order to do something about the exposures, it's necessary to know not only the firm's aggregate exposure to Lehman but to know
where this exposure is situated in the firm (such as which trading book or business unit). This internal organizational information is also reference data, which is often a source of difficulty in reporting. However it's useful only to the firm itself, and likely not information that it would want to share anyway.
You'll notice that we've not even gotten to the main event yet - the actual exposures. These are sensitive pieces of information that must be (and are) jealously guarded by the firm. But they are also can be a major source of data error, caused by a number of issues. Among them - data integrity issues and timeliness problems - not to talk of metadata (semantic) challenges. Without a clean, timely source of its own exposures, a firm has little hope of being able to analyze its risk profile on a continuing basis.
But the problem gets bigger. Risk management is today not just the business of those running financial institutions - as the past 2 years have taught us,
it's is all of our business. The risk exposure of a firm is not only important it it, but also to organizations that are charged with safeguarding the health of the financial system as a whole. Understanding and controlling systemic risk requires all the data discussed above and more. While an organization like the CCDM can certainly be helpful in aggregating some of the required data, there are other kinds - exposures to name just one - that will be almost impossible for such an industry-funded group to aggregate. If you consider that this sort of information has proved well-nigh impossible to aggregate even within a single financial institution, except with a regulatory hammer hanging over it (such as Basel II), I can't see how a cooperative, industry-funded initiative has any hope of success of collecting such information. This is where I see an organization like the National Institute of Finance (see their site
here) playing an important role.
To conclude, it seems to me that the concept of the CCDM is sound and addresses a crying need for financial institutions. Not only is it theoretically a good idea, it seems to me that for certain kinds of data there is a great deal of practicality to it as well. However, it's not the whole story especially as it pertains to risk management. An overwhelming amount of important financial data that needs to be collected for this purpose does not fit well into the concept of a voluntary submission, industry-cooperative initiative. Rather, I'm convinced that it will take a regulatory imperative to break down the barriers to solving the problem of aggregating systemically important data from across the financial industry.
Posted by dkrishna at 01:57 AM
| Comments (3)
