This article compares the way in which LUSID models FXForward, Interest rate swap, Equity option, Equity and Bond instruments with two alternative paradigms: ISDA CDM and FpML.
The intention is to show that the LUSID instrument model is already reasonably close to ISDA CDM; we intend to be compliant if it becomes industry standard. Where there are differences, or your source systems are different, we can translate between your choice of ISDA CDM or FpML and our modelling paradigm.
FXForward
ISDA CDM ForeignExchange object
LUSID FxForward DTO
To examine this object interactively, and for the latest information, try the C# or Python SDK reference help.
Discussion
Given the CDM exchangedCurrency object contains both date and amount, the main difference to note is that CDM employs a tenorPeriod. This is suitable for execution but not for agreeing trade details and booking, which are both done at the date level only (otherwise date generation rules need to be agreed and persisted with the trade; this is not the convention). If the former approach is required, we can expose our schedule generator as an API or create a UI interface which switches between tenor and date.
The LUSID DTO specifies startDate and also transactionDate across contractual products, as opposed to the CDM which states effective date and trade date. Discrepancies like this can be aligned to move our DTO closer to CDM standards. Additionally, a cleared date is currently not supported in the DTO which would be useful in the case of cleared derivative products; again, additions such as this can be reviewed to further align our model.
Interest rate swap
ISDA CDM InterestRatePayout object
LUSID LegDefinition DTO
To examine this object interactively, and for the latest information, try the C# or Python SDK reference help.
Discussion
The main difference is repetition, with the CDM defining payouts as cashflows, each containing the full definition for the instrument leg (swap, FRA, CDS, or equity swap). By contrast, the LUSID model defines cashflows through the instrument leg, with customisation applied ex-post. There is also a bespoke cashflows representation for greater control, which can be used to support a fuller set of attributes, or tailor the model for different use cases.
It is also worth highlighting that the CDM contains a discountingMethod. At FINBOURNE, we endeavour to keep the build method and market data separate from the instrument for flexibility and customisation at runtime. This approach extends to counterparties, resets and other trade lifecycle data.
In the case where enumerated values differ to those in the CDM ,these can be adjusted as our models are further aligned. Where additional logic is required, such as restricting the values for holiday calendars based on the chosen business centre, clients can configure their own levels of validation to manage the inputs into the DTO. This allows greater levels of data control while leaving our model unbiased and unrestricted.
Equity option
ISDA CDM Option* objects
FpML equity option contract
LUSID EquityOption DTO
To examine this object interactively, and for the latest information, try the C# or Python SDK reference help.
Discussion
The CDM model starts with a product definition and then supplies the option to include additional details as desired. These additional details include option type, feature, provision, strike and style as well as exercise details. The FpML model includes an even greater range of fields to detail a wider amount of provisions and it is obvious how much additional transaction information is included. Once removed, the model looks much more similar to the LUSID DTO. Our approach is to capture the minimum required information over the maximum number of optional fields, for ease of use and also to diminish the need to capture potentially unused data.
Equity
ISDA CDM Equity object
FpML equity contract
LUSID SimpleInstrument DTO
To examine this object interactively, and for the latest information, try the C# or Python SDK reference help.
Discussion
In the case of simple instruments such as equities, the models are very similar with the only key differences being the LUSID DTO requires a domestic currency (the currency of the instrument) but does not require a source to be defined. In this example the FpML extract has been cut down to just the instrument information and is almost identical to the LUSID DTO.
Bond
ISDA CDM Bond object
FpML bond contract
LUSID Bond DTO
To examine this object interactively, and for the latest information, try the C# or Python SDK reference help.
Discussion
The CDM model is quite straightforward, consisting of a product taxonomy (value and source) and identifier. Under the identifier further attributes can be included for debt class, interest type, principal and seniority. CDM take this approach, excluding collecting further information, to avoid the potential for conflict between the contractual product and the service provider.
The LUSID model is expanded to also include the full cashflow details, including frequency, daycount convention and roll convention in addition to principal and coupon rate as we believe this is important financial information for this instrument. This is much closer to the instrument data included in the FpML model. The extract above shows a basic bond definition; however, all the additional terms from the LUSID DTO can also be included.