search

finos / common-domain-model

The CDM is a model for financial products, trades in those products, and the lifecycle events of those trades. It is an open source standard that aligns data, systems and processes and is available as code in multiple languages for easy implementation across technologies.
Other
123 stars 53 forks source link

CDM Asset Refactor Task Force - July 25th, 2024 #3029

Closed eteridvalishvili closed 1 month ago

eteridvalishvili commented 2 months ago

CDM Asset Refactor Task Force Minutes

Meeting Host: Lionel Smith Gordon, Regnosys

Date

July 25th, 2024 - 11 am ET / 4 pm BST

Untracked attendees

Meeting notices

Agenda

Materials

ARTForce 25Jul24.pptx

Minutes

Zoom info

Join Zoom Meeting https://zoom.us/j/91947398280?pwd=YS85Mmo4ejhvV2VKMlpaU1FmeDYydz09

Meeting ID: 919 4739 8280 Passcode: 867245

chrisisla commented 1 month ago

Chris Rayner / ISLA

llynhiavu commented 1 month ago

Lyteck Lynhiavu / ISDA

Oblongs commented 1 month ago

Today we had limited participation but thanks to Chris, Tom and Lyteck for joining.

On Tuesday I had presented the Phase 3 PR contents at the Contribution Review WG. There was feedback that further work was required in two areas: • FX modelling (to address potential duplication between SettlementPayout and ForwardPayout and the dilemma whether FX Spot and Forward should be modelled the same way or all forwards the same way) • PriceQuantity (a solution to address the interaction between Quantity and Observable, ie to address “the quantity of what”).

Today’s deck – attached – has a couple of proposals for alternate solutions; these are also in the latest PR#3055 on GitHub and in Rosetta.

Please review these proposals and comment on the PR or on this issue.

JBZ-Fragmos commented 1 month ago

please accept my apologies could not attend... hereunder feedback :

currencyQuantity

forwardPayout I do not agree with condition to restrict ForwardPayout to the existence of schedule for the purpose of restricting it to “strip of forwards” – we definitely need to avoid adding restrictions everywhere which do not comply with variety of real business needs and variety of product features

For instance an Acc/Decu is for sure a Forward with ObservationTerms i.e. observation dates for cumulation, etc. Having such attribute ObservationTerms will encompass the “strip of forwards” among other structures, because ObservationTerms is more generic… (as an indication, fact Observable is also present in ObservationTerms natively offers possibility to represent “ net differential price” payout in smooth manner… just to insist that proposal to add this attribute is more generic thus will solve / cover most all business needs in that matter…

Besides, there is also one key attribute obviously missing today in ForwardPayout that is the forward price itself that is today missing whereas in essence the core payout of a forward only consists in having a “fixedPrice” (fact it might be represented today via payout->PriceQuantity->price is really confusing… it is equivalent saying strike price of an option shall be represented in payout->PriceQuantity->price : this makes no sense for an option, so cannot make sense neither for a forward, hence the need to move the price attribute at FowardPayout node itself, for consistency reason)

So all in all as regards FowardPayout, would propose the following changes (and no other ones than these ones) :

for clarity, by “net differential payout” I mean “payout = quantity x ( fixedPrice minus observable) ”

(to represent such payout in backward-compatible way, just need to add both fixedPrice and consider presence of observationTerms->observable, meaning a Qualifier can easily be defined “when observationTerms->observable exists then net differential payout is qualified as having payout = quantity x ( fixedPrice minus observable), else only fixedPrice exist and observationTerms->observable is absent, so that is straight forward which payout = quantity x fixedPrice)