Imported from previous forum
Hi all,
Regarding FIX specifications, “trade report cancel” and “trade break” are indifferently used for TradeReportType. What was the need to define two different values? In which case should we use one value instead of the other?
Regards,
Xavier.
Xavier,
I do not know exactly what the need was at the time. I see the apparent ambiguity as part of the general problem that the TCR is to be used for too many things. The following is my personal view on the difference between the two TradeReportTypes you mention below.
In case of reporting trades to a central venue there will be a time window during which this trade has not been confirmed yet to the respective counterparties. For example, you may still cancel the trade report as long as one or more counterparties have not responded and agreed to the trade. As soon as the central venue confirms the trade to the counterparties, this trade is “locked-in”. Now a different set of rules may apply as to the circumstances and workflow that still permit one of the parties to undo the trade. This is then considered a trade break and has its own TradeReportType value.
A current gap in FIX is the lack of a trade status model similar to the order status model. The two similar values of TradeReportType might then not be needed because you simply cancel a trade at different states. However, any general trade status model will be significantly more complex than the current order status model, especially if you include the OTC business. EP118 introduced a model for allocation states in the context of give-up/take-up workflows for clearing houses which gives you an idea of the complexity. Part of it is due to the fact that an order involves just a single party, i.e. the submitter, and except for retail orders, typically has a short lifetime. A trade can involve a large number of parties and a long period of time during which it may change state until it finally reaches a terminal state.
Regards,
Hanno.
Hi all,
Regarding FIX specifications, “trade report cancel” and “trade break” are indifferently used for TradeReportType. What was the need to define two different values? In which case should we use one value instead of the other?
Regards,
Xavier.
Hi Hanno,
It confirms my understanding. Once the trade has been confirmed, we can request its cancelation by sending “TradeReportTransType=new|TradeReportType=trade-break (locked-in)”. However if the trade has not been confirmed yet, we can cancel it by sending “TradeReportTransType=cancel|TradeReportType=submit”. I don’t doubt that TCR workflows may be various and there is certainly one of them which needs “TradeReportType=trade-report-cancel”.
Xavier,
I do not know exactly what the need was at the time. I see the apparent ambiguity as part of the general problem that the TCR is to be used for too many things. The following is my personal view on the difference between the two TradeReportTypes you mention below.
In case of reporting trades to a central venue there will be a time window during which this trade has not been confirmed yet to the respective counterparties. For example, you may still cancel the trade report as long as one or more counterparties have not responded and agreed to the trade. As soon as the central venue confirms the trade to the counterparties, this trade is “locked-in”. Now a different set of rules may apply as to the circumstances and workflow that still permit one of the parties to undo the trade. This is then considered a trade break and has its own TradeReportType value.
A current gap in FIX is the lack of a trade status model similar to the order status model. The two similar values of TradeReportType might then not be needed because you simply cancel a trade at different states. However, any general trade status model will be significantly more complex than the current order status model, especially if you include the OTC business. EP118 introduced a model for allocation states in the context of give-up/take-up workflows for clearing houses which gives you an idea of the complexity. Part of it is due to the fact that an order involves just a single party, i.e. the submitter, and except for retail orders, typically has a short lifetime. A trade can involve a large number of parties and a long period of time during which it may change state until it finally reaches a terminal state.
Regards,
Hanno.Hi all,
Regarding FIX specifications, “trade report cancel” and “trade break” are indifferently used for TradeReportType. What was the need to define two different values? In which case should we use one value instead of the other?
Regards,
Xavier.