FRAGMOS - Structured Products - Child Story 2.1. - structuredFeature 1 : Knock

[JBZ-Fragmos]

BACKGROUND - GAP ANALYSIS

we may start with a "gap analysis" about this particular feature, because there is already an existing one in CDM today that is Knock type which contains two attributes both using same type TriggerEvent type - which current usage as an attribute is only used in model for optionPayout

here is Knock type content :

graphical view of details for TriggerEvent type (used as Knock attrinutes)

graphical view how this looks like when effectively used in Product model as optionPayout attributes :

Gap Analysis = limitations and issues with the current representation :

• Knock type only exists for the purpose of "renaming" the TriggerEvent type either as "knockIn" or "knockOut"

  • that is almost "a type for nothing", thus one node for nothing (would expect just Knock to exist with all attributes at this level without having another type in between such as current TriggerEvent which is carrying current end-value attributes)
  • but more to the point, being either "in" or "out" type of Knock is core value information, both in terms of business meaning and functional implementation when interpreting the Knock for assessing and calculating how it affect the value of the object it is attached to so we would not expect so core value being just modelled with the name of the type TriggerEvent
  • such Knock with TriggerEvent as attribute cannot handle multiple Knock conditions, unless using Knock as an array [*] but still each instance would have both "knockIn" and "knockOut", repeated twice in each , etc.

• in TriggerType which has end-value attributes

  • featurePayment attribute creates an overlap to Payout terms or maybe is filling the gap for what should be better described in Payout terms intead of having suchfeaturePayment attribute - that is to say, Knock purpose is only to trigger or not existence of Payout (or any object it is attached to), not for the purpose of describing Payout obligations...
  • schedule is name of type behind it that is AveragingSchedule, which is limitation to only kind of "aggregation" of multiple values (other exist as we know e.g; "min", "max", "sum", etc.)
  • triggerDates is only a list of dates[*] which is very poor object to describe all dates features e.g. periodic dates, adjustment parameters, frequency, offset, etc.
  • trigger is of type Trigger that is made to describe the Price level per se, as well as conditions whether observable is "less" or "geater" etc. which has limitations below :
    • trigger value per se ,named 'level" and "levelPercentage" both are of type number which is poor notaby considering it is core value information no currency, no unit, that is potential operational risk if there is dispute because of digits involved in exact Price, etc; also no possible referencing to Price we could have defined in TradeLot->PriceQuantity, hence the heavy way to express the level both absolute and precentage by using "names" of type number, whereas Price has priceExpressionEnum attribute designed precisely to represent this multiple way to express a same Price...
    • current conditions in TriggerTypeEnum only cover Single underlier... they simply do not cover Basket case...
    • current condition in TriggerTimeTypeEnum are quite limited to 2 values "Closing" or "AnyTime"
  • there is no attribute to specify which asset is being observed, assuming implictly this must be the Underlier... but in practice, for sure it is not necessarily the case...

NEW TYPE PROPOSAL

[JBZ-Fragmos]

any item related to this Issue is either closed or re-open under this one :
#2941