@JBZ-Fragmos Before I comment further on the Pull Request, can you please clarify on the design:

It looks like you're building multiple cardinality redundancy:

• On the one hand your portfolioPriceReturnTerms attribute is set as (0..*)
• On the other you're allowing a single underlier to handle multiple basketConstituent

If the latter is the chosen representation, I would have expected portfolioPriceReturnTerms to be (0..1).

@lolabeis
that is quite documented in related GitHub Issue
and also during works in cessions, this is on purpose,

but just to recap for you, i confirm modelling is as expected for the business requirement i.e. this is exactly what we need, hence need to create new types, etc.
effectively, we want in same product to have BOTH :

• multiple single return per each single underlier
• AND one Basket at "net" level, which multiple components are these single underliers

Consequently, "initialValuationPrice" or "notionalQuantity" attributes inside each may be referencing ("address") the same source ("location") in PriceQuantity. I mean, for clarity, that such "redundancy" of data is designed on purpose

Lionel has been involved as you had requested, so you may want to liaise directly with him also to help answering your questions

Ok, I think I get the redundancy design. So overall basket underlier in PerformancePayout, and individual underliers in a multiplicity of portfolioPriceReturnTerms objects, both pointing to the same data in the external PriceQuantity object.

Couple of follow-up comments:

• It looks like you're aligning PortfolioPriceReturnTerms onto ReturnTerms (+/- some attributes), which is good. Consider renaming the former as PortfolioReturnTerms, since it contains both price and dividend return terms.
• By the same argument, consider repositioning portfolioReturnTerms alongside returnTerms in PerformancePayout (still with multiple cardinality) rather than in it - possibly with a choice condition between returnTerms and portfolioReturnTerms?
• Why position financingTerms inside PortfolioPriceReturnTerms instead of simply using interestRatePayout in Payout? As I understand it, you will need to create multiple portfolioPriceReturnTerms attributes, each with its own financingTerms. So in terms of overall Payout object size it would be the same if you were creating multiple interestRatePayout attributes. If you did that, you would still be able to link the quantity of each interestRatePayout to the quantity of the corresponding PortfolioPriceReturnTerms object, in the same way as is currently done for single-name equity swaps
• You are proposing some further refactoring, which has merit. However you will be constrained by having to keep CDM Prod (which is what is used in DRR) backward-compatible, so removing or renaming attributes is a no-go. You may use the [deprecated] annotation to keep those attributes in place while introducing new ones, but I would advise against doing any non-critical refactoring and for saving those for CDM Dev. It also means that your Prod vs Dev Pull Requests will be shaped differently, rather than a simple copy/paste.

Here is the deck that was presented at the DPBE on 27 February:
Price Return Swap v3 DPBE.pptx

@lolabeis
please find below answers to each of your comment/question :

• 1 - "portfolioPriceReturnTerms" is consistent name with current implementation where this item has restricted scope to "priceReturnTerms"

  • the good alignment of the payout names is quite obvious visually
    
  • however, your proposal to rename it "portfolioReturnTerms" instead of "portfolioPriceReturnTerms" would fully make sense if being a "generic portfolio" i.e. "priceReturn" or "varianceReturn" or "volatilityReturn" or "correlReturn" or "divReturn"
    • as an indication, this would look as below (in such model, "portfolioReturnTerms" would "extends returnTerms")
      
    • I would fully support such further generic design, which would notably simplify the current representation of "dispersion strategy" (that is "heavy" today because we have to repeat redundant info in multiple high level node at performancePayout[*] level)
    • but are we sure we want to move that way now ? that meaning coming back with new proposal to the Review Committee and also to DGPE ? for me this is only a question of "timing constraints" in regards of "Acc DRR Project" targets... @dshoneisda any thoughts ?

• 2 - in accordance with above discussion about point n°1, your proposal to rename it "portfolioReturnTerms" would be relevant if we would decide to go for "generic" design

• 3 - i'm not convinced the fact we might "link the quantity of each interestRatePayout to the quantity of the corresponding PortfolioPriceReturnTerms object" is sufficiently representing the fact we creat "pairs" of payout terms I mean from an ilplementor perspective, is simple link at priceQuantity->quantity level sufficient to explicitly "link" objects at Payout level ? looks like implicit not to say indirect usage of refefencing which original meaning for me is to say that ne quantity is resolved via another one, but not to associate/link any related object together as a whole e.g. given two distinct Payout, each with A, B, C, D attributes, i do not believe these two are "linked" because one particular attributes (say "A" is "quantity") would be referecning the other one

• 4 - on this last point i'm sorry but i'm quite "lost in translation" / would need have a chat with you about it I guess...

  • not sure to understand the concept of "backward compatible"
  • moreover do not understand how to know whether some change are or not "backward compatible" if when drafting objects in WS there is no "red" points and all is "green" even when such issues may exist

I am hoping we can move this forward in Monday's meeting. To the question above we should where possible try to do enough to support DRR requirements of JPM/Pictet, and note further development/design improvement for a later date if necessary

TAKING INTO ACCOUNT ALL ABOVE DISCUSSION AND FEEDBACK

HEREUNDER refactored proposal

My initial comment is that BasketConstituent is misplaced. As defined it includes economic characteristics that belong at the economicTerms level for attributes or provisions that effect the overall basket and at the payout level for those items that effect payout characteristics.

The description of the problem appears to describe a portfolio (not considered a tradable product) so if these terms are not specific the definition of a product then they belong in the portfolio. Baskets are considered tradable products.

I'll continue to review but please clarify the mixed use portfolio and basket terms.

@tomhealey-icma

the fact BasketConstituent is of type Product (which effectively mean that it may include economicTerms etc. as you say above) is already in the model today

if you would like to discuss it, that should be part of another Issue, mostly as part of other good discussions we've had about "Asset", etc.

for now, we shall only focus on changes related to "portfolioReturnSwap" and having or not Product as a BasketConsituent is not a change related to "portfolioReturnSwap" per se

indeed Basket refactoring proposed as part of "portfolioReturnSwap" proposal, only "extends (existing) Product" with other attributes required to better represent net aggregation Price and Quantity at Basket level,

but again, that is not touching current model where Product is BasketConsitutent - see below the core structure si the same

@tomhealey-icma
As defined, the basket constituents only include quantities and prices as economic characteristics, but no other payout characteristics (those are in the return terms). Adding those quantity and price attributes is aligned with how we would define an "observable", and a basket defined as such may exist independently of any tradable product. However, this would require some significant refactoring (as proposed in our latest Steering WG) and cannot be built into a prod version.

So instead, what @JBZ-Fragmos has effectively implemented is a tactical version of that observable concept applied to the "basket" case, in a way that maintains backward-compatibility.

As an indication, have just pushed an update with 2 changes :

condition is slitghly modified as below :

payerReceiver is added to PortfolioReturnTerms (because depending on strategy and business case, the payerReceiver of the whole structure, that is defined at PerformancePayout level, may not necessarily be the same as inside individual legs, moreover for some strategy, it will necessarily vary inside the individual legs)