CDM Derivatives Working Group - April 30th, 2025

[eteridvalishvili]

CDM Derivatives Working Group

Meeting Host: Lyteck Lynhiavu, ISDA

April 30th, 2025 - 11:30 am EST / 4:30 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 legal@finos.org 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

• Convene & roll call (5mins)
• Display FINOS Antitrust Policy summary slide
• Review Meeting Notices (see above)
• Approve Past Meeting Minutes
  • CDM Derivatives Working Group - April 9th, 2025 #3601
• CDM Derivatives WG Project Board
• Meeting schedule
  • currently, "Second and Last Wednesday at 11:30 AM EST (4:30PM GMT)." https://cdm.finos.org/docs/cdm-derivatives-wg/
  • proposal
• AOB, Q&A & Adjourn (5mins)

Minutes

• Past meeting minutes were approved. Inclusion of Underlying Asset Price Source field #3623 has been closed as not planned. This has been implemented another way in DRR.
• Project Board
  • follow up items
    • FRAGMOS - Rate Matrix mentioned in ISDA 2021 Def is missing in MatrixTypeEnum #3186 There were no comments. People haven't had the chance to review and were given two more weeks.
    • FRAGMOS - ObservationTerms & ValuationTerms #3114 JB restructured the issue. Leo suggested the complex issue should be broken down into smaller issues to facilitate the review. JB believes the content is well organized as is. It could be split into task if there is value. Lyteck agreed with JB. We can think about splitting later for the PR 3227 if needed.
  • current items
    • FRAGMOS - metadada for all Price occurrences in Payout #3669
      • There was good feedback from Ian, Leo, Marc, Dan, Tom. The discussions were quite dense. Rather than trying to summarize, we pasted large portions of the transcript, with only minor touches, some cleanup. In certain cases, the sentences may not be fully grammatically correct. Let Lyteck know if any objections.
      • Ian - strike price may not be a good example. Variance, strike, price, volatility, strike, price, correlation, strike price are not really prices in the sense that they are what the tradable product is exchanged in.
      • Dan - 1) is what you're really asking for a review of where there's an opportunity for the model to have to take advantage of keys and references? 2) is what you're asking for, that there be that the model mandate that there be keys and reference keys on certain elements of the model (technical requirement). JB looking to have an exhaustive benefit of referencing where, whenever it's feasible and already in place. So basically, the keys are already there in the abstract trade lot component and JB is effectively promoting an abstract usage of it. Then why not to have the target which can reference that key whenever we can, in that inconsistent manner, because today we have it some in some places, not in all of the places where I believe it should be. This is why JB is proposing here that take this component and annotate. The target referencing so they can effectively benefit from from the, from the keys which are already there. recap: 1) yes, there ought to be a review of where keys and references are used, and 2) looking to create a constraint that where we believe references ought to be in the model there that they have to be there.
      • Leo
        • comment so this is not your traditional key reference mechanism that is also used in other places in the Cdm. This is the address location, referencing mechanism. So the existing and the the there is existing room syntax to handle that. So this address, location reference works a little bit like a scope reference. If you want and is the one that is used for for price quantities referencing in the model.
        • I think it's almost you know, you're posing a almost an overarching question, jabling the model which is and again, to paraphrase, "should we move all instances of price and quantity wherever we find them in the product definition, should we abstract them and move them in in the trade lot?" I think you know you've explained some of the benefits. Obviously, you know position, building, and and you know the ease of changing those attributes on the trade without touching ever touching the product. It means I don't know. For reusability purposes. The same product instance could be used many times over where those variables change. So that's good for risk management systems.
          But then I think we have to balance against that. The fact that if we do that, and I think that thing that's probably that may be one of the problems that that Ian was having. If we do that, we are fundamentally changing the meaning of the quantity price quantity change primitive in other like we are making it. We are making that primitive doing potentially a lot more. For instance, you could change the strike of an option which is essentially which everybody would consider as an amendment by changing what looks like a price quantity. But you're not really changing the the price. You're really changing the stripe, which is an embedded term of of the option. So I think, if.
          like, I can see the benefits. I think we would have to. Carefully look at. You know, balance that against what the implications are in terms of the primitive and how we can. You know, and if there are any adverse benefits sorry adverse consequence then we should. We should look to mitigate that maybe we need to further speed the the primitives. I don't know, but I think we have to to carefully think about that.
      • Marc
        • It's a bit tricky. one of the questions is this idea of using trade lot goes into the fundamentals of of how we model OTCs, Marc is sympathetic with JB's in the idea of to be consistent. I'm all for that however he doesn't think we should we should treat these products as securities with the idea that by having all these prices and quantities in trade lots, we'll be able to to treat them as as security products, because at the end the way that we represent this price needs to take into account things that are part of the product definition. To Leo's point is that by putting all these prices in trade lot. we are just simply treat them as a security product because they are not securities.
        • Marc's other point is initial rate for the floating rate specification, which is listed in the proposal: Why would we consider this as a price? Because this initial rate is just forcing the initial rate for the floating. for the initial period of the floating leg.
          JB - To a generic approach of what means trade, lot, price, quantity, and which is not then only restricted to showing the price that you pay for quantity, and you get a product. Because if it's not, I agree, it's like a security. Only Then I just pushed to the end. You know a check always missing, and said, Oh, that one is a kind of a price. But maybe it's a it's an it's an exception case where it makes no sense. So okay, we're not going to reference that one particularly. I agree initial rate. And also any event on this one. Why could that be? I mean. So when discussing further leveraging the the, you know, the the replace behavior of referencing as part of the event model, I agree that for initial rate, typically. I do not really see the benefit.
          JB - You cannot reuse for national reset, because I think that that changes basically to make it short, I have the national reset, basically. And then the corporate actions, and maybe other things. But these are the big ones. But just to finish on that, don't forget to trade. Lot was not was not brought on the table by the security space. It's a typical thing where you find swap when you have shapes of swaps. So this is to be considered that I think at the very beginning, which not means it was right to be like this. It was something more abstract already, even at source. It was not just a it's not that all the price should be cash price.
      • Tom - noted the topic has come up a number of times on his side. And just to give you a couple of examples of use cases in the repo space. Say, sometimes you trade the haircut. So sometimes you price the haircut on the trade. at the moment, like the haircut is embedded inside the product. Right? It's down in the collateral, in the product. So you have to change the product in order to change the haircut. Yet the haircut was negotiated as part of the trade. So this is a problem that you can't actually easily reference by price, type or price thing, margin, haircut, or something at the trade level that you would like to, that is embedded somewhere within the product. So I see it as a very similar case, as you know, instructor product and swaps, and so on. Where you actually are trading on something other, you know, than just indicating what the the price is. There is a complication in this as it relates to actually building your application with it where you don't have the right. You know, you don't automatically have that data structure built into the trade lot because it all depends on the metadata that's generated from it. e.g. the start date, maturity, date, termination, date and maturity date or expiration date. So I create repo products that use the trade date as a reference. the date structures that are there can be pegged. based on date adjustments. Right? And so I can use a date adjustment on the start date, where I don't have to say what the start date is. I just peg it to the trade date. or I can use the termination date. So we have an overnight repo. I can peg the termination date to the start, the start date right? The effective date. So there's structure there that allows me part of the repo to say I can create a repo product on a particular piece of collateral that is then pegged to whatever I put at the trade level. So that's 1 example where it kind of works. But my other example is margin haircut embedded deep down inside the collateral. I cannot trade that at the moment, whereas a reference to it is being suggested would allow you to price that or put it on the trade lot. support potentially looking into this. But there is complications with this. If you're building an application. And you you've used annotations or metadata to indicate certain elements that are required in the trade lot. When you build the application. It's not going to tell you that those are required, and it may you'd have to find a way around it.
    • Action: all to review the proposal in terms of the elements or the attributes that JB is proposing, e.g. like some concerns about initial rate, And once we have a list we can discuss further.
    • there is an underlying question there in terms of the architecture of the CDM of the product representation. But I don't think that that's the issue. The issue is more consistency with the, with the way we have referencing. And I think we we can make a more specific proposal with a with a reviewed set of of fields that we need. We need references.
