FRAGMOS - Structured Products - Parent Story

[JBZ-Fragmos]

Purpose of this GitHub Issue :

• to document the Structured Product modelling proposal, designed by the Structured Product WG
  cf. below, sections are sorted top/down from high level view to more granular descriptions
  - "Model Design 1 - Introduction"
  - "Model Design 2 - Core Model Components - Overview"
  - "Model Design 3 - Core Model Components - Functional Meaning of Product Model"
  - "Model Design 4 - An example how to represent in the Product Model a Termsheet with "complex formula""

• also to gather as a "Parent Story" other individual GitHub Issues which will relate to this topic e.g. "Child Stories"
  - "Model Components - links to related individual GitHub Issues"
  - "Trade File CDM Distribution - List of some Termsheets with related Trade Files"

The content of sections above mentioned will be updated from time to time in accordance with the Roadmap of the WG, in terms of PRs and related documentation inside individual GitHub Issues.

"Model Design 1 - Introduction"

Purpose of the Product Model is to extend CDM payout existing list (e.g. "optionPayout", "performancePayout", etc.) with an additional new branch i.e. "structuredPayout" which will permit to properly represent mostly all types of products which involve Structured or Exotic features.

Examples of well known types of products at stake e.g. "Range Accruals" ; "Steepener", "Autocallable (incl, Memory Coupons)", "Exotic Dispersion", "Accumulators", "Lookback" Options, etc.
For clarity, the above list is not at all exhaustive, and the purpose of the Structured Model is precisely to be generic, that is to cover any type of product that involve generic structured features and related possible combinations.

Expected benefits are very high for the industry :

• 1 - structured features beign represented by a set of Objects as part of Product-Model such as CDM shall eliminate or dramastically reduce one main historical operational risk e.g. misbooking due to the fact booking scripts used to model the complex payouts are not homegeneous to the related algebraic formula in contractual documents (that is to say, whatever the setup in respective banks, eventually, booking A and booking B cannot be directly compared and both have to be manually reconciled to contractual document with no guarantee on any sides these parallel reconciliation are 100% reliable, because eventually these 3 objects, say "booking A, booking B, contractual document C") remain distinct objects thus with with "inexorable gap" between each others).

• 2 - our modelling is also building the sound basis of Smart Contract implementation into CDM, since such contracts must refer to the Product Model as the contractual "golden-source" where both "F(X)" and "X" must be described as an self-executable agreement i.e. needs to be both legally binding to the parties (which cannot be done via Functional Model or any "script" modelling, that is simply not appropriate to build any legal agreement which could then be executable per se) and self-executable hence the need for granular description of payout terms in Product Model and some refactoring in Event Model as well

The modelling design relies on 6 foundational generic items :

• and explicit representation of Payout, broken down into "corePayout" components (1), that is designing all nodes of the new structuredPayout branch, to be added to existing Payout type
• ObservableBasis (2) : end-value of the corePayout branches in Product Model, also to be re-used consistently in Event Model for capturing observation fixing / pass them through exact corePayout arguments for calculation purposes
• Knock (3) + Cap & Floor (4) + Multiplier & Divisor (5) : a set of features, kind of a "tool kit" for structuring, grouped in new type "structuredFeatures", that is attached and re-used in several corePayout components)
• AggregationOperator : a set of Enum objects, also attached to corePayout components, whenever unbound cardinality exist (0..*)

Actually, we may also count a 7th item :

• yet this one is not an object, because it is only a way to interprete in smart and deterministic manner the "branching logic" of CDM tree of paths, for completing the model, notably to represent some generic logical expression ("OR" / "AND") or preeminence order of components in payout calculations (equivalent to the role played by parenthesis in algebraic formula), etc. : the idea here is to consider that the configuration of the paths per se shall be further leveraged with high benefits in terms of representation, simply by clarifiying some interpretation and branching rules.

"Model Design 2 - Core Model Components - Overview"

"Model Design 3 - Core Model Components - Functional Meaning of Product Model"

• Payout Amount = Payout x Notional Quantity

Preliminary abstract considerations (notwithstanding "CDM " or any "Domain Language" at this stage)

• any Payout, per se, is made of (1) mathematical formula, to which may apply (2) logical expressions

