FRAGMOS - ObservationTerms & ValuationTerms

[JBZ-Fragmos]

Background

We consider that both observation terms and valuation terms are generic features to any payout type
to be populated on business case basis, therefore should not be restricted to particular types.

As of today ObservationTerms is only an attribute of OptionPayout and of PerformancePayout, and ValuationDates is only an attribute of PerformancePayout. We beleive all other types of payout may need to use such attributes.

To provide at least one example among many other possible ones, let's consider forwardPayout :

• per se, core structure of such payout does not require observation or valuation terms
• however, when used to represent an "accumulator" then both observation and valuation terms are required for representing the product features in accordance with related termsheet

That is to illustrate that the need for observation or valuation terms is not driven by the type of the payout, but by the business usage and other features of the product to be considered in addition to the core payout type, given context.

Main Proposal - PayoutBase

Related PR #3051

• we propose to attach both observation terms and valuation terms in payoutBase as optional attribute so that they can be populated or not for any payout type, on business case basis

• besides, we propose additional refactoring to some components in both ObservationTerms and ValuationDates as further detailed the sections below

main refactoring notably results in increasing consistency of current PayoutBase i.e. all kinds of "terms" are gathered same place i.e. current SettlementTerms are relevantly completed with the new attributes below highlighted : ObservationTerms and ValuationTerms

Additional Refactoring - ObservationTerms

Proposal : to add two attributes, each being an existing type :

