FRAGMOS - BespokePayoutFormula ( ex- Structured Product)

[JBZ-Fragmos]

Background

The initial set of core components referred to in prior descriptions as "StructuredPayout" has been refactored into "BespokePayoutFormula"

• related PR : JEAN BAPTISTE ZIADE BespokePayoutFormula_new #3128
• related Distribution : FRAGMOS - DISTRIBUTION - BespokePayoutFormula #3038

What is "BespokePayoutFormula" ?

BespokePayoutFormula is a set of components that introduce in CDM

• a granular representation of any Payout terms which eventually consist in a calculation formula
• inside the Product model (that is to say, using only genuine type objects, not using any func objects.)

Importantly :

• benefit of BespokePayoutFormula is not restricted to the description of "structured/exotic" features ; meaning it is applicable to any business cases (Trade of any kinds, Lifecycle Events, etc.) whenever there is a need to describe formula terms at granular level - examples
  • to describe Averaging or Compounding or Discounting formula involved in classic Interest Rate Swap
  • to describe exhaustive payoff formula of Variance Amount or Volatility Amount or Correlation Amount in related swaps,
• BespokePayoutFormula is complementary (thus not replacing nor contradicting with) existing Payout attributes ; it bring new dimension of information that is how the Payout terms, whenever existing, may be composed into "formula"

each attribute is described with details in below sections

• "Proposal Overview"
• and depending your appetite to further drill down, you may also read next section "Proposal Details"

BespokePayoutFormula is primarily introduced as an optional attribute of existing Payout terms, one may consider it as a local extension of existing Payout terms, whenever there is a need to represent related terms details at more granular level.

example in OptionPayout :

example in PerformancePayout (attached per each returnTerms type)

example in InterestRatePayout :

Other business cases beyond trade description may be contemplated, for instance the BespokePayoutComponent would be re-used in Event model - hereunder an example to build new Event say "PayoutCalculation"

hereunder "payoutFormula" is actually type object "BespokePayoutFormula"

Why refactoring previous proposal StructuredPayout ?

because of some limitations or issues encountered, and based on WG feedbacks :

• focusing primarily on concept of "product complexity" per se is eventually not the relevant driver, at least not the only one ; moreover such concept is "grey zone" (hard to fix it), to which CDM model should therefore be agnostic by design, moreover the frontier between "vanillas" and "exotic" necessarily evolves with standardisation evolves ; as an example, "Range Accrual" may be considered as "exotic", whereas related features are explicitly described in ISDA 2021 Definition, which could let us say that now such terms became actually "vanilla"(="standards")
• having "StructuredPayout" as new node in existing list of Payout terms looked like potentially "forking" existing model, with no certainty why some features would be in "StructuredPayout" branch or not compared to features which already exist in current legacy Payout terms
• potentially compromising the existing Qualifier logic in case given product could be booked either under original legacy branch, else as well under StructuredPayout which by essence could replicate "vanilla" as well...
• looking to the details, number of new components was quite important as well as naming method (long names, etc.) etc. so it looks like main concptual basis was fine (e.g. aggregation terms, etc.) but that simplification effort was however desirable

What benefits with new proposal BespokePayoutFormula ?

• Enlarge the Scope of Business Cases
  (i.e. no reason to restrict the outcome of the new modelling proposal to so called "structured/exotic" products)

  • (1) benefits also exists for "vanilla"/"standard" products, depending business background

    • example 1 : say there is no Master Confirmation Agreement in place with particular Counterparty, then there is benefit to represent granular fomula of Payout terms in CDM, since this permits to digitize the whole scope of the agreement with same level of details required in Long Form Confirmation e.g. to represent for instance formula of non-linear returns such as variance, volatiliy or correlation for which parties need to agree on detailed formula
    • example 2 : there is an ISDA document to which parties being CDM user may refer to e.g. templates dounf udner Exhibit of ISDA definitions, but still, related formula content would also need to be represented in CDM :
      

  • (2) there are benefits beyond Product model at Trade inception, for instance in Event model as well

    • e.g. new event "Payout Calculation" to complement existing events such as "Observation" or "Transfer", say for solving CashFlow breaks where you need to know all details of calculations to spot exact root break values
    • e.g. new event "Valuation", for which BeposkePayoutFormula is ready-made basis such new type may "extends"

  • (3) implementation of CDM SmartContract : this kind of artefact requires granular inputs and outputs, all together both human-readable, machine-executable and legally-executable all of which being by design features coming with BespokePayoutFormula

