FRAGMOS - Acc DRR Project - Acc/Decumulator = CumulationFeatures

[JBZ-Fragmos]

BUSINESS NEED

• To represent products where “NotionalQuantity” (i.e. CDM item “PayoutBase->PriceQuantity”) increases in periodic manner

  • increment period may be leveraged
  • increment period and/or lever attributes may be guaranteed, or not i.e. contingent features usually exist, of both Knock-Out and Knock-In types
  • counting rules of days (say “period multipliers” for convenience) in period may not be fixed, due to start/end anchor being resolvable dates (i.e. say period start/end dates is “relativeTo” the Knock-Out date for instance, then this is an observable date, not known yet, not a given date value)
  • increment settlement may be cash or physical, or both with percentage split (e.g. “X% cash” vs “Y% physical”)
  • strike price is expressed both in X% of initial price and in absolute value (both expression are required for business reasons)
  • payable or delivery price of increment settlements does not always equal to the strike, that is to say it may be “X% of strike”
  • dividend treatment has to be specified, whether reinvested or not in the increment value, also net ratio has to be clarified (fiscal %tage), etc.
  • some product are both “Acc” and “Decu”, via “Privot Price” which functional meaning is to create an additional Knock condition to the original Knock In Price

• To represent a final payout that is described in termsheets as applied to a “sum” of multiple “period multipliers” – that is to say, with Final Payout = Payout x Notional Quantity, where :

  • “Payout” is usually “optionPayout” or “fixedPricePayout”
  • “Notional Quantity” = (Multiplier1 x Multiplier2 x Multiplier_3a&x) + (Multiplier1 x Multiplier3b&y) + ( Multiplier1 x sum[Multiplier4(n)] ) = Multiplier1 x { ( Multiplier2 x Multiplier3a&x ) + Multiplier3b&y + sum[Multiplier_4(n)] }, where :
  • Multiplier_1 is the core unit quantity, to be incremented (e.g. « 30 shares »)
  • Multiplier_2 is a lever (e.g. « 2 »)
  • Multiplier_3a(x) & 3b(y) are respectively the total count of knock-In days, whether « less » or « greater », where « a » or « b » is one or the other, depending if an « Accumulator » or a « Decumulator » - and « (x) » or « (y) » represent Pivot Price if any, being « greater » or « less »
  • Multiplier_4(n) is the total count of days in period[n], possibly "guaranteed" when Knock-Out compromise it
  • Besides, net counting for all Multiplier needs to be adjusted whenever Knock-Out would occur (that is causing a “stub” in the cumulation period at stake)

EXISTING MODELLING FEATURES - GAP ANALYSIS

• To represent cumulation feature :
  • Frequency type is an attribute of QuantitySchedule in TradeLot->PriceQuantity that may be referenced in PayoutBase->PriceQuantity
  • refactoring gap : very poor item, compared to complex ObservationPeriod terms required + having Frequency an attribute of PriceQuantity per se might be questioned : is it not a Payout attribute, because involving further observations criteria which are eventually defined in Payout terms
• To represent contingent features :
  • TriggerEvent type exists
  • refactoring gap : only exists as an optionPayout attribute + heavy to manipulate (need to duplicate to distinguish whether “In” or “Out” in the name of the nodes) + cannot represent referenced observable (as well as other features e.g. triggerLevel of type number, thus has no unit, etc,)

FINAL PROPOSAL

[JBZ-Fragmos]

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

HERE IS REFACTORED NEW PROPOSAL

• this proposal is simpler than previous one
• (you may want to compare recap below with abvoe description on top of this Ticket)

RECAP

DETAILS : all objects :

[lolabeis]

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]

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 :

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]

have pushed updated PR

• this PR update notably removes DividendApplicability because it seems this item was not that clear, so will further will SMEs if really requested or not
• and add "underlier" as an optional attribute of FixedPricePayout, with an update of descriptions as below (changes are highlighted in yellow)

For clarity,

• this proposal is "strategic", by trying to minimize model impact for Prod, hence adding "underlier" as an optional attribute, not to "break" current usage without any underlier
• but would recommand further refactoring in the future (would be separate PR, of course), notably when comparing FixedPricePayout with ForwardPayout. Indeed, I beleive these two at some point shoudl be "merged" (but that is not purpose as part of this PR, that was obly said for future discussions or other PRs about it)

[JBZ-Fragmos]

@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) :

• either "strikeMinusObservablePrice" thus "bearish" one (that is to say this is "Put-like" if disregarding the 0 floor),
• else "observablePriceMinusStrike" that is the "bullish" one (so this is "Call-like" if disregarding the 0 floor)

that may be alternate way of modelling :

• we could create this new payout (instead of amending the existing fixedPricePayout by adding to it an "underlier", meaning current fixedPricePayout could remain as it is for now...)

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")