AssetType missing from Product

[tomhealey-icma]

Background

When a new Asset type was created in v6 there were four types of assets created Cash, Commodity, DigitalAsset and Instrument. Cash, Commodity, DigitalAsset all have Asset base as an attribute where as Instrument has three attributes, ListedDerivative, Loan and Security. Each of these types also has the attribute InstrumentBase. Under InstrumentBase there is the attribute AssetBase and the attribute InstrumentType which again has the attribute ListedDerivative.

So the questions that arise are:

1. What is the meaning of Instrument->ListedDerivative->InstrumentType->ListedDerivative?
2. What is the difference between Instrument->ListedDerivative->InstrumentType->ListedDerivative and Instrument->Security->InstrumentType->ListedDerivative.
3. Under ListedDerivative there are only three attributes deliveryTerm, optionType and strike. Thus implying LIstedDerivatives are either futures or simple options but missing many other parameters.

Proposal

As a starting point here are three proposals:

1. AssetBase should be moved to the AssetType level instead of InstrumentBase.
2. InstrumentTypes should be specific to the type of Instrument so that ListedDerivative, Loan and Security have mutually exclusive types to eliminate ambiguity at the of type of Instrument.
3. Remove Listed from the name of ListedDerivative as it's possible to have Transferable derivatives that are not listed.

Compatibility

This would be a breaking change to v6 and thus would go into v7.

[lolabeis]

Hi @tomhealey-icma

I would slightly adjust your opening statement re "attributes" as follows:

Cash, Commodity, DigitalAsset all extend Asset base whereas Instrument is a choice between ListedDerivative, Loan and Security. Each of these types also extend InstrumentBase. InstrumentBase extends AssetBase with the attribute InstrumentType which again includes the value ListedDerivative.

To answer your questions:

1. What is the meaning of Instrument->ListedDerivative->InstrumentType->ListedDerivative?
2. What is the difference between Instrument->ListedDerivative->InstrumentType->ListedDerivative and Instrument->Security->InstrumentType->ListedDerivative.

The enum value ListedDerivative should be restricted to using the ListedDerivative type, so that one cannot use it with Security. That condition was missed amidst the large Asset Refactoring change but should really be added (unless exception, in the next Dev version, since it's backward-incompatible)

3. Under ListedDerivative there are only three attributes deliveryTerm, optionType and strike. Thus implying LIstedDerivatives are either futures or simple options but missing many other parameters.

These attributes are meant to enable to uniquely identify the listed contract, not to represent all the contract's economic terms. This is what TransferableProduct, where the instrument can be wrapped alongside all its economic terms, is for.

With regards to your proposals:

1. AssetBase should be moved to the AssetType level instead of InstrumentBase.

Not sure this was what you meant? Maybe you meant instead:

1. AssetType should be moved to the AssetBase level instead of InstrumentBase.

That's a good idea. We should add validation conditions to ensure consistency between the asset's choice and the combination of enum values.

2. InstrumentTypes should be specific to the type of Instrument so that ListedDerivative, Loan and Security have mutually exclusive types to eliminate ambiguity at the of type of Instrument.

You may be referring to the possible overlap between Loan and Security when the instrument type is Debt. I believe this is on purpose, such that a Loan is indeed a debt instrument but its asset type is Other (i.e. not Security). The validation conditions I mentioned above could apply to combination of enum values to ensure mutual exclusivity.

3. Remove Listed from the name of ListedDerivative as it's possible to have Transferable derivatives that are not listed.

What non-listed derivatives are transferable -- Are you referring to OTC derivatives? Those aren't "transferable" in the way the the CDM defines that term (i.e. they underpin a Transfer object), they can only be novated through lifecycle events. That was the essence of the delineation between transferable vs non-transferable products in CDM 6.

[lolabeis]

@tomhealey-icma

Would you like to include this one up for discussion at the next CRWG? To follow-up on my responses, I believe the solution involves something along the lines of: including AssetType as an attribute in AssetBase, with a set of validation conditions to ensure consistency between each type of asset vs the content of that assetType attribute.

We need to be mindful that, based on its description, AssetType was originally meant as an eligibility component - i.e. relatively inoffensive. By including it in AssetBase, we would be promoting to the heart of the model. So this will need careful review.

[tomhealey-icma]

In reference to AssetBase, I meant it would be better to move AssetBase to Asset. So Asset extends AssetBase. But Asset is a Choice which does not support "extends". Is it possible to allow "extends" on Choice?

[lolabeis]

Asset already achieves that by being a choice between types that all ultimately extend AssetBase. E.g. regardless of the type of asset, one can already write (using the "deep-path" ->> operator):

asset ->> identifier
asset ->> taxonomy

because identifier and taxonomy exist on all assets.

By extension, if an AssetType attribute (or components of it - it's essentially a set of enums) was included in AssetBase, it would be accessible in all assets. You may then implement conditions to ensure that the enum values are populated consistently with the type of asset.

[CDM-ReleaseManagement-OT]

Hi @tomhealey-icma, will this issue be ready to present on the CRWG?

[tomhealey-icma]

My reference to set/get the identifier in AssetBase was inside Java or the Json output.