common-domain-model
common-domain-model copied to clipboard
finos
CDM Asset Refactor Task Force - April 25th, 2024
CDM Asset Refactor Task Force Minutes
Meeting Host: Lionel Smith Gordon, Regnosys
Date
April 25th, 2024 - 11am ET / 4pm GMT
Untracked attendees
Meeting notices
-
FINOS Project leads are responsible for observing the FINOS guidelines for running project meetings. Project maintainers can find additional resources in the FINOS Maintainers Cheatsheet.
-
All participants in FINOS project meetings are subject to the LF Antitrust Policy, the FINOS Community Code of Conduct and all other FINOS policies.
-
FINOS meetings involve participation by industry competitors, and it is the intention of FINOS and the Linux Foundation to conduct all of its activities in accordance with applicable antitrust and competition laws. It is therefore extremely important that attendees adhere to meeting agendas, and be aware of, and not participate in, any activities that are prohibited under applicable US state, federal or foreign antitrust and competition laws. Please contact [email protected] with any questions.
-
FINOS project meetings may be recorded for use solely by the FINOS team for administration purposes. In very limited instances, and with explicit approval, recordings may be made more widely available.
Agenda
- [x] Convene & roll call (5mins)
- [x] Display FINOS Antitrust Policy summary slide
- [x] Review Meeting Notices (see above)
- [ ] Approve past meeting minutes
- [x] https://github.com/finos/common-domain-model/issues/2822
- [ ] Reach consensus on outstanding points on Asset
- [ ] Agree approach on Product
- [ ] AOB, Q&A & Adjourn (5mins)
Materials
Minutes
1. Need for a new “Asset” data type – Agreed Discussion on the rationale for creating a new Asset data type:
- a. Discussion on the meaning of the “Transfer” event, i.e. whether it represents transfer of ownership or a movement/settlement transfer. Acknowledgement that the current modelling is immature but includes parts of both definitions, covering the whole lifecycle of transfer from agreement through to the actual movement. Further refactoring of Transfer is anticipated at a later date, as required by participants.
- b. The intention of defining Assets as being ‘transferable’ is that this event lifecycle can be used on them. This differentiates Assets from negotiated products which cannot be transferred but can only be novated from one party to another.
- c. Agreement that “Be Held” is ambiguous (and could be misinterpreted to only cover physical ‘holding’); agreed better to define as the ability to “have legal title” (i.e. ‘owned’).
- d. Agreed that it helps to contrast the definition with things that cannot be owned or transferred, e.g. Index.
- e. Agreed with the need for this new data type “Asset”.
2. Attributes of “Asset” – Agreed Discussion on which attributes should be included in the Asset data type:
- a. AssetPool – yes, albeit recognising that the current modelling is not understood nor do participants know of any use.
- AssetPool seems to have been added to CDM when mapping some FpML data. However in FpML, AssetPool is an attribute of Mortgage, which is itself one of the FpML product types.
- One might conclude therefore that AssetPool is incorrectly modelled in the CDM today and should be replaced with Mortgage.
- Decision needed on one of the following:
- Add Mortgage as an Asset with AssetPool as an attribute; this will still be incomplete but can be enhanced by participants at a later date, if and when there is a need.
- AssetPool stays as is in CDM 5.
- AssetPool is removed.
- b. Basket - yes, but need a condition that allows a Basket to only be defined as a transferable Assets.It was also discussed that Basket is recursive (an Asset that is composed of Assets); do we need to address this in the model? E.G. Do all the asset types of a Basket need to be the same?
- c. Cash, Commodity, DigitalAsset – yes, no discussion.
- d. Loan – yes, no desire to change.
- e. Security – yes, and effectively the same as “issued asset”, but security is a more recognisable name.
- f. Majority agreement that exchange traded products should be in the model as their own data type; recollections of any agreement on the right name vary, including “ListedDerivative”, “ExchangeTradedDerivative” or “SecuritisedDerivative” (possibly with a Z not S?). We need to reach agreement on this detail in the next meeting.
- g. Liability – not needed, “asset” covers both ways.
- h. Agreed that this is the complete list.
- i. ACTION: Update the PR with the agreed definition.
3. Difference between Asset and Product – Pending
- Ran out of time for a full discussion; will be picked up in the next meeting.
- ACTION: Participants to review materials and reach out for discussion.
- Overview: Asset supports composition and modularisation in CDM, and allows the namespace hierarchy to be followed.
- Some participants not comfortable with the separation between TransferableProduct and Asset; to be discussed.
- Examples provided in the meeting deck.
Action Items
Zoom info
Join Zoom Meeting https://zoom.us/j/91947398280?pwd=YS85Mmo4ejhvV2VKMlpaU1FmeDYydz09
Meeting ID: 919 4739 8280 Passcode: 867245
@Oblongs
-
as regards items discussed so far :
- AGREED
-
by anticipation, as regards PriceQuantity and BuySellPayout :
-
DO NOT AGREE
-
with that regards, kindly suggest that you consider the material for discussion below
- pb statement -> frontier between Payout->[PayoutBase] vs. Payout->[other terms not in PayoutBase] is source of confusion in current model due to Price being present in Payout->[PayoutBase]
- that is root cause of hidden gaps such as having for instance fixedPayout without Underlier on one hand, and commodityPayout without fixedPrice and Payout terms empty of any formula attribute on the other hand, also root cause of overlaps e.g. alternate equivalent booking : your example of FX Spot or FX Frd via BuySellPayout can be booked as well by two fixedPayout legs... all this comes from the confusion of having a Price inside PayoutBase...
- alternate proposal by FRAGMOS :
- remove Price from Payout->[PayoutBase],
- move it to Payout->[other terms not in PayoutBase]
-
this proposal is based on generic acceptance that the core structure of any payout formula eventually consists in "comparing" something "fixed" to something "floating" (i know there are exceptions but restricted scope of exception examples precisely confirm the base rule)
accordingly :
- whatever wrapper terminology e.g. "reset/ini" Price of priceReturnSwap, "strike" Price of an Option, "forward" Price of forwardPayout, etc. eventually the "fixed" Price should be inside Payout->[other terms not in PayoutBase]
- and Payout->[PayoutBase] would only contains Quantity (no Price)
- real payout in termsheet : Payout Amount = Quantity x PayoutFormula(Price,Observable)
- current CDM : confused = PayoutBase->Quantity(Price) x PayoutFormula(??,??)
- proposal : CDM re-aligned = PayoutBase->Quantity x PayoutFormula(Price,Observable)
@Oblongs by the wayn about Transfer->TransferBase itself that was also discussed, would suggest following changes :
- introduce Price (0..1)
- and increase cardinality of Quantity up to (1..2)
the benefit is to improve representation when Transfer relates to Physical Settlement
for clarity, new items introduced here are only optional
- for the purpose of being a plus in the good direction, by having a CDM item being closer to actual Operation system inputs in which Price and Nominal Amount are mostly always required (without prentending to be exhaustive for the purpose of refactoring Transfer ; for instance, SSIs might be modelled as well here, etc.)
- also this will not restrict the Tranfer object to model only particluar kind of Transfer being Physical Settlemen, as discussed, Transfer is larger than that, and that is takedn into account here, you can still use it for straight Cash flow transfer, etc.
proposal would look as below :