• Strengthen Model Consistency :
  the flexibility that BespokePayoutFormula introduces in the model does not at all contradict with strong objective of ensuring standard Payout terms. To the opposite, new proposal is precisely strengthening model consistency :

  • (1) granularity of description permits to improve the qualifier logic, for DRR usages or for any other usages
  • (2) placing the new feature locally at each existing Payout level permits to leverage the existing Payout standard terms for ensuring convergence of booking models (that is made concretely in model by defining condition per each Payout level, to ensure BespokePayoutFormula terms are locally bounded in accordance to the particular Payout type for which they are defined (example : there is minimum standard booking model for an "option", even if bespoke, compared to "volatility swap", etc. : this can be enforced via conditions)

• Smooth Change Management in order to facilitate/accelerate release for Prod :

  • (3) the new proposal has been simplified compared to previous StructuredPayout (e.g. less new components, more existing components re-used, shorter name of attributes, name with more straight signification, etc.)
  • which notably permitted to model the PR directly in CDM Prod version, with backward-compatibility

Trade Samples Distribution

The sample files are attached in #3038

We shall start with Product model by providing a Trade File Distribution for the set of product below, selected by the WG given business interest (e.g. trading volumes) and educational interest in terms of booking model for good range of features, wrapper and asset classes :

• Sample of "structured/exotic" products :

  • Autocallable and Callable swaps
  • some Exotic options (e.g. Lookback, etc.)
  • Range Accruals and Steepener swaps
  • Acc/Decumulator (that including a sample of Target)

• Sample of "classic" products (though not considered "structured", some features involve calculations which details can be described with BespokePayoutFormula - that may be notably required when no Master Confirmation Agreement or no ISDA reference documentation exists where such details would be sufficiently described)

  • IRS or CCS with Compounding feature &/or with Averaging feature
  • Variance swap or Volatility swap or Correlation swap

Roadmap

For clarity, highlevel target timeline is as below :

• Already Done : root BespokePayoutFormula has pushed in PR as new optional attribute of 3 main legacy Payout :

  • optionPayout -> bespokePayoutFormula (0..1)
  • interestRatePayout -> bespokePayoutFormula (0..1)
  • and performancePayout-> returnTerms-> [...] -> bespokePayoutFormula (0..1), where [...] designates each type of return : priceReturn, volatilityReturnTerms, varianceReturnTerms and correlationReturnTerms

• for clarity, as far as structured products per se are concerned, most of them also requires two specific components

  • Autocallable re-using existing components in attribute but extending new type KnockCondition (that is introduced in model as part of the BespokePayoutFormula set) cf. FRAGMOS - Autocallable Provisions #2502
  • and Callable only re-using existing components in attribute cf. FRAGMOS - Callable Provisions #2503

• July 2024 :

  • trade file distribution : cf. above mentioned products
  • PPT Deck Presentation = need to describe the proposal in user-friendly format

• Aug-Nov-Dec 2024 :

  • calibrate/adjust PR = incorporate maintainers feedback
  • make necessary presentations to other WG, etc.

• **H1-2025 ** :

  • release to Prod.

Proposal Overview

"BespokePayoutFormula" is a generic set of composable features to describe formula and features of Payout terms at custom granular level, by emulating a "payout algebra" (a) inside Product model (b) :

• (a) payout algebra means no general abstract math but specific business logic precisely based on domain language e.g. for instance using operators such as "KnockCondition" or "Cap" etc., which functional signification in model obviously leverages users acceptance of basic derivatives business background, as notably documented in ISDA Definition
• (b) inside Product model means in this context a set of components that is no func object but only type object, that being aligned with canonical CDM modelling per which type object are input values to be consumed by func object (and not the opposite, meaning notably that the description of Payout terms aggreement shall exclusively rely on type object so never on func objects, which per say eventually remains a 'black box' piece of code from a contractual and operational standpoint, technically similar to so-called "script" in-house languages, that is to say func object cannot be used for the purpose of modelling a contractual agreement)

Overview of core components :

• 1 set of 3 types which composable logic permits to represent basic arthmetic operation :

  • PrimitiveValue (type to represent "F(X)=X" that is to say trivial operation, where "X" is an attribute of type BaseValue which contains the leave end-value of type PriceSchedule or QuantitySchedule)
  • DifferentialValue (type to represent "F(X)=X-Y" where "X" or "Y" are intermediary node which contains the two other ones, for composability purposes)
  • FractionalValue (type to represent "F(X)=X/Y" where "X" or "Y" are intermediary node which contains the two other ones, for composability purposes)

• 1 component which represents the method for ValueAggregation that the model requires to exist whenever there is multiple instance of given node value to be aggregated into single one, which main attribute is an Enum object e.g. Sum, Multiply, Min, Max, Average

• 1 component to represent ValueOperation that is a set of 3 components, each corresponding to "classic" structuring feature, based on Derivatives Domain Language (as an indication, these components were referred to as "StructuredFeatures" in prior proposal under StructuredPayout) :

  • KnockCondition : permits to define boolean conditions as regards the existence/non-existence of related object
  • CapFloor : permit to represent respectively a Min or Max value that will bound the value of the related object
  • MultiplierDivisor : permits to represent value with multiplier or divisor effect (for clarity, these components are not just "simple" type Quantity or type number... they come with specific features, hence why creating new type for each)

• 1 component CalculatedValue which purpose is to capture the resolved value at each node, when any (which leave end-value is logically of same type than resolvable value i.e. type PriceSchedule or QuantitySchedule)

• 1 component BespokeName that is of type string which permits implementors to define any custom name in context (that without compromising the backend calculation logic of the model, of course ! since the implementation is based on considering the type object per se, thus is agnostic to any string value that might be defined as an attribute of any type).

Proposal Details

BespokePayoutFormula is a Payout Algebra inside Product model of CDM, which relies on 6 pillars :

• (Pillar 1) CorePayoutValue : a set of three atomic root functional operations, composable within each others :

  • PrimitiveValue to represent the trivial operation "F(X)=X" where "X" is an attribute of type BaseValue which contains the leave end-value of type PriceSchedule or QuantitySchedule)
  • DifferentialValue to represent a substraction "F(X,Y)=X-Y" where "X" or "Y" are intermediary nodes Long and Short (which extends the CorePayoutValue for composability purposes)
  • FractionalValue to represent a division "F(X,Y)=X/Y", where "X" or "Y" are intermediary nodes with attributes Numerator and Denominator (which extends the CorePayoutValue for composability purposes)

