FRAGMOS - Structured Products - Child Story 3 - AggregationFeatures

[JBZ-Fragmos]

BACKGROUND - OVERVIEW

We represent 𝐚𝐠𝐠𝐫𝐞𝐠𝐚𝐭𝐢𝐨𝐧𝐅𝐞𝐚𝐭𝐮𝐫𝐞𝐬 with symbol "Æ" for convenience.
It is an Enum list of functions, all basic operators with commutative property.

• Each Enum value designates an aggregation type of multiple inputs[*] into one single output
  = Sum, Multiply, Min, Max, Average.
  As an example of business case, "Min" would typically be used to represent a "WorstOf" feature, etc.

Besides, 2 sub-types exist to represent aggregation

• either per observable(...) series Æ.v(...)
  exact object name is "multipleObservableAggregationPerDateEnum"
• or per date[...] series Æ.h(...).
  exact object name is "multipleDateAggregationPerObservableEnum"

Conceptual basis for having two complementary types of aggregations, is the consideration that any Payout variables eventually consist in pairs = value + observation date i.e. say “Payout” means “f(x)=y” then “x” and “y” are “datedValue”(=value + date)

One may see this as a matrix :

• observable in rows ; then multipleObservableAggregationPerDate Enum represents "vertical" aggregation (“v” values in matrix) of “observable” series, this is why we deisgnate this function by Æ.v(...)
• dates in column ; then multipleDateAggregationPerObservable Enum represents "horizontal" aggregation (“h” values) of “date” series, this is why we deisgnate this function by Æ.h(...)

In addition :

• sub-type of averaging may be defined e.g. Arithmetic, Geometric, Harmonic.

• alternate types of Æ may be defined e.g. either "nthFromMinToMax" or "nthFromMaxToMin" ; this ones does not turn multiple inputs[n] into 1 output, but intends to turn multiple inputs[n] into multiple outputs[m] as a sorted series. As an example of business case, this features would be used to represent "rainbow" features or contingent "multi-baskets" etc.

Last not least, sorted combinations of aggregations may be represented, when using the similar type "cumulativeObservationConditions" nested inside parent object "obsevationConditions"

Let's illustrate with an example - say payoff formula is as below

meaning the need is to represent a payoff that consists in making first an average per each underlier in a basket made of 3 underliers, for instance observing 5 fixing, and then selecting the worst of them

the modelling would be as below :

CDM TYPE DESCRIPTION

focus 1
same type NewBasicCommutativeFunctionsEnum
re-used for both dateSeriesAggregationPerObservable and observableSeriesAggregationPerDate :

focus 2
same type NewRankingMethod
re-used for both dateSeriesRankingPerObservable and observableSeriesRankingPerDate

BACKGROUND - CONCEPTUAL BASIS

The original idea was to consider that given payout formula "F(X)", then "X" might not be straight value, but a resolvable value, precisely a value resulting from "aggregation" of multiple values at source i.e. would actually be "F(Æ(x))" with "X=Æ(x)".

Then the determination of the exact list mainly result from the below considerations :

• we only want "commutative" functions
• we only want "basic" functions as part of the Æ Enum list

which in turn result from these upfront model design considerations :

why only "commutative" ?

• non-commutative properties of payout formula terms would be mainly represented by the label of the "name of corePayout" components in the model (which is the foundational ground concept of DomainBased Language such as CDM) or via the "Branching Logic" itself by considering "nesting" and nodes relations
• multiple instance properties of objects in CDM is defined by "cardinality", meaning that no "ordinality" / no "sorting" meaning of values in array exist in the model design, and that core feature should not contradict nor have unexpected side-effect with that regards

why only "basic" ?

• non-basic functions would embedd interpretation risk into the model, that could undermine scallable usage of CDM
  • for representing digitized agreements that shall be legally binding to the party with clear meaning in case of dispute i.e. core components shall be valuable to court thus shall not refer to complex mathematical functions which exact signification or formula is not straitgh (for instance "correlation" is not straight meaningfull, is is "Pearson" type ? another tpe ? linear or not ? etc.)
  • eventually for representing SmartContracts, which must rely on clear 'golden-source' terms, be deterministic, self-executable with almost no (or say minimum) interpretation of the Product Model at source, etc;. which all in all means foundational functions shall be 'basic' as far as possible

and all in all :

• because exhaustiveness of payout formula description in the model does not require that all mathematical properties shall be defined in same type of objects (it is not because "[ a+b + (c / d) ]" can be read as one chain of symbols at same level e.g. parenthesis priority "[", values "a", operators "+", etc. that a model should represent each of them also at same level)
• instead our model proposal precisely relies on the combination of "heterogeneous" items "F(..)" with names of objects and "X" with Enum aggregation values "Æ" to represent eventually as consistent/exhaustive formula "F(Æ(x))" with "X=Æ(x)", and parenthesis properties also represented, etc.

[JBZ-Fragmos]

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