common-domain-model icon indicating copy to clipboard operation
common-domain-model copied to clipboard

CDM Contribution Review Working Group - July 23rd, 2024

Open eteridvalishvili opened this issue 1 year ago • 6 comments

CDM Contribution Review Working Group Minutes

Meeting Host: David Shone, ISDA

Date

July 23rd, 2024 - 10 am EST / 3 pm BST

Untracked attendees

  • Fullname, Affiliation, (optional) GitHub username

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/3020
  • [x] FINOS tech sprint announcement @eteridvalishvili
    • CDM Use Case: https://github.com/finos/traderX/discussions/184
    • Sign up form: https://www.finos.org/open-source-in-finance-tech-sprint-2024?hs_preview=uqQWlasX-172001817999
  • [x] ART update- Phase 3 contribution and communication re: release schedule @Oblongs ARTForce P3 CRWG 23Jul24.pptx
  • [x] FRAGMOS - ObservationTerms & ValuationTerms https://github.com/finos/common-domain-model/issues/3058 @JBZ-Fragmos
  • [ ] [FRAGMOS - Add FixedPrice In ForwardPayout · Issue #3057 ·https://github.com/finos/common-domain-model/issues/3057 @JBZ-Fragmos
  • [ ] AOB, Q&A & Adjourn (5mins)

Minutes

@eteridvalishvili ran through meeting admin and notices. Previous minutes were missing.

  • @chrisisla to write minutes for previous CRWG and these will be reviewed at next CRWG

Kris Moll informed group of the tech sprint focused on integrating CDM and TraderX- links for community to get involved:

  • CDM Use Case: https://github.com/finos/traderX/discussions/184
  • Sign up form: https://www.finos.org/open-source-in-finance-tech-sprint-2024?hs_preview=uqQWlasX-172001817999

@Oblongs ran through Phase 3 presentation

  • PriceQuantity slide 9 still needs to be agreed within the taskforce in particular potential for restrciting cardinality proposed by @lolabeis butt disputed by @JBZ-Fragmos
  • FX payout has two possible representations @lolabeis asked taskforce to provide the rationale to keep both to avoid ambiguity identified by @mgratacos
  • Scope for release was outlined including documentation, mappings, samples and index simplification
  • Timeline
    • release phase 2 has been delayed due to mapping work; this is due to be finished today- 23d July
    • phase 3 PR will be completed within 10 days, then go through review cycle
    • objective is for phase 3 to be released by end of August, depending on that review cycle duration
    • Phase 3 PR: #3055

@JBZ-Fragmos gave an overview of the concept outlined in issue #3058

  • question on why they are both observation and valuation terms- confirmed they are different
  • proposal is to generalise obs and val terms within the payouts
  • @mgratacos would prefer there to be a matrix where certain products that need this level of distinction are considered- to avoid misuse or multiple methods of representing the same product- i.e. specific business use cases should exist. @lolabeis supported the application to specific scenarios to avoid problems down the line.
  • @mgratacos asked for some examples to back up the use case or guidance to users
  • @lolabeis suggested that while not a bad idea and actually this is a more strategic approach, there needs to be a unique way of representing observations across payouts to avoid new users to pick one way or another, thus there would be new refactoring, a much larger undertaking

Meeting closed without discussing further items due to lack of time

Action Items

Zoom info

Join Zoom Meeting

https://zoom.us/j/96436091087?pwd=TUZMYm1KdGt2YWtxdDVHY3BpQzh0QT09 Meeting ID: 964 3609 1087 Passcode: 238896

Find your local number: https://zoom.us/u/a3KWGNquN

eteridvalishvili avatar Jul 04 '24 03:07 eteridvalishvili

Lionel Smith-Gordon for REGnosys

LionelSG-REGnosys avatar Jul 23 '24 14:07 LionelSG-REGnosys

Leo Labeis / REGnosys

lolabeis avatar Jul 23 '24 14:07 lolabeis

D Shone/ISDA

dshoneisda avatar Jul 23 '24 14:07 dshoneisda

Tom Healey/ICMA

tomhealey-icma avatar Jul 23 '24 14:07 tomhealey-icma

Chris Rayner / ISLA

chrisisla avatar Jul 23 '24 14:07 chrisisla

hello @eteridvalishvili and @dshoneisda

about the discussion : issue https://github.com/finos/common-domain-model/issues/3058

beleive the minutes only record remarks from participants raising potential issues, and have omitted to record in balance the answers given by Fragmos, which have at least merit to try highlighting positive content of the proposal

do not intend/prentend to re-write all the discussion in details now, but anyway kindly record feedbacks below :

  • about potential issue that proposal could compromise "unique way of representing observations across payouts" :

    • what object exactly ? if limited to particular case then most probably a simple condition is sufficient to solve it, etc. @lolabeis would be happy to check in details with you about it, so please let me know what case you have in mind ?
    • proposal permits to strengthen steadyness of the model because it makes it more generic/composable, and i beleive such benefit has net positive value compare to potential cases not fully clarified for now
    • strongly beleive that beyond such theoretical discussion, the answer is given by the practice in context I mean if for particular product it makes sense to further specify observationTerms whereas not for another one, the business user has the answer (Trader, SME, business implementor)... so the issue is not that the feature would exist as optional, with potential overlap in some corner case but the opposite : that the user cannot find the feature in the model for some particular product so will need to require for an update, this changes impacting the model, maybe just for one product...
  • about "examples to back up the use case" :

    • believe this is not the good direction to require termsheets to assess whether a change proposal makes sense, because it is not feasible in practice to produce "N" termsheets, neither feasible to determine the value of "N" (is that 1, 2 or 3 ?) nor to agree on relevant scope of criteria for that (e.g. range of products ? of assets ? of features ? etc.)
    • that being said, we could agree that at least 1 example is sufficient to agree that a feature is required, so i can give 1 for each feature : observationTerms and valuationTerms, at least for ForwardPayout :
      • FX Target Foward recently raised by SME asking CDM modelling for it explicitly requires ValuationTerms
      • and Equity Accumulator also part of same bulk of products being worked out recently for DRR needs clearly requires ObservationTerms that will be used for specifying the cumulation observation periods, as required for a clean standard modelling per se, but also required by ESMA

@mgratacos : you are part of the DRR WG on Acc/Decu so you can access to the termsheets for each product above mentioned so that you can confirm what i say, that all in all that permits to be conclusive that at least ForwardPayout needs both observationTerms and valuationTerms

i can push a PR just for ForwardPayout at this stage then, but as proposed, beleive that having such terms in PayoutBase would avoid such "1 by 1 approach" that is at cost in terms of model updates / versioning management, etc.

For sure I will be happy to continue it again at some point, during other meetings, else i'm also happy to have separate call/discussion with anyone interested in continuing this discussion, please do not hesitate to get in touch @lolabeis or @mgratacos

thanks a lot

JBZ-Fragmos avatar Jul 25 '24 10:07 JBZ-Fragmos