• Leo suggested Lyteck work on the order of items with relevant parties (e.g. Fragmos or others) prior to the meeting
• Meeting schedule was approved to be fortnightly (every two weeks).
  • currently the website is stating, "Second and Last Wednesday at 11:30 AM EST (4:30PM GMT)." https://cdm.finos.org/docs/cdm-derivatives-wg/ in some cases there are like 5 weeks in a month, 5 Wednesdays in a month. So that meant that there's a bigger gap between the the 1st meeting and the last meeting. The website will be updated accordingly.
• AOB - None.

Action Items

[x] meeting schedule: Eteri to update website to reflect the change to every two week meetings
[x] all to review/comments on #3186 #3114 #3669

Zoom info

Join Zoom Meeting
https://zoom.us/j/94131415778?pwd=L1A2aUhoTEhoODdUZ0lrUkNLOXBiQT09
Meeting ID: 941 3141 5778
Passcode: 189607
Find your local number: https://zoom.us/u/adEnPA6h80

[lolabeis]

@eteridvalishvili @llynhiavu
Based on the recurring fortnight cadence, this meeting should have taken place on Apr 23rd (i.e. today). Was it expected to have been moved to Apr 30th (while the next one after that seems to be May 7th)? Also according to the same recurrence, we are supposed to have the next CRWG on Apr 29th, but that occurrence isn't setup yet.