The type for Long, Short, Numerator, Denominator is actually same as BespokePayoutFormula, which implements the composable logic of the model.

Any composition necessarily ends with a BaseValue node where the end-value is defined, which in essence consists in a required choice condition between

• fixedPrice (to represent any fixed argument in payout)
• observablePrice (to represent any variable argument)

Both fixedPrice and observablePrice are of same type PriceSchedule, both with metadata annotation for referencing related values in TradeLot->PriceQuantity or in any Event Primitive Instruction where the presence of such end-value component would be needed (e.g. refactoring observationEvent, create new event payoutCalculation, etc. that is actually opening a lot of possibilities for further re-use of BespokePayoutFormula components accross Product-to-Event model).

• (Pillar 2) ValueAggregation to represent possible aggregation of multiple instance of any node built with composable logic, knowing that the 3 composable components have unbound card (0..*). The main attribute here is an Enum list of commutative Operators e.g. Sum, Min, Max, Averaging, etc..

From a functional standpoint, Enum value represents which method is used to turn multiple value into one single value.

Importantly, the ValueAggregation not only exist when multiplity is visible as an immediate value series in array but also whenever multiplicity comes from time series i.e. when ever type DatedValue is embedded, typically in PriceSchedule that is ultimate type of the BaseValue.

That is to say aggregation may apply along two dimensions :

• value series
• or time series i.e. made of datedValue in array

• value series (given one date, logically the date on which aggregation is performed) :

  • use case example : for WorstOf, need is to aggregate minimum value among multiple instance of fractionalValue = value(*) therefore booking model is : valueSeriesAggregationEnum->Min

• time series (given one observable with datedValue, typically PriceSchedule with value observations)

  • use case example : for Lookback,
    • if Fixed put : max(0, K−min[S()]), need is to aggregate minimum value as well, but now among multiple instance of **observablePrice()** = datedValue(*) therefore booking model is : datedValueSeriesAggregationEnum->Min
    • if Floating call: max(0, S−min[K()]) same model datedValueSeriesAggregationEnum->Min, but for **fixedPrice()** = datedValue(*)

Interestingly, examples above are showing how the model is leveraging generic bottum-up logic, in accordance with CDM Design Principles e.g. same type "AggregationMethodEnum", moreover with same value "Min" is used for modelling distinct business features.

In essence, combining CorePayoutValue and ValueAggregation components is the core engine of the algebra.
Considering that the functional signification of each respective type is both human-readeable and machine-executable, the algebra components from the Product model are ready-made inputs for implementing any Process model i.e. func object with a [calculation] annotation.

