FRAGMOS - interestRatePayout vs. ISDA 2021 Definitions - GAP ANALYSIS

[JBZ-Fragmos]

Background

As of today, most calculation terms applicable to rate products, inherited from 2021 ISDA Definitions, are present in CDM in namespaces "cdm.observable.asset.fro:enum" and "cdm.observable.asset.fro:type"

• fro:enum
  
• fro:type
  

Problem Statement n°1 : terms missing in interestRatePayout

The above components from "fro" namespaces are used by Functional model, while being absent from Product model. For instance, none is used as an attribute of FloatingRateSpecifications under InteresRatePayout.

That is causing inconsistency at Process model level, current situation being that some terms may be executed from calculation standpoint (= objects present in Functional model) without being preliminary representable and executed between parties and executed from contractual standpoint (= objects absent from Product model via any InterestRatePayout paths, or more broadly absent Event model via Execution or ContractFormation).

This means calculating terms as "black box" in regards to Trade agreement terms where such calculation terms cannot be represented.

Hereunder is a GAP ANALYSIS performed with regards to "ISDA Def 2021 Floating Rate Matrix", considering the matrix provides an overview of main terms described in the "Main Book that we would expect as attributes in interestRatePayout:

• blue figures
  • from 1 to 8 designate features present in interestRatePayout and looks mostly OK
  • figure 9 designates feature also present but that requires refactoring (further detailed in next section)
• red circles designate features missing for interestRatePayout (notwithstanding some of them may be present and already used in Functional model as reminded above in Background section)

If wanting to perform the GAP ANALYSIS by referring to the Main Book, here are the main missing terms when considering the original documentation : they correspond to the 2nd column in the Matrix "Category / Style" :

Problem Statement n°2 : terms present in interestRatePayout need refactoring

We actually find some components inherited from 2021 ISDA Definitions from another namespace than "fro", which are currently attributes of in FloatingRateSpecifications path, under InteresRatePayout. These are the ones flagged with figure 9 above, from namespace "cdm.observable.asset.calculatedrate:type"

However, when comparing such terms to original ISDA documentation they intent to capture :

• we spot some missing information (mostly the ones above mentioned in Problem Statement n°1)
• we find current struture of the model not well aligned with the exact terms and drafting style of the original documentation

as an illustration, see original terms below :

compare it with the current structure : it not well aligned , since Compouding/Averaging are considered as separate dimenstion, which looks smart drafting simplication but is eventually not clarifying the terms

• repeating offsetDays per each calculation node
• the Index Method part is fully missing
• attribute with observationParamters actually represent cap/floor features, that is not expected per attribute name, moreover it creates overlap with capRateSchedule/floorRateSchedule which already exist in FloatingRateSpecification
• bespoke rate and bespoke methods are not adressed, whereas standard documentation (2021 Def) explicitly recognize existence of such components

Problem Statement n°3 : some specific terms for Range Accruals are missing

These terms are not mentioned in core text of the definitions, cannot be found in the "Main Book" for instance, they come from "EXHIBIT II-I to 2021 ISDA Interest Rate Derivatives Definitions / Additional Provisions for a Confirmation of a Transaction that is a Range Accrual Swap")" :

We have highlighted the main terms deemed to be missing, when compared to existing objects in CDM, for the purpose of representing "Range Accruals" features :

IMPORTANTLY :
when considering above documentation, let's note two kinds of drated terms :

• "straight terms" : each term defined in the document as a concept, drafted as a particular label, associated with a specific paragraph where description is given e.g. "First Spread Rate", "Second Spread Rate", "Lower Barrier", "Upper Barrier", etc.

• "formula terms" i.e. terms of the documents where the description includes algebraic symbols or more generally describes calculations based on the mathematical composition of the "straight terms"
  for instance this one
  
  or this one as well
  

That has to be said for clarifying that current ticket/PR only focuses at this stage on the "straight components".
As regards the formula terms please other ticket/PR (new set of components in CDM, complementary and optional to existing Payout terms, fully designed in Fragmos-Chain WS, ready for production uppon business interest) #2941

Proposal = refactoring some "fro" Enum, then add to interestRatePayout

** related PR **
#3247

We want to fill the gaps between current interestRatePayout attributes with regards to ISDA Def, considering that Process Model (functions) shall ideally not use any items as abstraction with no link to Product/Event Models where related terms may be represented in CDM as part of an agreement between the parties.

• we refactor Enum objects, from "fro" namespace
• then we use them for replacing current struture in interestRatePayout
• that is for being aligned with original documentation

CORE PROPOSAL :

• deprecate existing type FloatingRateCalculationParamters
• replace it with new type OvernightRateSpecification
• which notably relies on refactoring some Enum list from "fro" namespace for using it as attributes in interestRatePayout paths (technical comment : this means cdm.observable.asset.fro is imported into cdm.observable.asset.calculatedrate)

OVERVIEW

FOCUS on MISSING TERMS

FOCUS on OVERLAPS

COMPLEMENTARY PROPOSAL :

to add missing features for ensuring minimum modelling, say "MVP" for "Range Accruals" features. Based on gap analysis compared to ISDA template above described, that result into adding 4 endpoints* :

• at least have possibility to select "SpreadRate" that being composite item made of

  • "ShortRate"
  • and "LongRate"
    

• also need to represent the key triggers for the corridor into which ref rate shall remains :

  • "Lower Barrier"
  • and "Upper Barrier"
    

new component highlighted below :

remark : on purpose we haved drafted the missing barriers not as new stand-alone attributes but as particular ones into more generic type "BespokeFeature" where other resolving features may be listed - at this stage this is "draft for discussion"

Compatibility

Most changes proposals are backwardly _incompatible

For now in current WS, objects we suggest to remove are annotated [deprecated].

Indeed, we could not be able to remove them, because this would require fixing quite a lot of broken calculations i.e. impact both "func objects" and "mapper objects" required in current Process model

Help is kindly requested for fixing func/mapper objects, for finalizing the PR, by fully removing deprecated types at target.