The interactions between risk management and technologyFocus both on technology developments that can help improve risk management, but also on other aspects such as operational and potentially strategic risks caused by advances in technology
| |
« Systemic Risk and Macro-prudential Regulation |
Main
| The Invisible Hand »
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 February 12, 2010 01:57 AM
Question/statement
My own opinion of a data utility 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).
CCDM/ADG Answer
The CCDM will only assign and oversee “supply chain” entities, those corporate and financial enterprises and financial institutions that are involved in security issuance or creation, and trading and payment, not retail customers – there is about 1.5 million such business entities globally, a manageable number, certainly in the context of today’s terabyte data bases
Question/statement
There are other kinds of key reference data types that are firm-specific - an internal organizational hierarchy is the most common example.
CCDM/ADG Answer
Not of interest to the CCDM as the domain we are covering is “shared” data sets. In this regard we are interested in a trading desk, as securities may be delivered directly to its back/middle office/ custodian agent on its behalf. Here there are industry data bases that contain such “standing settlement instructions (SSIs)”. Unfortunately there are many, varying widely in accuracy and timeliness – this is the CCDMs domain and value proposition, to standardize and maintain one data set for all.
Question/statement
Let's drill down deeper. There are other types of 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.
CCDM/ADG Answer
Which “trading book” will be determined by the instrument id, again with a standard id across all financial institutions, it can be understood. Where a trading book traverses multiple business units, those business units would also be known via the SSI’s, the combination of BEI/SSI and Instrument ID would be the coordinates for locating the trading book. The Business Unit will be a new standard that will be overseen by the CCDM. This, in the CCDMs thinking is to be expressed as the “Acting in Capacity” code. This code would be aligned in combination with the BEI/SSI identity so that it would be known whether you had a relation with this business unit as, for a example, as a counterparty, as an escrow agent, as a custodian, as an agent for others, as a fiduciary, etc.
Question/statement
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.
CCDM/ADG Answer
The intent of the CCDM is not to aggregate exposures. It is to facilitate financial institutions ability to do so, and for regulators to have access to such exposure information through commonly defined position and transaction data. Access to this information will be facilitated by common id’s and referential data, and their associated standardized data tags. Terms & conditions of standardized and customized products will be available, as will standardized instrument/product ID’s and Business Entity/SSI/Acting-in-Capacity-code ID’s. Position and transaction data coded with such standard Ids, will be available at each firm, accessible remotely or on-site, when needed for both Basel II supervision as well as for model building and testing around the new discipline of systemic risk analysis proposed by NIF
Question/statement
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.
CCDM/ADG Answer
A regulatory imperative is highly desired, to compel financial intermediaries and financial infrastructure institutions to set a course for standardization of reference data through the CCDM. This is long overdue as many industry initiated studies, including that of the Group of Thirty, admonished the industry for not doing this, starting over two decades ago. The idea of collecting position and transaction data and submitting it to a government run facility is not warranted in light of the alternative of having such data available to regulators in standardized, searchable and, aggregated form at financial firms, much like the general ledgers and sub-ledgers are available on site, in standardized GAAP or IFRS form, for external audits. Where quick searches through multiple, distributed data bases are warranted, the technology of the internet has shown that such aggregation is not only feasible but available in sub seconds, made practicable by data tagging and standardization of address locators and other referential data.
Posted by: Allan Grody at February 12, 2010 12:48 PM
Thanks to Allan for the thoughtful clarification. We need such initiatives to move forward if the next financial armageddon is to be fended off.
Posted by: Dilip Krishna at February 13, 2010 10:24 PM
I think it is a great idea.
To manage & scope the expectations from CCDM, the boundary has to be clear and how organization can make use of such shared asset, What is they get something in transaction differently than the shared asset which they reference. Some of these implementation scenarios has to be discussed as well in my opinion.
Posted by: Hari at March 6, 2010 08:23 PM
Post a comment
|
|
