Font Size: AAA // Print // Bookmark

Comment for Proposed Rule 75 FR 76706

  • From: Victoria Lemieux
    Organization(s):
    Centre for the Investigation of Financial Electronic Records

    Comment No: 26821
    Date: 12/31/2010

    Comment Text:

    Dr. Victoria Lemieux
    Director
    Centre for the Investigation of Financial Electronic Records
    School of Library, Archival and Information Studies
    University of British Columbia
    Vancouver, Canada
    V6T 1Z1


    December 29, 2010

    David A. Stawick,
    Secretary of the Commission
    Commodity Futures Trading Commission
    Three Lafayette Centre, 1155 21st Street, NW.
    Washington, DC 20581

    Dear Sir,

    Re: CFTC/SEC Consultation on standardized computer-readable algorithmic descriptions which may be used to describe complex and standardized financial derivatives dd. 9 December 2010

    I am writing to respond to the set of questions on the above subject on behalf of the Centre for the Investigation of Financial Electronic Records.

    The Centre for the Investigation of Financial Electronic Records (www.ciferresearch.org) conducts research, hosts educational and networking events, engages in advocacy and provides products and services related to financial records and the records of financial institutions. The premise upon which the Centre is founded is that, in today’s complex operating environment, global financial institutions face a growing number of risks associated with business records. Insufficient understanding and control of business records is at the root of many of the current risks faced by financial institutions: data leakage, integrity of transaction records, legal discovery challenges, data protection and confidentiality, trans-border data flow, and records retention to name but a few. The key to resolving many of these issues is in developing a clearer understanding of the records of financial institutions – their creation, communication, storage, and disposal, as well as the people and systems that shape these processes. From this understanding the principles and practices associated with a strong and effective program of managing and controlling the risks associated with records can be achieved. In furtherance of this objective, the Centre has been involved over the past two years in a project to develop an open source domain specific modeling language that can be used to represent complex and standardized financial derivatives. Our approach is outlined in a forthcoming paper to be published in the Journal of Information Science (copy attached). The Centre’s responses to the questions draw on this research. We have only provided responses to those questions with which our research activities are concerned.

    1. How would your organization or community define ‘‘net exposures to complex derivatives?’’

    We understand this to mean the extent to which a financial institution’s (or one of its client’s) capital is exposed to the market as a result of its position in complex derivatives, less the value of any hedging strategies.

    2. Do you calculate net exposures to complex derivatives?

    3. What data do you require to calculate net exposures to complex derivatives? Does it depend on the derivatives instrument type? How?

    CIFER Response: To develop our domain specific modeling language, we conducted detailed analysis of source documentation related to events leading up to, during and immediately following the financial crisis of 2008. From this analysis, we identified several ‘information failures’ along the ‘derivatives supply chain’. We define the derivatives supply chain as the set of financial transactions from creation of the asset underlying a complex derivative, to creation of the derivative product itself, to subsequent trades involving the derivative until the end of the life of the product.

    Among these information failures, we identified several that interfered with financial institutions’ ability to identify their ‘net exposures to complex derivatives.’ Among these failures are: 1) insufficient information related to the underlying assets (e.g. which mortgages underpinned which tranches); 2) insufficient information related to the ownership of the underlying assets (i.e. the counterparty who legally owned the mortgage); 3) insufficient information related to the credit-worthiness of various counterparties along the derivatives supply chain (i.e. the mortgagors, counterparties holding mortgages, counterparties insuring against credit default)); 4) insufficient trust documentation to distinguish safe custody assets held for one client from a financial institution’s own assets or its clients’ assets (a problem created by the practice of rehypothecation); 5) insufficiently timely settlement of OTC trades to determine net exposures to various derivatives products and counterparties as markets changed.

    From this analysis, it is possible to conclude that defining “net exposures to complex derivatives” requires, at the least, basic data about 1) the derivatives supply chain itself; 2) the underlying assets underpinning complex derivatives products; 2) the custodians of derivatives along the supply chain; 3) the beneficial ownership of the derivative, its underpinning assets and any assets pledged as security or rehypothecated along the derivatives supply chain; 4) the credit-worthiness of each counterparty involved in the derivatives supply chain; and 5) sufficiently timely information about each transaction along the derivatives supply chain to maintain current information about net exposures to complex derivatives.

    4. Are there any difficulties associated with your ability to gather the data needed to calculate net exposures to complex derivatives? What are they?

    CIFER Response: Our research revealed a number of difficulties, which we call ‘information failures’ that interfered with financial institutions’ ability to gather the data needed to calculate net exposures to complex derivatives. For example:

    1) ‘No Docs’ Mortgages

    The first point of records and information risk identified in the process relates to the creation of “no doc” or no documentation mortgages, also known as “liar loans” [22]. Since mortgage brokers received commissions on the number of deals that they secured, they were motivated to sell more mortgages to potential home buyers (including those who have a high probability of defaulting payment) as their commission was based on loan volume and not on loan quality. As such, mortgage brokers did not collect the documentation which should be supplied by loan applicants such as evidence of their income and their credit history, information usually used by mortgage underwriters (the banks lending the money for the mortgage) to assess the applicant’s credit worthiness. There was also no incentive for mortgage underwriters to conduct stringent checks on the loan application since, from the creation of mortgage backed securities and the originate and distribute derivatives supply chain, they knew that they could easily pass on the risk associated with mortgages by selling them to investment banks, such as Lehman Brothers, or hedge funds, etc. Thus, the originate and distribute model created a disincentive for both mortgage brokers and mortgage underwriters to collect documentation associated with prudent lending practices. This analysis has led us to incorporate behavioral constructs into our domain specific modeling language so as to be able to represent the impact of changes in product incentive structures, product supply chains, risk ‘ownership’ and the like on financial actors’ cognitive state and resulting actions.

    2) Rehypothecation

    Rehypothecation of client assets was one of the “dominant drivers of contagion” during the financial crisis, amplifying the market turmoil in the wake of the Lehman Brothers collapse according to the the Senior Supervisors' Group (SSG) . The body, consisting of financial regulators from the US, Japan, Germany, France, the UK, Canada and Switzerland, made the assertion in its Risk Management Lessons from the Global Banking Crisis of 2008 report, issued as a follow-up to its first survey published in March 2008. The authors noted that, following the bankruptcy of Lehman Brothers International Europe (LBIE), that clients who elected to allow the dealer to rehypothecate their assets found themselves caught in the bankruptcy as mere unsecured creditors to the estate, rather than having their assets preserved in segregated customer accounts.
    As a result, counterparties that should not have been significantly affected by the collapse of the dealer found their assets trapped in the insolvency, shrinking their funding base and dragging a host of additional institutions into a precarious fiscal position, further deepening the crisis. LBIE’s administrators PricewaterhouseCoopers confirmed that more than $40 billion in hedge fund collateral had been swallowed in the collapse. The SSG report noted that “Custody of assets and rehypothecation practices were dominant drivers of contagion, transmitting liquidity risks to other firms. The loss of rehypothecated assets and the “freezing" of custody assets created alarm in the hedge fund community and led to an outflow of positions from similar accounts at other firms. Some firms’ use of liquidity from rehypothecated assets to finance proprietary positions also exacerbated funding stresses.”
    At the heart of the problem lay records. A March 2009 Dear Compliance Officer letter from the UK Financial Services Authority mentions that Client Assets Sourcebook (CASS) requirements were not being followed, specifically those requiring that “a firm must keep such records and accounts as necessary to enable it – at any time and without delay – to distinguish safe custody assets/client money held for one client, from safe custody assets/client money held for any other clients and the firm’s own applicable assets/client money.”
    The letter noted how essential it is to provide an insolvency practitioner with sufficient information and cited such failures as the fact agreements and terms of business documentation was not executed with signed copies on file. The letter went on to advise that best practice firms will have a central file including client assets and money policy and procedures documentation, letters of acknowledgement of trust arrangements; a copy of all record keeping requirements; a copy of the most recent regulatory audit report together with steps to address breaches; and the breaches register for the current period, and relevant management information reports. In contrast to what it considered to be best practice, the Financial Services Authority admonished that “Recent firm visits suggest that many firms do not have the appropriate trust acknowledgements in place. Where these are placed on file, we found instances where the documentation had not been executed in the name of the relevant bank or with appropriate authority on behalf of the relevant bank. Creating and operating these accounts are of paramount importance in establishing trust status for the benefit of the underlying client, the purpose of which again is only apparent on insolvency . . . In a period of market turbulence, we would anticipate that firms would conduct due diligence more frequently. We are reminding firms to document their due diligence.”
    3) OTC Trade Settlement

    Another point of information risk and failure relates to the settlement of OTC trades in CDOs and CDS’s. In his book on the collapse of Lehman Brothers, Lawrence McDonald notes that ``. . . the record keeping was close to impossible to keep up with . . .`referring to the fact that OTC trades could take as much as 30 days to settle due to process and infrastructure limitations. This issue was well known before the collapse: a TATA consulting report outlined the problem of infrastructure limitations as early as 2006 noting that “Given the crucial role of custodians in the entire process and the growing volumes and importance of OTC Derivatives, it is imperative for custodians to strengthen their infrastructure . . .” The fact that these trades took as much as 30 days to settle severely hampered downstream risk management and accounting systems that would have provided a view of the bank’s risk exposures and profits and losses. Assuming typical front-to-back office processes, it is possible to deduce that without such data, it would have been impossible to accurately keep track the bank’s net exposures on a timely basis.


    5. What other analyses do you currently perform on derivatives agreements? What kinds of analyses would you like to perform, and how could regulators and standards setters make those analyses possible?

    CIFER Response: CIFER continues to build its knowledge base on the derivatives supply chain and derivatives products. We would like to continue to use this information to analyze the causes of information failures associated the build-up of risk along the derivatives supply chain. We would also like to extend the use of our domain specific modeling language to other products and their supply chains as well as to other events involving information failure in the financial markets. We would further like to conduct empirical tests (‘read’ and ‘write’ tests) of our domain specific modeling language to determine whether it comprises a sufficiently rich set of semantic constructs.

    Regulators and standards setters could assist in making these analyses possible through funding studies and through the provision of expertise and information that will add to CIFER’s and other existing knowledge bases.

    6. How often do you perform net exposure calculations at the level of your organization? Is it continuous and real time, only for periodic external reporting, or some frequency in between?

    Current practices concerning standardized computer descriptions of derivatives:

    7. Do you rely on a discrete set of computer-readable descriptions (‘‘ontologies’’) to define and describe derivatives transactions and positions? If yes, what computer language do you
    use?

    CIFER Response: We are working at the level of conceptual modeling and have not yet experimented with translating our models into computer-readable code. We are, however, capturing our models in a MetaCASE tool called MetaEdit (http://www.metacase.com), which has the capability of translating customized domain specific modeling languages into executable code.

    8. If you use one or more ontologies to define derivatives transactions and positions, are they proprietary or open to the public? Are they used by your counterparties and others in the derivatives industry?

    CIFER Response: Our domain specific modeling language is intended to be open source.

    9. How do you maintain and extend the ontologies that you use to define derivatives data to cover new financial derivative products? How frequently are new terms, concepts and definitions added?

    CIFER Response: We are in the process of developing our domain specific modeling language. Development of the language is data-drive; we abstract from case data related to various ‘information failures’ associated with the financial crisis of 2008. We then devise constructs that will allow us to model the information failures and, iteratively, we return to the case data to determine whether the models accurately reflect the information failures they are designed to represent. We maintain our language through careful documentation of the semantics and syntax of the language as well as through maintaining a metamodel of our language that documents the relationships among constituent constructs. We also analyze and map the relationship between the constructs comprising our domain specific modeling language and Bunge’s and Searle’s formal ontologies in order to validate our constructs in relation to the formal logic outlined in these ontologies. We argue that this practice lends a semantic ‘robustness’ to our language that makes it easier to interconnect the semantics of our language to other ontologies and domain specific modeling languages.

    10. What is the scope and variety of derivatives and their positions covered by the ontologies that you use? What do they describe well, and what are their limitations?

    CIFER Response: Our domain specific modeling language has been designed to represent how information failures contribute to the build-up of risks along the mortgage-backed derivatives supply chain. We believe that it offers constructs that can be extended to represent other types of derivatives and financial products, but this belief is untested at this point in time.

    11. How do you think any limitations to the ontologies you use to describe derivatives can be overcome?

    CIFER Response: We believe that limitations in our domain specific modeling language may be overcome by further development of the language specification (i.e. by using the language to analyze other derivatives products, their supply chains and any associated information failures) and through empirical testing of the utility of the language.

    12. Are these ontologies able to describe derivatives transactions in sufficient detail to enable you to calculate net exposures to complex derivatives?

    CIFER Response: This is unknown and untested at this point in time.

    13. Are these ontologies able to describe derivatives transactions in sufficient detail to enable you to perform other analysis? What types of analysis can you conduct with this data, and what additional data must be captured to perform this analysis?

    CIFER Response: At this point in time, our work is only sufficiently advanced to allow us to represent information failures and their relationship to the build-up of risk along the mortgage-backed derivatives supply chain. We hypothesize that our models will allow people to understand, identify and therefore, mitigate information practices that could lead to the accumulation of risk or process failures along a product (e.g. derivatives) supply chain.

    14. Which identifier regimes, if any, do you use to identify counterparties, financial instruments, and other entities as part of derivatives contract analysis?

    Current use of standardized computer readable descriptions for messaging of derivatives transactions:

    15. Which computer language or message standard do you currently use to create and communicate your messages for derivatives transactions?

    16. Is there a difference between the created message and the communicated message? For example, does your internally archived version of the message contain proprietary fields or data that are removed when it is communicated to counterparties or clearing houses?

    17. Are different messaging standards used to describe different contracts, counterparties, and transactions?

    18. How and where are the messages stored, and do the messages capture different information from that information stored in internal systems?

    19. What information is currently communicated, by and to whom, and for what purposes?
    20. For lifecycle event messages (e.g., credit events, changes of party names or identifiers), are there extant messaging standards that can update data relating to derivatives contracts that are stored in data repositories?

    21. What other standards (i.e., FpML, FIX, etc.) related to derivatives transactions does your organization or community use, and for what purposes? Has your implementation of these
    standards had any effect on the way your business is conducted (e.g., does it reduce misunderstanding of contract terms, has it increased the frequency or ease of trades).

    22. Is the data represented by this/these messaging standard(s) complete enough to calculate net exposures to complex derivatives? What additional information would need to be represented?

    CIFER Response: We have not studied in depth the standards mentioned above; however, in general, we have observed through our study of other metadata standards that the process of development and, therefore, the content elements of these standards derive from accepted best practice rather than theory. This has led to the existence of many different metadata standards containing different elements. Drawing on the theory of the record as a representation of domain functions, activities and transactions, we propose that development of standards to represent financial products should be measured against how faithfully the domain is represented and further, that the semantic constructs used to represent the domain should be validated empirically and through comparison with formal ontology theory. We maintain that this approach will yield results that are much more rigorous and will stand the test of time much more so than relying solely on developing standards by building a consensus around best industry practice.

    23. In general, to what extent are XML-based languages able to describe a derivatives contract for further analysis? To what extent is other technology needed to provide a full description?

    CIFER Response: We have been motivated to develop our own domain specific modeling language because we have found other modeling languages and approaches lacking in the semantic richness needed to fully and faithfully represent our domain of analysis – the derivatives supply chain leading up to and including the time of the financial crisis of 2008. To achieve greater explanatory power, we have developed new conceptual constructs (represented in our modeling diagrams by specified graphical symbols) to represent aspects of the domain represented in complex derivatives that we discovered were not possible or difficult to represent with other languages. Our aim is to produce a modeling language that is semantically rich with extended explanatory capabilities, rather than one that is simple. By mapping our conceptual constructs to formal ontological logic, however, we believe it will still be possible to map our language to other languages to allow for flexibility and translation between different ontologies.

    24. What other analysis can be conducted with this data? What additional information should be captured?

    CIFER Response: Our domain specific modeling language has been developed with the specific purpose of understanding how the way in which information is created and captured (or not) and handled across the derivatives supply chain contributes to the build-up of risk, be it operational risk, market risk, liquidity risk or systemic risk. Our ultimate goal is to develop an approach that is capable of linking ‘micro’ risk analysis (e.g. operational and market risk) with ‘macro’ risk analysis (i.e. systemic risk).

    25. Do you have plans to change your messaging schemes/formats in the near
    future?

    CIFER Response: Our domain specific modeling language is still under development.

    26. Are there identifier regimes widely used in the derivatives market for identifying counterparties, financial instruments, and other entities in messaging?

    The need for standardized computer descriptions of derivatives:

    27. Would there be a benefit to standardizing computer readable descriptions of financial derivatives? What about standardization for a certain
    class/type of financial derivatives (i.e.,CDS versus interest rate, or plain vanilla versus complex)?

    CIFER Response: We support the development of standardized computer readable descriptions of financial derivatives as a strategy to improve transparency in financial markets and improve the management of risk associated with these products. Semantic approaches to analyzing complex derivatives will facilitate identification of metadata elements that need to be captured in order to monitor the effect of changes in the status of particular features on financial institutions’ net exposures to complex derivates and associated systemic risk. Analysis of different varieties of derivatives instruments will help determine the extent to and level at which descriptions can be standardized.

    28. What would be the issues, costs and concerns associated with standardizing computer readable descriptions of financial derivatives? Are there existing standards that could
    or should be expanded (i.e., FpML, FIX, etc.)? Do the existing standards in this
    area have materially different costs or issues?

    CIFER Response: We believe that no effort should be wasted, but that each standard should be properly evaluated (e.g. empirically tested and logically validated against formal ontologies). It may also be beneficial to build semantic ‘cross-walks’ between different standards that have taken hold in financial institutions as the industry gradually migrates to newer standards or updated versions of the previous standards.

    29. What would be an ideal ontology for you in terms of design, implementation, and maintenance of the data sets and applications needed for your business?

    CIFER Response: We take a theoretical approach to answering this question and suggest that an ideal ontology will faithfully represent its domain of analysis. That is to say, for a complex derivative, the ontology must faithfully represent all aspects of the markets, functions, activities and transactions of which that product is a part. We also submit that the ideal ontology should consist of constructs that have been logically validated against a pre-existing formal ontology (e.g. Bunge and/or Searle) and that such ontologies should be properly empirically tested.

    30. How would a standardized computer readable description of financial derivatives be developed and maintained (i.e., a government sponsored initiative, a public-private partnership, standard-setting by a collaborative process, etc.)? Are there current models that should be considered?

    CIFER Response: We believe that the process must be collective and that an international body, such as the International Standards Organization, could provide a suitable framework within which to develop and disseminate standardized descriptions.

    31. What is the importance of ontologies for the representation of derivatives data now and in the future?

    CIFER Response: The need for intelligent integration is critical to all information intensive endeavors such as the management of the risk associated with complex derivatives. The different contexts in which derivatives products are created can lead to wide semantic gaps even when there is relative consistency and agreement on the need to capture particular data elements. These semantic gaps can prevent effective human and computer communication that is needed to manage the risks associated with complex derivatives within financial institutions and financial systems. To illustrate, the concept of ‘net exposures’ can mean very different things to different individuals and groups and how this is calculated with lead to quite different conclusions. Semantics is important and the ability to mediate different semantic understandings arising from differing contextual knowledge is essential.

    Moreover, development of standard representations for complex derivatives, based on an understanding that representations of these products must faithfully encapsulate all elements of the domain, can reveal the importance of previously overlooked metadata elements needed to achieve more effective management of risk. As case in point based on CIFER’s research into the information failures along the mortgage-backed derivatives supply chain is the absence of information concerning the underlying assets, beneficial ownership of underlying assets and the credit worthiness of associated counterparties. We believe that it is essential to capture and associate these elements of the domain in any representation of complex derivative instruments, such as derivatives contracts and records of OTC trades.

    Implementation:
    32. Have you ever implemented a transition to a new data ontology, data messaging standard, or internal data standard?

    33. If yes, how did the perceived and actual benefits compare to estimated and actual costs over the short- and long-run?

    34. What were the main difficulties that you experienced during a transition/implementation of new data standards? What could the organization developing and maintaining the standards do (or avoid) to help alleviate these difficulties?

    35. Would it be useful to use a standardized, computer readable description for financial derivatives instruments? How would it be useful? Would such a standard be useful for
    communicating transactions, storing position information, both, or other purposes? What would be the costs involved?

    CIFER Response: Please see our response to question 31 above.

    36. How should regulators and standard setters implement description standards in the derivatives market?

    CIFER Response. Please see our response to question 30 above.

    Making computer descriptions legally binding:
    37. Are there currently aspects of financial derivatives messaged in a computer readable format that have a legally-binding effect?

    38. What information, if any, is not captured that would be required to make the computer descriptions themselves, without reference to other materials, legally binding?

    39. What information would need to be captured for a legally binding contract that would not need to be captured for analyzing the contract? Is there a substantial cost differential
    between the processes needed to capture one set of information versus another?

    40. Would there be a benefit to making the computer readable descriptions of financial derivatives legally binding? Would there be drawbacks? What are they?

    Other:
    41. Is there other information not called for by these questions that we should consider?

    CIFER Response: There are many approaches to modeling complex derivatives. Many of these are proprietary and many have not been empirically or theoretically validated. Although we have not undertaken a systematic study of these, we have noted the absence of key semantic constructs in a number of them for the purposes of our research on information failures along the derivatives supply chain. We believe that the industry would benefit from gathering information about all available standards, whether proprietary or not, and full analysis of their composition. Some level of coordination is needed in order to prevent the emergence of a ‘tower of Babel’ in relation to the representation of complex derivatives that prevents effective management of risks. We do not advocate our domain specific model or any other approach, but rather recommend developing a framework within which the many disparate efforts to develop standardized ontologies of derivatives can be harnessed and harmonized. We suggest that such a process must remain open, transparent, and international in focus if the full benefit of developing standardized computer-readable descriptions is to be realized.

    Thank you for your consideration of our response to your questions.

    Should you have any questions about these responses, please contact me at [email protected], by telephone at 1-604-822-9199 or by mail at the above address.

    Yours sincerely,


    Dr. Victoria Lemieux




Edit
No records to display.