Add contractDetails to Product

[tomhealey-icma]

The current model can only support contract details at the Trade level after execution and during the contract formation phase. For most financial products a legal agreement and governing law are set on the product during the creation of the product before execution. Consider bond issuance, structured products with term sheets, swap agreements based on ISDA agreements, repo transaction executed with a GMRA vs a private agreement. I propose adding a new attribute to ProductBase -> productContract ContractDetails (0..*). I'm open to this being a required field as well.

[JBZ-Fragmos]

• if to add it as an optional info to Product, I would agree
• if to replace the current place of this object (that is an attribute of Trade) or to make it additional but required at Product level, then I would disagree

hereunder reasons to document my position, hope will make sense for you and clarifies :

eventually the Product object is mostly used from business point of view as the Observable &/or the Underlier of Payout legs involved in a given Trade, so attaching ContractDetails to Product actually means you would attach Legal Terms to an Observable/Underlier which honestly looks a bit unusual

(also would lead to obvious corner cases e.g. imagine a Trade on a Basket = multiple Products you would have multiple ContractDetails=LegalAgreements... whereas obviously you want only 1 set of legal terms for the whole trade... that is why you want it at Trade level... not Product level...)

accordingly, i beleive the ContractDetails are attached in the correct place as of today that is at Trade level which present the "agreement" whether on Economics (roughly speaking "EconomicTerms") or on Legal terms as well ("ContractDetails=LegalAgreement")

besides, the reasons you provide e.g. "structured products with term sheets, swap agreements based on ISDA agreement" for me are look like the reasons why proper place for ContractDetails is precisely at Trade level, and not at Product/Underlier level :

• in practice, traders/middleOfficers will first reconcile and get agree on a termsheet during execution phase, usually they do not check legal terms (since termsheets mostly focus on core economics required for front/risk booking) at this stage so only EconomicTerms in Trade need to be populated via Execution Instruction that will path trough EconomicTerms, at Trade level
• and then as 2nd step one of the party will draft the Legal Form to be sent for further agreement, that is when ContractFormation Instruction will be populated to path through related additional terms to ContractDetails, again at Trade level

all that being, said, where i could follow you maybe is when one would like to represent some LegalTerms which are specific i.e. restricted to a given Underlier, notably in case there is a basket... I can imagine, say a mix Basket of Bonds and of Equity Stocks, why not... then you maight one to specify some LegalTerms applicable "only to Bonds" for instance...

but in such a case, I would rather suggest to have a referencing attribute at Product level, which would definitly remain optional, thanks to whicbh you could reference some LegalTerms (which per se as an Object would remain an attribute of the Trade as of today) for instance would look like below

what do you think ? that might meet the needs at Product level as optional, withtout undermining the good logic we have today that is to stay with original legal info (metadata key) at Trade level

kind regards
jb

[tomhealey-icma]

Following up on your comments.

1. I proposed adding contractDetails to product but not removing it from the Trade so you can override the product contract with a trade level contract.
2. The product always comes before the trade. When a new product is issued, the contract and legal terms such as covenants, governing law, etc are all establish and defined in the term sheet and distributed to the market before orders are even placed. And this is not just for structure products it applies to new issue bonds, loans, swaps, and even repos. If it's not a product with a term sheet it just means the counterparties have standing agreements in place.
3. Exchange traded products all have predefined contract details before trades are executed. You can't trade an exchange traded future or exchange traded option without a legal agreement in place for the product.

[JBZ-Fragmos]

thanks for clarifying Tom

until you do not intend to remove contractDetails from its current place (and you confirmed in your point 1. that you effectively do not intend to do so) then as far as I'm concerned, I would agree with your proposal

[lolabeis]

Unfortunately, the term "Product" is over-loaded and can mean different things in different contexts. But as far as the CDM is concerned, the concept is quite restricted on purpose.

The idea of a Product in CDM is that you should be able to define its underlying EconomicTerms (in short: what are the flows being exchanged) without the need to invoke an outside agreement - which is true of your examples above, be it a bond, a swap, a repo or a structured note. Yes, this will usually need further wrapping into a legal agreement (as in a note), or association to a master agreement (as in a GMRA) - but that concern should not be mingled with the Product.

This idea is embodied by the CDM namespace hierarchy: base -> observable -> product -> legalagreement and event (the latter are "siblings" that can import from one another). This proposal in effect breaks that hierarchy.

I believe a similar comment was made in a related issue: #2365

[LionelSG-REGnosys]

3. Exchange traded products all have predefined contract details before trades are executed. You can't trade an exchange traded future or exchange traded option without a legal agreement in place for the product.

The legal agreement for exchange traded products governs the relationships between two or more parties (such as a brokerage, executions services or clearing agreement) and is not specific to a particular product but usually to a venue or asset class.

[tomhealey-icma]

I think we agree that in many or most cases you cannot execute or trade a product until a legal agreement is in place, so having contractdetails attached only to a trade is insufficient to address the cases where the legal terms and governing law are required before the execution. If in fact we consider a product to be void of an legal agreement then we would need a new type, LegalAgreementProduct. Since adding productContractDetails has a cardinality of (0..1) it serves a dual purpose without impacting the concept that a product may be defined without legal terms or with legal terms.

Regarding the comment of 3) above, in a very generic sense you can define a product's economic terms without a legal agreement but the product would never be offered on an exchange until the legal agreement and governing law are defined and agreed to by any party that would even want to bid on the product.

[tomhealey-icma]

@lolabeis - following up on the CRWG meeting, please provide your thoughts and suggestions on how to add a product with contract details.

[JBZ-Fragmos]

modest contribution to the discussion :

• for me do not see any fondamental issue, provided this is an optional attribute : card (0..1)
• either attached to the product i.e. productIssuerContractDetails card (0..1) ; which is possible only if the exact list of related attributes to describe the legal terms can be defined in generic manner at product level
• if not (and i beleive such list is not the same for a Bond and for a Commodity, or for an Index/Tracker being issued whether by a Market or private Issuer e.g. proprietary index, etc.) - then would be a set of distinct new types, eventually still optional in any case (0..1), each to be attached to a given type of product e.g. index, commodity, security, etc.
• as an indication, I see no business case so far for OTC (= contratcualProduct) or foreignExchange or basket, which i beleive cannot be issued per se...

hope this helps

[lolabeis]

This issue was discussed off-line between maintainers, so I'm posting the takeaway from that conversation here for audit trail transparency.

The approach being considered would not encumber the current Product representation with contract details. Instead, the proposed approach would introduce two layers of Products:

1. one with economic terms only, still in the product namespace - aligned with current representation.
2. one were economic terms are further wrapped with legal terms, in the legalagreement namespace.

A model proposal is being worked on how this could be implemented.

In addition, qualification logic will need to be enhanced so that it can work at those different layers. This is tackled by a separate issue: #2365

[tomhealey-icma]

Changes to asset/product model in review.