• 1 - mathematical formula is made of (1-1) Arguments, either (1-1-a) variable or (1-1-b) fixed, which are related to each others by (1-2) Operators either (1-2-a) commutative or (1-2-b) non-commutative

• 2 - logical expressions are represented by the (2-1) Branching Logic itself and by (2-2) the Knock object as regards Boolean rules restricted to the specific domain language at stake here

CDM representation in Structured Modelling :

• 1 - mathematical formula

• 1-1-a : variable Arguments are represented by ObservableValue where only Observable values exist and no Price or Quantity values exist (unless being defined as relativeToEnum or referencing other Observable, say, a Price with priceExpression in "% of InitialValuationPrice" that is defined elsewhere in the trade, or similar use cases)

• 1-1-b : fixed Argument are ObservableValue where at least 1 PQ value exists (whether Observable being populated or not), either in Quantity or Price or (1-1-b) fixed, which are related to each others by (1-2) Operators"

• 1-2-a : commutative Operators are mainly represented with the AggregationOperator, that is notably able to represent the two complementary types of aggregation of a given matrix made of dates[] and or observableValues[] : either per date series say ""h"" (horizontal), or per observable series, say ""v"" (vertical), that with possible combinations and iterations, i.e. aggregation combos of aggregation vertical/horizontal embedded e.g. v (h (h (h (v (v (h)))))

• 1-2-b : non-commutative Operators, else not being a projection, are mainly described by the names of the key path nodes e.g. corePayout nodes into which the payout is brokedn down (for clarity, assuming "name" of objects shall have functional meaning in terms of calculation is not a new idea per se, that is to say thecurrent CDM version already assumes that when reading for instance ""volatilityPayout"", an implementor should know which kind of detailed formula this label actually designate... the added value in Structured Model is that objects that shall represent calculation formula are further split in all exhaustive explicit components, so the granularity level of Product Model on which implementors will map the formula components is far more closer to ultimate algebraic values in Structured Product model, than in legacy CDM model)"

• 2 - Logical Expressions

• 2-1 : branching logic consist in interpreting as below :
  (i) multiple branches on same node shall mean ""at least 1"", that is to correspond to ""Union"" rule ""OR""
  and (ii) branches nested as a child branch of a parent branch, which name usually includes prefix ""cumulative[objectName]"" shall mean ""both"", that is corresponding to ""Intersection"" rule ""AND"""
  unlimited combinations of such conditions in series can easily be represented e.g. A OR (B OR (C AND D AND (E OR F OR G OR (H AND I)))), simply by reading the branching of the relate nodes

• 2-2 : Knock means that the existence of the related object must be evaluated with boolean multiplier that is either ""x1"" or ""x0"" depending on KnockType and related boolean assessment :
  ""x0"" given KnockTypeEnum is ""IN"" and assessment is ""false"", else ""x1"" when ""true""
  ""x1"" given KnockTypeEnum is ""OUT"" and assessment is ""false"", else ""x0"" when ""true""
  each include ""cumulativeFeatures"" by nesting the object as its own attribute, also relying on the ""branching logic"" above described so that Knock conditions can be defned appropriatley, whether additive or cumulative or combos "

"Model Design 4 - An example how to represent in the Product Model a Termsheet with "complex formula"

"Model Components - links to related individual GitHub Issues = Child Stories"

• 1st shape : all the ones which would refactor existing objects and would thus have an impact on the whole model, that is to say prerequisite for the Structured Model that will hopefully also benefit to the CDM as a whole model e.g. refactoring of the Observable concept in Product Model, together with a refactoring of the Observation concept in Event Model

#2338
#2106
#2506
#2492
#2457
#2188
#2107
#2098
#2522
#2523
#2524
#2525
#2526
#2527

• 2nd shape : the "structuredPayout" branch per se, which would mostly have no impact because related components will be used only by the structuredPayout branch, this one being additional to existing ones, so embedded components will not impact existing components in other payout types

#2494
#2499
#2500
#2495
#2496
#2497
#2498
#2501
#2502
#2503
#2504

"Trade File CDM Distribution - List of some Termsheets with related Trade Files"

to be continued

[jiahaodengbb]

Would it make sense to maintain a tree structure of all issues in the parent story instead of listing the issue numbers only?

[JBZ-Fragmos]

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