JEAN BAPTISTE ZIADE removeAbusiveConditions-PerformancePayout

[regnosys-prod-user]

No description provided.

[netlify]

✅ Deploy Preview for finos-cdm ready!

Name	Link
🔨 Latest commit	58598bb
🔍 Latest deploy log	https://app.netlify.com/sites/finos-cdm/deploys/66912cc23c3da700083f403e
😎 Deploy Preview	https://deploy-preview-3040--finos-cdm.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[JBZ-Fragmos]

business need to remove these 2 conditions that should not have been implemented at the time when we (mostly Fragmos-Chain based on JPM business case) designed the PortfolioReturnTerms and attached it to PerformancePayout also with such abusive conditions.

rationale why removing - examples, business cases :

• blockers when at some point in lifecycle a Portfolio might involve only 1 underlier in position (that is to say when only 1 unique PortfolioReturnTerms leg may exist at some point in time, which is not permitted with current condition)

• prevent larger usage of PortfolioReturnTerms - for instance for representing Dispersion Strategy involving multiple individual components vs. single index component (no Basket is involved in such case, so current conditions would prevent it, though PortfolioReturnTerms was notabky designed to encompass this type of strategy)

[JBZ-Fragmos]

@dshoneisda @lolabeis @nicholas-moger

i assume such minor fix can be pushed without requiring discussion/validation with the Group, right ?

[dshoneisda]

@lolabeis @Oblongs please can you review this item on my behalf

[Oblongs]

@lolabeis @Oblongs please can you review this item on my behalf

The change itself looks relatively straightforward - removing two conditions on one data type - however this pull request seems to be corrupt as there are 1600+ files recorded as having been changed. This needs to be fixed.

[dshoneisda]

thanks
@JBZ-Fragmos can you look at the multiple file issue/re-submit if necessary

[JBZ-Fragmos]

have (re)checked and confirmed there is no other change in my contrib other than removing the two conditions, so believe cannot help in regards to the issue you mentioned, looks like something technical beyond my scope... ***@***.*** From: dshoneisda ***@***.***> Sent: Tuesday, July 16, 2024 12:02 PM To: finos/common-domain-model ***@***.***> Cc: Jean-Baptiste Ziadé ***@***.***>; Mention ***@***.***> Subject: Re: [finos/common-domain-model] JEAN BAPTISTE ZIADE removeAbusiveConditions-PerformancePayout (PR #3040) thanks @JBZ-Fragmos<https://github.com/JBZ-Fragmos> can you look at the multiple file issue/re-submit if necessary - Reply to this email directly, view it on GitHub<#3040 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AWFL2PN6H2SGI5R3UQQEE73ZMTVRPAVCNFSM6AAAAABKY5JKZGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMZQGUYDINJYHA>. You are receiving this because you were mentioned.Message ID: ***@***.******@***.***>>

[Oblongs]

looks like something technical beyond my scope

Have raised to the team to investigate

Update Has been fixed

[JBZ-Fragmos]

@Oblongs @lolabeis @dshoneisda

reading comment history about this proposal, also considering it is really minor technical one, which requires only 1 approver, kindly let me know if this could be pushed to Prod in coming days

thanks
JB

[JBZ-Fragmos]

Background :

• agreed with DPBE : CDM Derivatives Products and Business Events Working Group - November 6th, 2024 #3210
• this particular PR is part of a list of multiple other PRs, referred to in DPBE minutes as "wish list" submitted to the group

Target :

• merge any agreed components into Dev, before next major release that will incorporate such changes into Prod

Method proposal :

• some PR in the list are "small" so Fragmos would expect agreement for the whole PR
• other ones are "big" (contains a lot of proposal changes), in which case, though Fragmos would be very happy to get consensus for the whole PR, Fragmos may understand opportunity to split / create new individual PR whenever there would be consensus for "cherry picking" sub-sets of changes among the whole set being present in the original "big" PR

For clarity, this particular PR is considered "small"