FRAGMOS - Transfer

[JBZ-Fragmos]

Related PR

#3234

Problem Statement 1

We want to enrich the representation of transfer i.e.

• represent not only the quantity being transferred that is what already exists in current model (Quantity 1),
• but also, optionnaly, additional information :
  • the notional quantity at stake with it (Quantity 2)
  • as well as price related to the transfer (Price)

BUSINESS CASE : example : say transferred quantity is 100 Share (Quantity 1), and you want to have additional info such as the price, say 2 USD/Share (Price), with nominal quantity for it, thus being equal to 200 USD (Quantity 2)

GAP ANALYSIS :

• as of today, only 1 quantity exists : current model ony permit to have Quantity 1
• whereas business example above requires Quantity 2 + Price attribute

ADDITIONAL BUSINESS CASES : above example is the "easy" case : more kinds of quantity or price may be involved... for instance, let's keep same example, but say now there is 2nd Price involved because of FX Features at stake e.g. settlement ccy <> fixing currency, so you may need to represent not only USD/Share Price, but possibly EUR/Share Price, and may also EUR/USD Price, etc.

GAP ANALYSIS :

• as of today, only 1 quantity exists : current model ony permit to have Quantity 1
• whereas business example above requires Quantity 2 + Price attribute 1 + Price attribute 2

Problem Statement 2

there is a business need to manipulate CDM files representing a transfer as a [rootType], which seems to be conceptually already acknowleged by current model, yet with a design that prevents concrete implementation :

• for now [rootType] already exists but as an annotation for TransferState, whereas the generic roor of the transfer per se is at TransferInstruction level, where a net transfer may notably exist when the transfer encompasses multiple gross transfers represented at TransferState level
• having [rootType] annotation without having attributes for describing parties to the transfer is inconsistent ; as of today there is an attribute related to parties in tranfer path, but it is of type PayerPartyReference thus involving resolving values which reference keys come from Trade paths... though using tranfer stand-alone as [rootType] means using it with no associated Trade, meaning that, it is impossible to resolve values for defining parties for the transfer at rootType level

Proposal 1 = Additional Quantity + Price

For clarity, because "transfer extends TransferBase" that is where the changes are actually made i.e. in TransferBase :

Besides, we propose modifications on the conditions :

Proposal 2 = TransferInstruction becomes a [rootType], with Party attribute

we propose :

• to move [rootType] from TransferState to TransferInstruction because this is the right level where a net transfer may exist when the transfer encompass multiple gross transfers represented at TransferState level
  
• to add party and partyRole in TransferInstruction, that is to meet core business need above described in Problem Statement 2
  

Compatibility

backward-incompatible = 1 change = renaming prior "quantity" into "deliverableQuantity"

[lolabeis]

@JBZ-Fragmos Could you expand on the use-case please?

I'm a little uncomfortable with expanding the remit of the Transfer object and add informational-only, non-functional considerations. Also price is contextual: i.e. who decides in which currency unit that price should be expressed, or whether to use the spot price for t+1 settlement etc.? Two parties may agree on what a transfer should be (asset, quantity and date) but may not on these extra attributes, and that shouldn't impact the transfer.

Where that transfer originates from a payout such as SettlementPayout, this contextual information is defined by the payout (and is indirectly accessible to the Transfer object via a reference to that payout). The parties had to agree them when they executed the trade. But this isn't information that belongs to the transfer per se.

I believe a similar issue was raised (by you) earlier this year and later abandoned: #2507

[JBZ-Fragmos]

@lolabeis

The current attribute in Transfer which permits to reference the Payout is not sufficient for the purpose of associating a Price to a Transfer, for several reasons :

• the reference is too "high level' : once at Payout node, there may be too many paths where a Price may exist for implementors to be able to resolve which is the relevant one... for instance, say Trade is a Basket trade, then there are multiple assets therefore multiple Price values exist in the Payout
• the method how to resolve the relevant Price is not always straight "look-up" : there are more complex situations at stake e.g. "averaging", "worst of", "FX multiplier", etc. which are not clarified / not referenced at proper level of granularity for assuming that implementors may resolve the Price at Transfer level, simply with a "high level" reference simply pointing to Payout level
• even if a Price could be determined (say above issues would be solved), still there is no "place holder" attribute at Transfer level for recording the resolved value of the Price - that is not aligned with expected logic : a resolved value should be placed as an attribute of the object it is relative to ; with no such proper attribute at Tranfer level, implementors will be obliged to manufacture a association/concatenation of the Transfer with the resolved Price, which in the absence of a genuine CDM object will consist in a dirty/custom and non-interoperable component...
• in addition to resolving/displaying issues related to Price when deterministic, the Price is not always deterministic, so you need this data to be an input e.g. rebalancing/substitution/decrease/restrike events e.g. depending how being booked and negociated by Traders and execution terms in related Trade agreements, then the Price of the Transfer may be the spot market Price which is not the one in Payout but pure external info separatly agreed by the parties when the event is happening
• beyond any above considerations mostly incurred from derivative space, for sure there is no legacy system in any market place or financial institution involved in Transfer that is not associating the Price at which an Asset is being transferred together with the number of physical units (Quantity 1) AND the Nominal Value - that is to say these 3 data are a minimum set of values expected i.e. "MVP" data in any standard model as Transfer attributes
• last not least : why Price should be considered in different manner than the Asset per se ? I mean why being happy that the Asset involved in Transfer is core attribute of Transfer (thus not having to be resolved by referencing, etc.) but not the Price of at which this Asset is being transferred ? That is not consistent.

Recap :

• maturity of CDM notably Process model that is not yet at target for ensuring generic / exhaustive list of methods for resolving all Payout terms involding Price for Transfer at granular level
• missing place holder for representing related resolved value at Transfer level
• cases where Price is not deterministic
• MVP representation of Transfer in most legacy systems
• consistency of modelling (e.g. if Asset is an input at Transfer level, why not Price of the transfer beign an inptu as well ?)

Hence the proposal :

• to clarify compulsory attribute Quantity 1 being the tranferable one
• and to have optional attribute for documenting Quantity 2 and/or Price whenever needed

[JBZ-Fragmos]

@lolabeis

• have done my best to provide a lot of material / rationale why change proposal makes sense, for answering your question
• also have presented the change proposal to CRWG- December 17th, 2024 where no Reg attendee were present, unfortunately, but looks like we got consensus on business need and overall change direction
• so could we further proceed i.e. please review the related PR ?

also you will find one more change proposal in last update related to the PR, in addition to above description, that is to add optional attribute Party to Transfer : that is required if wanting to use the Transfer "alone" I mean as [root type] object, we need it for the purpose of resolving the reference involved in transfer->payerReceiver... curently that is missing and blocking implementation that may want to benefit from the fact Transfer is [root type]