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 in particular business case to represent an "Accumulator" then both observation and valuation terms become required for representing the product features in accordance with related termsheet - that regardless of asset type e.g. whether Equity, or an FX, etc

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

Main Proposal - PayoutBase

• we propose to attach both observationTerms and valuationTerms (renaming of current valuationDates) 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

Additional Refactoring - ObservationTerms

• add one new attribute (existing type) :
  • observationMethod ; Enum type DeterminationMethod
• modify name of type used for informationSource
• remove attribute observable ( already done as part of ARTF)

Additional Refactoring - Observable

• add new optional attribute (existing type) for recording the fixing value observed per each fixing date

  • priceObservation type PriceSchedule ; with [metada address] for the purpose of updating datedValue embedded into PriceSchedule along with Event lifecycle represented via Event model, by leveraging any Event where the same type is annotated with [metadata location] ( see for instance FRAGMOS - FixingObservation Event #3059)

• add two (2) new conditions for consistency purposes

  • one is to ensure resetPrice is used for rate products
  • other one is forcing the usage of DatedValue for the purpose of describing properly the fixing as an association of a price value with related fixing date

Additional Refactoring - PriceSchedule

In order to indicate which type of price is at stake when recording any fixing value (depending business it may relate to an "observation", else to "valuation", or "reset", or other ones, etc.) without creating top/down list of price attributes with distinct name to correspond to each possible type, we propose to add this optional attribute to Price that is an Enum :

IMPORTANTLY :

• this Enum has other benefits for the model (see next section below)

Additional Refactoring - ObservationDates

• add one attribute name observation Date (existing type RelativeDateOffset enriched with new attribute below)
  that is to designate a kind of date to observe ; 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

• enrichment of RelativeDateOffset (existing type) with new attribute of new Enum type DateRelativeToEnum

IMPORTANTLY :

• this Enum is critical in our opinion when considering the variety of dates across all business context
• it is impossible in our experience to represent any structured products with CDM without such Enum being introduced
• yet benefit is not restricted to structured product per se - more generally, this will help to clarify the type of price at stake inside TradeLot->priceQuantity->price which as of today is suffering from abstraction, from a business standpoint (being aknoweldged that having an abstract list of price and quantity at TradeLot level has other benefits for the model that we do not intend to compromise)

• we may additionally contemplate further usage in Event model, see below how such component might be usefull to create a new instruction to record fixing observations in generic manner, also ensuring Product-to-Event consistency, by simply re-using existing types e.g. ObservationTerms and PriceSchedule, which Enum attribute named determinationDate permits as above explained to explicit the type of date to which the observation actually correspond from business standpoint

( see for instance #3059)

same if showing type name instead of attribute name :

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 - 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)