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
137 stars 59 forks source link

FRAGMOS - Acc DRR Project - Acc/Decumulator = CumulationFeatures #2746

Closed JBZ-Fragmos closed 6 months ago

JBZ-Fragmos commented 7 months ago

BUSINESS NEED

EXISTING MODELLING FEATURES - GAP ANALYSIS

FINAL PROPOSAL

image

image

image

image

JBZ-Fragmos commented 7 months ago

TAKING INTO CONSIDERATION LAST FEEDBACK from https://github.com/finos/common-domain-model/issues/2669

HERE IS REFACTORED NEW PROPOSAL

RECAP image

DETAILS : all objects :

image

image

image

image

image

image

image

image

image

lolabeis commented 7 months ago

This proposal was discussed at the CDM Derivatives Products and Business Events Working Group - March 13th, 2024.

It will need to be brought back there as there was not enough time to go through all the material, and comments were raised in the part that was presented.

JBZ-Fragmos commented 7 months ago

as raised during DPBE March 13th, one main issue is that "underlier" is not part of FixedPricePayout, which per se if very surprising...

indeed, this looks inconsistent with business purpose of such a payout that i cannot imaging being there for modelling something else than such payoff formula e.g. "Payout Amount = Quantity x (Fixed - ObservablePrice)" which necessarily means there must be an "underlier" - if not, to what kind of ObservabkePrice the "FixedPrice" may be compared to for the purpose of calculating price differential, eventually ?

interestingly, when reading the current "description" of this type it looks like above intrepretation is correct i.e. FixedPricePayout would represent a price differential, thus by reference to an underlier, and main use case mentioned as an example in the "description" is "Commodity underlier -- cf. quote below from Rosetta :

image

indeed, this type of payout is mostly used for Commodity...

overall, I definitly see no reason /no sense of such a payout without underlier...

as an information FixedPricePayout and OptionPayout are very closed, since the second one is just the first one with a Floor=0, [ meaning Max(0 ; FixedPricePayout) = OptionPayout(Call) ] that is to emphasis that for consistency purpose, if admitted taht optionPayout has an underlier, then fixedPricePayout shall also have one...

accordingly, would juts recommand to fil this gap by adding "underlier" as new attribute of FixedPricePayout...

will add it as part of PR and will push this prosal

JBZ-Fragmos commented 7 months ago

have pushed updated PR

For clarity,

JBZ-Fragmos commented 7 months ago

@lolabeis as an indication, as part of structuredPayout there is a "corePayout" that is named "DifferentialPayout" which is actually the parent node for two types of end-payout (both are using a unique type behind, only the "naming" creates the diff) :

that may be alternate way of modelling :

of course no other "structuring features" would come, I would just add basic new payout DifferentialPayout which will extends payoutBase with the basics you may for instance find in fixedPricePayout, but wiht of course an "underlier" attribute...

i'm not "pushing" here any item from structuredPayout in indirect manner, i'm only proposing, so if you would prefer at this stahge stays with original proposal above which only consists in adding "underlier" to fixedPayout, for now would be fine for me as well (though it will not be easy to qualify whether "accumumator" or "decumulator" is at stake because current fixedPricePayout does not indicate whether the price differential is "bearish" or "bullish")