Imported from previous forum
Within the TrdInstrmtLegExecGrp component block in the TMR message (35=DC) there is a LegTradeID (Tag 1894) but however there is no provision for a OrigLegTradeID field. This would be similar to how there is a SideTradeID (Tag 1506) and SideOrigTradeID (Tag 1507). Is this by design? How will we provide a pointer back to the original leg trade ID in case of a trade correction?
Yes. Same argument as for SideTradeID (see http://www.fixtradingcommunity.org/pg/discussions/topicpost/3947731/). Conceptually, there is no separate trade correction or trade leg correction. You can make a correction to a match event, expressed by using the same TrdMatchID(880) together with TradeReportType(856). In that correction you use the new ID values and make no reference to the old ones. The recipient should use only the TrdMatchID to find the associated trades and its leg executions. You need to include the TrdMatchID in your “primary key” when looking for one of its trades or leg executions.
If your design does not support the atomic nature of the TMR then it may be better to use the TCR on the level of leg execution with MultiLegReportingType(442)=2 (Individual leg of a multi-leg security). It depends on your architecture and workflows to determine the best fit.
We are planning on using the TMR for trade cancellations of entire match event (which will be atomic) and trade corrections for entire match event (atomic) as well as partial trade corrections and would not like to revert back to TCR to do this since TMR is a better message which supports consolidation and is more efficient than the TCR
We could do a custom implementation and add the “OrigID” or “RefID” fields back in to support partial corrections of specific InstrmtMtchSides or specific TrdMtchSides or specific LegExecs
Adding user-defined fields that change the intended message paradigm is not compliant in my view but that is your decision in the end. Why don’t you use the TCR to convey partial trade corrections? I assume you split new TMR messages into (leg) trades. With the TCR you can create new IDs and reference the old ones. TrdMatchID(880) would even allow you to reference the original match event sent with a TMR. I always believe it is worth spending some effort for a creative solution that stays within the standard as much as possible. User-defined fields are a double-edged sword.
We do not want to support two message formats (TMR & TCR) just for this use case and neither are we splitting new TMR messages into leg trades, they stay as MLEG=3
Why can’t we introduce the possibility to make partial adjustments to a TMR (TrdMatchID would not change only the underlying LegTradeID, SideTradeID etc)?
What is the argument against doing this? The adjusted TMR contains the incremental changes with the original TrdMatchID and the incremental changes (only price adjustments) will be applied to the original match event by doing a lookup of the original TrdMatchID
This statement seems incorrect --> Conceptually, there is no separate trade correction or trade leg correction
There is a business requirement to not adjust the whole match event but only certain parts of it and we need to be able to support it
We try to operate within the standard but if we cannot get anything then we have to use user defined fields
Adjusting parts of the match event is still an adjustment of the match event. What does it mean to you to adjust the “whole match event”? Changes are likely to always be partial. The match event is the entity of the TMR just like the single trade is the entity of the TCR. The entity changes if one or more of its attributes (including sub-entities) changes. Hence my statement saying there is no trade (leg) correction without conceptually also having a change to the match event. Whether the (sub-)entity identifier also has to change is a question of your internal data model which apparently requires this. Currently, the TMR does not have OrigTrdMatchID, SideOrigTradeID, LegOrigTradeID. The last one does not even exist for the TCR and nobody has asked to add that yet. The TMR also does not have the concpt of a secondary trade ID or of a firm trade ID. The former supports chaining (OrigSecondaryTradeID), the latter does not. The TMR was intentionally designed to not be a mere wrapper for a group of TCRs and hence does not have the same capabilities. Whether we should add capabilities to the TMR is an open question. Adding a capability to the TMR which the TCR does not have (e.g. LegOrigTradeID) requires to also add it to the TCR.
In summary that means that the current TMR does not support the same kind of workflow as the TCR. The TMR only supports persistent identifiers and no chain of identifiers like the TCR does. I can understand that you want to avoid using TMR and TCR. The standard process in FIX is to submit a Gap Analysis, asking for changes to the TMR. Only if that fails then you can say “we cannot get anything”.
Okay sure thing, having a further discussion/debate sounds good. Yes if you agree that we can initiate a gap analysis then we will look into it