FRAGMOS - metadada for all Price occurrences in Payout

[JBZ-Fragmos]

Background

As of today, there is neither consistent usage (ISSUE n°1) nor sufficient leverage (ISSUE n°2) of metadata referencing across the model where Price exists, notably when used as an attribute of components in Payout paths.

For clarity, situation is the following :

• Price already has proper annotation [metadata location] in TradeLot->PriceQuantity
• but not all kind of Price components inside Payout can actually benefit from this existing structure, because the corresponding annotation [metadata address] is missing for these components.

ISSUE n°1 : inconsistent usage of metadata references

EXAMPLE of current inconsistent use cases :

• performancePayout->initialValuationPrice is a kind of Price type attribute inside Payout path, which already has expected annotation [metadata address] so it can be referenced from TradeLot->PriceQuantity
• to the opposite, optionPayout->strike is a kind of Price type attribute inside Payout path, which is currently missing the annotation [metadata address] so it cannot be referenced from TradeLot->PriceQuantity

There is no reason why some Payout attribute of type Price have the annotation that permits for being referenced from TradeLot->PriceQuantity whereas some other components of same type Price in same conceptual place (i.e. Payout attribute) do not have this annotation for being referenced as well.

ISSUE n°2 : insufficient leverage of metadata references

Not to have [metadata address] in all Price components involved in Payout is also compromising full benefit of the referencing mechanism from a functional standpoint, accross the model, actually not just when considering Product model, but also (if not mainly) when considering Event model and its ability to represent Lifecycle of Products.

Indeed, referencing is an embedded kind of resolving property i.e. when compiling, CDM objects with proper referenced value populated in referencing structures above described is actually resolved, meaning that path with [metadata address] eventually results in havfing end-value corresponding to the one of the path with [metadata location].

For instance, there are a lot (if not a majority) of Lifecycle event which eventually consists in updating some before data with after data in such a way that is functionally equivalent to resolving a reference between before and after...

And that is especially obvious whenever Price is at stake. That is why ensuring metadata referencing is in place whenever feasible, is base structure for simplifying the creation or the refactoring of the Instructions involved in Event model.

In other words, whenever referencing can be used / embedded in an Instruction, this means such Instruction is roughly "out-of-the-box" because expected functional effect for updating is native in CDM when compiling the references.

EXAMPLE of current use case :

The current QuantityChange Instruction already works this way : after Change is resolved into PriceQuantity the native referencing structure that is connecting Price in Payout with PriceQuantity actually permit to finish the job i.e. to propagate the changes inside Payout paths (without the need for an additional Instruction that would directly target such paths)

EXAMPLE of additional / new kinds of use case we may contemplate :

Our point is that such behavior shall be further leveraged, and extended to **** than QuantityChange.

As a key example we have in mind, we beleive that refactoring of current Reset and Observation items involved in Event model, for instance by replacing/harmonizing with new Instruction that could be named FixingObservation which could typicallly be easilly designed, also with very generic scope able to encompass not only basic fixing but also resolvable fixing, including barrier event fixing, etc. if provided all kinds of Price (including trigger Price in Knock, etc.) would have proper annotation [metadata reference] as we are proposing here.

• see for instance FRAGMOS - FixingObservation Event #3059

Proposal

1 - to add [metadata address] to any Price type components where it is currently missing in Product model (whether of type Price or PriceSchedule because the later one actually extends Price) :

• level (an attribute of Trigger)
• varianceStrikePrice
• volatilityStrikePrice
• correlationStrikePrice
• initialRate (an attribute of FloatingRateSpecification)

2 - in addition to that, we beleive the annotation for referencing is also required in component which existing type is simply to poor for permitting such annotation to be added, that is quantityMultiplier (an attribute of QuantityMultiplier) which type is number ; proposal being to upgrade it with type PriceQuantity with [metadata address] annotation.

Compatibility

Core proposal n°1 only consists in adding [metadata address] annotation therefore is backward compatible
Not sure if proposal n°2 may not be backward compatible

Release

current PR corresponding to this Issue :
#3395

[lolabeis]

Issue was discussed at the CDM Derivatives Working Group - April 30th, 2025 - outcome inconclusive so should be followed-up.

@JBZ-Fragmos To summarise the high-level proposal:

• All price components in payout (TBD: what qualifies as being a "price"? See below) should use the address / location metadata referencing and be accessible from the trade lot.
• Further, doing this consistently for both price and quantity components (also in trade lot) would abstract away all the "variable" parameters of a trade outside of the core payout definition. This enables an event to update them without touching the payout.

My view:

• The proposal has the appeal of consistency. The question: is X or Y a "price" is ill-defined because highly context-dependent: e.g. what does a regulator call "price"? However the CDM response can be systematic: if it is represented by a Price object, meaning it's an "exchange of value" with a number (or schedule) and 2 units, then it's a price. The haircut example brought by @tomhealey-icma illustrates how this approach can be generalised to most number parameters of a trade: a haircut represents an exchange of value between loan amount and collateral.
• However, we need to consider the implication that it would broaden the meaning of the price and quantity change primitives. If they become catch-all (e.g. to change a strike, I use a price change primitive, but really it's an amendment), we may need to consider splitting them differently to make the event qualification logic effective.
• In a trade lot, you will have price and quantity components that can be treated "linearly" for the purpose of position building, but others (like strike) that won't. We will need some way of separating them.

[mgratacos]

As discussed during the meeting, I don't think the initialRate (an attribute of FloatingRateSpecification) should be included in the scope of the proposal.

[JBZ-Fragmos]

agreed @mgratacos