There is a common misperception that financial instruments, and in particular derivatives, are a recent invention, dreamt up by rocket scientists left jobless after NASA and Cold War budget cuts. This is of course far from the reality. It is true that the complexity of financial instruments has come a long way since some of the earliest examples of organised trading – such as equity trading in 2nd century BC Rome, and options trading of olive presses in ancient Greece. It would be nice to think that this is the reason why Greek letters are used to represent market sensitivities for certain derivative products.
Financial instruments are, by their nature, a virtual representation of the real world and as in the real world, a lot of organisations do not necessarily have the luxury of taking a top-down approach to interface design. This would entail modelling the business components affected, then creating a logical data model of the information, and finally defining the message model itself. In a project based, rapid development environment, the business and logical modelling analysis tend to be overlooked and resources are focused on designing the message model.
There are various ways representing the instrument and market data which can be grouped into three main categories. Firstly, there is the hierarchical approach, broken down by asset class or trading floor operations (equities, fixed income and so on). An example of this technique can be seen in MDDL version 1 & 2. A variant of this approach is the instrument type representation, where all the terms associated with a specific product are grouped together within the message model (this can be seen in FpML – Financial products Markup Language). Finally, there is the building block method, where instruments are constructed from a set of characteristics.
To highlight the differences between the various approaches, this article presents example XML messages that have been constructed based on an S&P 500 equity linked dollar-denominated structured bond issued by the World Bank in 2004. This combines the features of an interest bearing bond with a coupon of 1.5% and the potential growth of the S&P 500 Equity index.
Hierarchical approach
Traditionally, investment banks and other financial institutions have organised their trading floor operations and sales teams around broad instrument categories, such as equities, fixed income, futures and options and FX. Therefore it is not surprising that data and message models have been structured in a similar manner, with terms and their relationships broken down by asset class, sub-class and so on, in a hierarchical manner.
Figure 1 Hierarchical representation
The hierarchical method lends itself to message validation being built into the model as well as an alignment of the message structure with the operations of the business. However, a hierarchical structure can lead to the duplication of ingredients as the terms used in one category may also be required in another, which can result in the model being difficult to use with binding tools and for use in runtime validation scenarios, given the complexity of some models.
An example of a message with a hierarchical structure is shown in Figure 2.
<snap> <entityDomain> <issuerClass> <name>International Bank for Reconstruction and Development</name> <location> <address>1818 H Street, NW</address> <stateOrProvince> <name>Washington</name> </stateOrProvince> <postalCode scheme="http://www.usps.com"> <mdString>DC 20433</mdString> </postalCode> <country>US</country> <website>http://treasury.worldbank.org</website> </location> </issuerClass> </entityDomain> <debtDomain> <currency>USD</currency> <debtIssueData> <instrumentIdentifier> <name>World Bank issues USD Standard and Poor's 500 Equity Linked Bonds Series No. 2825</name> <code scheme="http://www.mddl.org/ext/scheme/iso6166"> <mdString>US45905UED28</mdString> </code> <code scheme="http://www.mddl.org/ext/scheme/SYMBOL?SRC=CUSIP"> <mdString>45905UED2</mdString> </code> <!-- Common Code --> <code scheme="http://www.mddl.org/ext/scheme/SYMBOL?SRC=ECCC"> <mdString>020698365</mdString> </code> </instrumentIdentifier> <interestRate> <rate>1.5</rate> <dateTime>2005-11-26</dateTime> <period> <duration>P1Y</duration> </period> <accrual> <period> <dayRuleType>actual</dayRuleType> <duration>P1Y</duration> </period> <accrualBasis> <accrualBasisType>30/365</accrualBasisType> </accrualBasis> </accrual> </interestRate> <interestRate> <linked> <mdBoolean>true</mdBoolean> <instrumentIdentifier> <code scheme="http://www.standardandpoors.com"> <mdString>Standard and Poor's 500</mdString> </code> <name>Standards and Poor's index of the 500 leading US companies</name> </instrumentIdentifier> </linked> </interestRate> <maturity> <maturityDate> <mdDateTime>2011-11-26</mdDateTime> </maturityDate> <maturityType>fixed</maturityType> </maturity> <denomination>1000</denomination> </debtIssueData> <issueData> <issuePrice>100</issuePrice> <issueDate>2004-11-26</issueDate> <issueAmount>10405000</issueAmount> <incomeType> <mdString>interest</mdString> </incomeType> <clearingSettlement> <clearingHouse>DTC</clearingHouse> </clearingSettlement> <governingLaw>New York</governingLaw> </issueData> </debtDomain> </snap> </mddl>
Figure 2 A hierarchical approach example based on MDDL version 2.5
It is also worth noting that the hierarchical approach may result in difficulties when attempting to represent products that bridge asset classes, such as structured/hybrid or OTC products.
Instrument type representation
A variant of the hierarchical approach is to organise terms into a message model by instrument type; this can be visualised as a list of ingredients. This method results in the creation of an XML schema or a set of schemas that forcefully locks down the terms for each specific product. An example of this technique can be found in FpML, where the user can specify the instrument type that is contained with the message. This is appropriate in the context of OTC (over-the-counter) products, as an instrument normally aligns with an underlying ISDA (International Swaps and Derivatives Association) Master Agreement.
Figure 3 Instrument type representation
Documentation can be built into the message model as well as validation of content as there is a tight relationship between the model and instrument terms. However, new instruments may require the creation of a new message model.
Building block method
Over recent years, there has been a better understanding of the building blocks that make up financial instruments, and it is not surprising to find that the majority of products can be created from a relatively small set of components. Based on the concept of grouping related terms into discrete chunks (or classes), this method does not suffer from being limited to a single business context, a weakness associated with other approaches.
This is the most flexible mechanism for representing data and is sometimes referred to as the ‘über instrument’ approach. Financial products are constructed by only using the components needed. This results in all components being optional, making it difficult to enforce schema validation of content, which is available in the hierarchical and instrument type methods. However, this is far outweighed by the ability to support a greater range of financial products without the need to update the associated models. It is also worth pointing out that one would normally expect the validation of the content to be undertaken by the sender and in cases where there is concern about the content, the receiver would also incorporate business rules validation; therefore this should not be considered an insurmountable issue.
Figure 4 Building block representation
Building block representation has the advantage that the range of instruments supported is not limited to a predetermined list. In addition, instruments can be created with ease and it is simple to extend the approach to include new components and thus new instruments and functionality. However, there is a risk that the model's use may evolve in an uncontrolled way if not supported by adequate documentation and maintenance procedures.
An example of a message constructed in this way is shown in Figure 5.
<instrument> <!-- Instrument Issuer Block --> <entity entityType="issuer"> <pointOfContact roleType="Vice President and Treasurer">Gary L. Perlin</pointOfContact> <name>International Bank for Reconstruction and Development</name> <address> <street>1818 H Street, NW</street> <stateOrProvince>Washington</stateOrProvince> <postalCode postalCodeType="http://www.usps.com">DC 20433</postalCode> <country>US</country> </address> <website>http://treasury.worldbank.org</website> </entity> <!-- Instrument Identification --> <identification> <name>World Bank issues USD Standard and Poor's 500 Equity Linked Bonds Series No. 2825</name> <code codeType="isin">US45905UED28</code> <code codeType="cusip">45905UED2</code> <code codeType="commonCode">020698365</code> </identification> <!-- Issuance Terms normally found in the Term Sheet or Prospectus --> <issuance> <maturityDate maturityType="fixed">2011-11-26</maturityDate> <denomination>1000</denomination> <issuePrice>100</issuePrice> <issueDate>2004-11-26</issueDate> <issueAmount>10405000</issueAmount> <governingLaw>New York</governingLaw> <clearing> <clearingHouse>DTC</clearingHouse> </clearing> <payments> <payment> <rate> <percentage>1.5</percentage> </rate> <dates> <date>11-26</date> </dates> <period> <multiplier>Y</multiplier> <multiplierValue>1</multiplierValue> </period> <accrual> <dayRuleType>act/act</dayRuleType> <accrualBasis>30/365</accrualBasis> </accrual> </payment> <payment> <variable> <referenceRate> <code codeType="http://www.standardandpoors.com">SandP500</code> <name>Standard and Poor's 500</name> </referenceRate> </variable> </payment> </payments> </issuance> </instrument>
Figure 5 Building block representation
If the message model contains components for supporting pricing, valuations and risk analysis it lends itself to grid computing architecture. For risk management, calculating complex analytics scenarios or time critical pricing/valuations analysis, a computational grid would be appropriate. A data grid could be used to house and provide access to data across the organisation (or across multiple organisations), and if bandwidth is an issue, then the grid can be combined with data compaction, such as fisdMessage or FIX FAST Protocol, to improve performance.
Conclusion
At the end of the day there are various ways of representing market data and it is a question of horses for courses. An organisation will need to examine its specific needs and adopt an approach that best fits its specific requirements. It is not a foregone conclusion that the building block approach is the appropriate method for all environments. Both the hierarchical and the instrument type approaches may meet the validation and documentation requirements of the organisation. On the other hand, the building block method does lend itself to supporting a greater range of financial instruments, especially in the new world of structured and hybrid products, as well as the ability to be used in multiple business contexts.