[llynhiavu]

@lolabeis

Derivatives WG

• We've been following the cadence set on https://cdm.finos.org/docs/cdm-derivatives-wg/ that says "Join us on the Second and Last Wednesday at 11:30 AM EST (4:30PM GMT)." which is the schedule inherited from the former DPBE WG
• April 2025 is one of those months that has 5 Wednesdays, making the gap between meetings bigger. but the dates were according to the book, April 9 (1st) and April 30 (last). Which I agree was not perfect.
  • April 9, 30 (is correct according to plan)
  • Next couple of months are ok
  • May 14, 28
  • June 11, 25
  • July 9, 30 (5 Wednesdays with larger gap)
  • August 13, 27

CRWG page states "Join us on the First and Third Tuesday at 10 AM EST (3 PM GMT)" https://cdm.finos.org/docs/CDM-Contribution-Review-WG

• April 1, 15 (was correct)

• we can reevalute the schedule at these WGs if needed or is it a steerco discussion (?) @eteridvalishvili

[lolabeis]

Thank @llynhiavu for your response.

We don't need to go to the steerco, it was agreed earlier this year that the meetings should be alternating fortnightly going forward. This was to ensure that they never fall on the same week, and it also makes it much easier to set-up a recurring calendar invite.

Unfortunately it seems that the reference WG pages have not been updated accordingly.

Regarding the upcoming occurrences, I propose to "reset" the calendar and have the next:

• DWG: as planned here, on 30-May
• CRWG: next week, 6-May (FINOS community calendar incorrectly states 13-May)
  And then alternating fortnightly after that.

@eteridvalishvili can you please:

• re-send the meeting invites
• update the WG pages in the CDM doc
• update the FINOS community calendar

+@dshoneisda

[eteridvalishvili]

Hi @lolabeis and @llynhiavu The calendar for May been updated accordingly. I will work to confirm the dates with the hosts and send out the finalized meetings to the mailing list.

Let me know if you have any additional questions or concerns.

[lolabeis]

Thanks @eteridvalishvili. Can you please also update the WG info in the CDM docs:
https://cdm.finos.org/docs/CDM-Contribution-Review-WG
https://cdm.finos.org/docs/CDM-Derivatives-WG
And create the "Discussion" meetings in advance for May?
Thanks

[lolabeis]

Leo Labeis / REGnosys

[manel-martos]

Manuel Martos / TradeHeader

[dschwartznyc]

Dan Schwartz / FT Advisory

[eacunaISDA]

Eleonora / ISDA

[ijuradoTH]

Imanol Jurado / TradeHeader

[paesdan]

Daniel Paes / SBI Group