• observationMethod ; Enum type DeterminationMethod
• priceObservation ; type PriceSchedule
  - with [metadata reference], that is to permit any relevant referencing, for instance from an Event type where fixing values are recorded per each observation date, e.g. Reset or ObservationEvent are typical type of events that could be further leveraged via priceObservation i.e. whenever fixing observation is effectively performed, one may enrich the information in related Trade, by populating datedValue series along the lifecycle, via priceObservation (see background and proposal around this topic in FRAGMOS - FixingObservation Event **DRAFT** #3059)
  - hence the new condition also being proposed, to ensure only this particular usage is made with this component when defined

Additional Refactoring - ObservationSchedule

We are currently missing item for representing manufactured schedule composed of period series (mostly used when period are irregular, thus unlikely calculable based on periodic parameters)

for clarity, there is a component which already exists for similar need i.e. representing manufactured schedule, that is type SchedulePeriod, however, this type is too specific because it was fined-tuned especially for commodityPayout (thus includes additional specific attributes for commos such as "deliveryPeriod", "fixingDates" and "paymentDates", etc.), so we cannot re-use type SchedulePeriod as it is, hence proposal to create new type to meet core need to represent a set of schedule periods, but with no other any extra features.

Proposal :

• create new type below :
  

• then add it as an attribute to existing type ObservationSchedule :
  

Additional Refactoring - ObservationDates

• add one optional attribute (already existing type RelativeDateOffset but after enrichement of this type), which business usage is to designate a kind of date to observe. Eventually, logic behind it is mostly similar to the one involved in existing type PayRelativeToEnum (e.g. say you want to pay on "Valuation_Date" or "Calculation_Period_End_Date", etc.) that is to designate a particular type of date among a given set of dates defined elsewhere in the document
  

• based on an enrichement for existing type RelativeDateOffset, with new Enum type below
  

new Enum

Additional Refactoring - ValuationDates + PerformanceValuationDates

here is recap of situation today :

• we may notably observe that ValuationDates is not an appropriate name, since this type actually contains other attributes e.g. valuationTime, determinationMethod, etc.

compare with change proposal :

• in summary, proposal is to gather all "valuation" terms currently spread in different places, under unique type and accordingly rename it appropriately, hence new name "valuationTerms" (instad of current one "valuationDates")

Changes proposals are furthed detailed below.

Additional Refactoring - ValuationDates

• rename this type : "ValuationTerms"** (considering that as of today this type does not only contains Dates but other attributes such as valulationTime, determinationMethod, etc.)
• rename existing attributes "initialValuationDate", "finalValuationDate" and "interimValuationDate" as simply "initialValuation", "finalValuation" and "interimValuation", because related type PerformanceValuationDates actually does not only contains Dates so attribute name shall not be restricted to mentioning "Dates" only
• move under this type any related terms, notably
  • initialValuationPrice, interimValuationPrice and finalValuationPrice (currently attached to PerformancePayout node)
  • also valuationTime, valuationTimeType and valuationMethod (type DeterminationMethodEnum)
• finally, add this type as an attribute in PayoutBase, so that any Payout type may use it

Additional Refactoring - PerformanceValuationDates

• rename this type : "ValuationBase"** (considering conflict name with components from other library, also given the fact type PerformanceValuationDates actually does not only contains Dates and is re-used as a base for multiple components i.E. "initialValuation", "finalValuation" and "interimValuation")
• rename existing attribute "determinationMethod" as "valuationMethod"
• add optional type "int" for recording number of valuation dates (equivalent to the same existing in ObservationTerms that is number of observation dates)

Compatibility

Renaming, as well as moving existing items, involved update in mapping
Accordingly, the set of changes proposed is not backward-compatible - hence proposal to push it under Dev

[JBZ-Fragmos]

in accordance with next steps which resulted from presenting this Github Issue to last DPBE Meeting #3080 :

• have refactored original proposal by removing the Observable from ObservationTerms, mainly for the purpose of avoiding redundancy with item interestRatePayout->rateSpecification->rateOption

• have started below gap/impact analysis with primary focus on commodityPayout and on interestRatePayout

commodityPayout

calculationPeriodDates may be removed => replaced by the same type already existing in ObservationTerms

pricingDates may be removed => replaced by the same in ObservationTerms, since both attributes are adequatly covered by similar components in ObservationTerms :
parametricDates

specificDates

specificDates

only this item may contain redundancy but together with additional specific features

• here is commodityPayout proper component SchedulePeriod
  

• compared with closer type of component we have under ObservationTerms that is observationPeriod
  

so there are two possibilities to handle this :

• A - either include a condition in commodityPayout that will simply prevent defining observationPeriod because only SchedulePeriod should be used under commodityPayout for defining manufactured/irregular series of schedules
• B - else we may remove observationPeriod and replace it with type SchedulePeriod, yet content of this type is a bit larger than "observation" per se, since there are also payment terms, and other terms specific to commos e.g. delivery etc.

would recommand just to add an addition (solution A) but happy to hear otherwise or other suggestions ?

interestRatePayout

• calculationPeriodDates may be removed => replaced by the same type already existing in ObservationTerms

• as regards need to avoid redundancy between observable and rateSpecification->rateOption

a solution may be to add this condition below :

in case you would wonder why then just not add observable as an attribute, answer is that it is requried in some cases, for instance in Range accrual, the observable in corridor may not be the same as the rateOption, sometimes it is another rate and/or it may also be another asset tyep, for instance an Equity stock, etc. hence we prefer having observable as an optional attribute and just prevent redundancy with the condition to ensure that only when there is real need to observe another type than rateOption then populating such attribute is permitted

for ALL payout[type]

have added observable direclty at payout root (thus removed out of PayoutBasis->ObservationTerms)
with same condition for each below :

for clarity, it may at first glance looks like equivalent to have observable remained under ObservationTerms, but when considering as well potential usage under Event model, eventually it seems that this will leave more flexibility in the model not to include Observable inside ObservationTerms

[JBZ-Fragmos]

@lolabeis

i have been reconsidering the original proposal, notably taking into accounts points of attention you have raised about proposal to add these two new attributes in ObserationTerms

• Observable in ObservationTerms
• priceObservation (type PriceSchedule)

as a result, i can effectively see more overlaps than expected (due to work in progress with the ARTF, that i had not sufficiently taken into account in my original proposal)...

so will refactor this proposal, but for clarity prefer closing this one, and start new proposal from clean new ref in github

[JBZ-Fragmos]

new proposal will replace this one

please see : #3114