Additionally, the core algebra is extended with typical operations inherited from derivative business (3) and with a way to represent basic logical conditions (4) :

• (Pillar 3) business operations are represented with type ValueOperator, mostly inspired from usual features found in structured product terms :

  • CapFloor : represents the functional operation [ F(X,Cap) = min(X,Cap) ] or the functional operation [ F(X,Floor) = max(X,Floor) ] where : [Cap] or [Floor] is the value of the barrierLevel for the given barrierType i.e. Cap or Floor and [X] is the value of the object for which CapFloor is defined as an attribute.
    

  • KnockCondition : represents the funtional operation [ F(X,In) = X x (Boolean) ] or the functional operation [ F(X,Out) = X x (1 - Boolean) ] where : [In] or [Out] designates the knockType, [Boolean] equals [1] when the triggerCondition is verified as "true", else equals [0], and [X] is the value of the object for which KnockCondition is defined as an attribute. Accordingly, this specifies that the existence of the parent object for which KnockCondition is defined as an attribute is contigent, either because it does not exists until the condition is verified as true, which is defined as the Knock-In type, or because it does exist unless the condition is verified as true, which is defined as the Knock-Out type.
    

  • MultiplierDivisor : represents the functional operation [ F(X) = X x M ] or the functional operation [ F(X) = X x 1/D ] where: [M] is the value of a Multiplier, [D] is the value of a Divisor and [X] is the value of the object for which Divisor is defined as an attribute. If any, multiple instances represent a straight concatenation of the same functional operation e.g. say Multiplier[M1], Multiplier[M2], ..., Multiplier[Mn] exist, also possiby with Divisor[D1], Divisor[D2], ..., Divisor[Dm] then this represents the functional operation [ F(X) = X x M1 x M2 x .... x Mn x 1/D1 x 1/D2 x .... x 1/Dm ].
    

• (Pillar 4) not any object per se, but an intrepretation of the 'branching logic' at stake i.e. the types of nodes relationship that may result from the composable logic, that consists in considering whether (a) multiple instance exist at same node in array, else (b) multiple instances exist as series of nested nodes :

  • (i) for representing associativity rules, that is to say the order according to which operations shall be executed (that is mostly described with parenthesis in usual languages) - use interpretation rule (a)
  • (ii) for representing logical condition 'OR' : use also the interpretation rule (a)
  • (iii) for logical condition 'AND' : use interpretation rule (b).">

• (Pillar 5) component CalculatedValue which purpose is to capture the resolved value at each node, when any (which leave end-value is logically of same type than resolvable value i.e. type PriceSchedule or QuantitySchedule)

• (Pillar 6) component BespokeName that is of type string which permits implementors to define any custom name in context (that without compromising the backend calculation logic of the model, of course ! since the implementation is based on considering the type object per se, thus is agnostic to any string value that might be defined as an attribute of any type).

Compatibility

Importantly, this refactoring also consisted in ensuring backward-compatibility - hence related PR is drafted directly under CDM Prod. version (that is so say any changes in PR shall be new types only or re-using existing types with optional cardinality as need be).

Model Benefits vs. CDM Design Principles

• scallability : backbone of the model to be encoded in backend is reduced to a limited number of core types, which exhaustive scope is eventually produced via composable logic between them
• machine-readeability : each core type designates a unique and basic operation (e.g. "X/Y", "min(X,value)", "value x Boolean" etc.) for deterministic implementation of any calculation
• human-readeability :
  • name of type is always basic, either per se (e.g. "Numerator", "Denominator") else per Domain Language (e.g. "Cap", "Floor", "Long", "Short', etc.)
  • each type has optional attribute bespokeName of type string that may be leveraged in may ways by implementors, whenever needed e.g. display custom terms in GUI or Termsheet templates, etc.
• interoperability :
  • the whole logic of representation relies on the functional signification of the type of objects per se (i.e. from backend standpoint, the modelling is fully agnostic to any bespokeName value for instance)
  • while Qualifier logic may apply in complementary manner as need be, in line with bottom-up Design Principle, thanks to granularity of the composable model
  • also CDM conditions can usefully specify some restriction to the generic modelling whenever required, that is to say depending root Payout type where BespokePayoutFormula may be defined (example : at optionPayout level, condition shall enforce root "DifferentialPrice" and "Floor" to exist with "value=0", that is for ensuring that whatever composition starting from optionPayout node will always correspond to generic payout of any option : "max(0;K-S)" or "max(0;S-K)" that is per se a Floor=0 applied to a DifferentialPrice)