Here's a simplified discussion of the remaining issue I raised in my June 11 email to the TC List.
The FIX TRWG next meeting is June 25.
The issue is around the Market Transaction Id that is part of the EiCreateTransactionPayload. Generally the party doing the matching (usually "the market") sends the EiCreateTransaction.
The case I've raised is a non-market party accepts a quote. EiAcceptQuotePayload is a subclass and includes an EiCreateTransactionPayload.
The issue is "how is a unique MarketTransactionId generated for the EiAcceptQuotePayload?
Here is Figure 9-10, the UML class diagram for EiAcceptQuotePayload and EiAcceptedQuotePayload; interaction pattern is in the spec as Figure 9-4 (pasted below)
The note in the sequence diagram describes the Quote-Driven Market choreography, as EiRequestQuote is not part of those interactions (see lines 1103ff in the spec - dominant players. (Note that cluttering the choreography with EiRejectQuote doesn't seem to add value)
So with the scene set, the market normally creates an ID for both sides of the transaction, and it can't be optional. Party A that wants to accept a quote can assign an ID (in some parts of FIX it's a message ID - see subscriptions).
But there needs to be an ID in the Accept Quote payload. Can Party A create a valid Market Transaction ID? Is this implementation dependent?
Earlier versions had an optional Market Transaction ID in the EiAcceptQuote, and the recipient (the market) could fill in a valid Market Transaction ID.
I hope the issue is clear - I see several workable approaches;
(1) use a null ID, and the AcceptedQuotePayload has the "real" market-assigned Market Transaction ID
(2) Make the ID in AcceptQuote optional and continue as in (1)
(3) Out of scope - create a server to generate MarketTransactionIds and perhaps a second one to asynchronously notify the participants in the transaction
(4) make the EiAccept and AcceptedQuote NOT inherit from EiCreate/CreatedTransaction
Please consider the possibilities so we can discuss at the Workshop meeting on June 19.
Thanks!
bill
Original Message:
Sent: 6/11/2025 11:45:00 AM
From: William Cox
Subject: RE: Notes on remaining issues in CTS WD33
David and all -
A workshop meeting Thursday would be good; thanks for the notes.
I'm hoping we have our liaison meeting with the FIX TRWG today; in andy event a discussion on these remaining issues would be good whether tomorrow (June 12) or next Thursday (June 19).
Other TC members' thoughts?
Thanks!
bill
On 6/10/25 3:28 PM, Holmberg, David G. (Fed) wrote:
DM6PR09MB50483910CCCBFABA0E653C3BEE6AA@DM6PR09MB5048.namprd09.prod.outlook.com"> Bill,
See a few edits and comments in the attached.
Also in line responses below.
Do you want to have a regular EITC meeting Thursday 11:00? Or workshop?
Thanks,
David
Original Message:
Sent: 6/10/2025 11:39:00 AM
From: William Cox
Subject: Notes on remaining issues in CTS WD33
Here are the remaining issues I see with WD33; most can be addressed in various ways that need to be clear in the specification. In come cases multiplicity needs to change.
- EiCreateTransactionPayload has attribute marketTransactionId. Currently mandatory in model and spec.
- This is generally provided by the market, but in case of EiAcceptQuote the actor lifting the quote may not be able to create a MarketTransactionId.
- So the multiplicity should be 0..1 for that case. In WD33 and the model it's mandatory.
- I see two possibilities--make it optional but mandatory for market or counterparty generated EiCreateTranactionPayload
- Keep it mandatory (and perhaps use the refId for the CreateTransaction message?) which requires text adjustments
- In case a NULL ID (since all IDs are UID strings, this could be the NULL string) is passed in the EiAcceptQuote a correct marketTransactionId COULD be returned in the EiAcceptedQuote payload which comes from the market.
- Most optional strings are now mandatory--pass a NULL string if no value intended. Makes coding simpler.
- A Party lifting a quote needs to direct the message (out of scope) to the <Market, Segment> that generated the Quote.
- Those IDs are in the embedded EITransactionType.tender.TenderBase.marketId and ...segmentId
- Should the text suggest exactly that (out of scope)?
- In Position Facet EiRequestPositionPaylaod MarketID is [0..1] - text says if not present the result gathers positions from all Segments of which the position manager is aware
- If there's a market ID the position is across all Segments in that Market - also matches the EML-CTS implementation
- RequestPrivate and RequestPublication were not in EiCreateTender and EiCreateTransaction; now inserted
- There's an implication in FIX that Transactions are publicly visible but RequestPublication suggests a request to put on a TrarnsactionTicker
- Is there justification for RequestPublication?
- Is there justification for RequestPrivate for Transaction? Makes sense for Tenders in the sense that it's an offer only to the listed counterparty.
- Recall the convention that the ActorId for the market/segment is the listed counterparty in a market tender, quote, etc so not sure what RequestPrivate should mean
- Private Quote Boolean -- comments welcome.
- Private Quote (1171)
- Quote is available specified counterparty only. Quote is not available to the Segment.
- Only the stated counterparty may lift this quote. Implies Publication Request = False. Table 9-4.
- Multiplicity in Create payloads
- CreateTender and CreateQuote contain 1..n artifacts (tender/quote respectively)
- CreateTransaction and CreateRfq contain exactly one artifact.
- Unchanged from much earlier--any reason to change?
- Tickers--the ticker payload has an optional subscriptionId which needs to be optional for multicast tickers. Is this clear?
Thanks!