Client sends NewOrderSingle(D) to us which results in trade matching in our side.
We then reply an unconfirmed/preliminary ExecutionReport(8) with ExecType = Trade(F) to client to indicate this Trade ER is an unconfirmed/preliminary trade.
(Possible other activities on this order/trade)
Later, we will send a confirmed ExecutionReport(8) with ExecType = Trade(F) to client to confirm that trade.
My question is that if there is any tag can differentiate between the unconfirmed ExecutionReport(8) and the confirmed ExecutionReport(8)? Can I use:
TradeContinuation(1937) = TakeUp(19) -> for indicating this is an unconfirmed ExecutionReport(8);
TradeContinuation(1937) = Allocation/Trade posting(22) -> indicating this is a confirmed ExecutionReport(8);
In addition, I also have similar case for TradeCaptionReport(AE), Consider:
We send unconfirmed/preliminary AE to client to indicate this AE is an unconfirmed/preliminary trade.
Later, we will send a confirmed AE to client to confirm that trade.
My question is that if there is any tag can differentiate between the unconfirmed AE and the confirmed AE? Can I use:
TradeContinuation(1937) = TakeUp(19) -> for indicating this is an unconfirmed AE;
TradeContinuation(1937) = Allocation/Trade posting(22) -> indicating this is a confirmed AE;
@robertlau does “preliminary” mean that the execution/trade details may still change or can it also mean that the execution/trade may be cancelled after all? Is credit checking part of these “other activities” between the two ERs/TCRs?
@hanno.klein, the contents of the ERs/TCRs will not be changed. However, the “other activities” can be (See #3):
Client sends NewOrderSingle(D) (ClOrdID = X) to us which results in trade matching in our side.
We then reply an unconfirmed/preliminary ExecutionReport(8) with ExecType = Trade(F), ClOrdID = X to client to indicate this Trade ER is an unconfirmed/preliminary trade.
(a) The Trade ER may be cancelled/busted - for this, we plan to send a unconfirmed/preliminary ER with ExecType = TraceCancel(H). Later, we will also send a confirmed Trade Cancel ER (at #5).
(b) (Assume it is a partially filled trade order) The order may be amended by client using ClOrdID = Y - for this, we will send Replaced ER to client immediately. Later, at #4 below, the confirmed ER still carries the same content as before, including ClOrdID = X.
( c) The order may be cancelled by client or by us, we will send Cancelled ER to client immediately. Understood the order is terminated but we will still carry out #4 later. That is, from client point of view, even though the order is cancelled, the client still receives the confirmed ER at #4.
Later, we will send a confirmed ExecutionReport(8) with ExecType = Trade(F), ClOrdID = X to client to confirm that trade.
If 3(a) is happened, we will send confirmed Trade Cancel ER to indicate to confirm that Trade Cancel ER.
@robertlau in looking thru what you detailed as possible actions (your step 3) after what appears to be an order that matched with a resting order in an order book, a few comments from me.
your step 2, if the order in step 1 matched a resting order, that is a ExecType=F and OrdStatus=1 (partial) or 2 (filled). This is a state that is very well established in FIX for 20+ yrs in this scenario.
your step 3(a) again, like my comment above, when you send ExecType=H and OrdStatus=4 (cancelled) it’s “done” and again this is a well established state in FIX
a partially filled order can be amended, yes and the amended order may still be resting in the book. The replaced ER you’re talking about in 3(b) acknowledges that amend has been accepted when you send ExecType=5 (replaced) that original order is no longer live (as identified in OrigClOrdID) but the amended one is what is in the order book. Again this is a well established state in FIX. It is not “preliminary/unconfirmed”
If you’re sending an unsolicited cancel to the client that is also an end state, it is not “preliminary”.
your step 4, ExecType=F should ONLY be used when reporting a partial fill or fill order status and it “confirms” that the fills are done. Nothing more.
there is no need for your step 5.
It seems that either there is a misunderstanding of the FIX state model or complexity is being created for no good reason. I would recommend taking a read of this page that talks about state precedence, the various order state examples and there is a state diagram as well. The FIX order state model is very well established.
All that said, if you are intent on introducing this concept of “preliminary” my question is “what is the business rational and why is it needed?”
Having been implementing FIX since FIX 2.7 in the 1990s, I don’t see a good reason for what you described above. The complex scenarios that I have seen involved 2-stage negotiation in fixed income where an ER is needed for each stage, but stage 1’s ER is not “preliminary” in the way you described “preliminary”.
I shall confess my scenarios are quite complex. However, due to some business requirements, it has to send the “preliminary” Trade ER or TradeCancel ER, and then the possible other activities and then the “confirmed” Trade ER or TradeCancel ER. Is there any way to achieve this? My other thought is that, for the “confirmed” Trade ER or TradeCancel ER, can we use TCR to convey them?
@ltaikit, the “preliminary” trade is to inform the client there is a trade matched but this cannot be confirmed at the moment. Later(just after a short while) we will send a “confirmed” trade for it. Initial idea is to allow client to operate the partially filled order (i.e. amend/cancel it) during the period between the “preliminary” trade and “confirmed” trade. For example, when client has received the “preliminary” trade - even though it is a “preliminary” one - it still allows the client to make further decision based on this “preliminary” trade. (@ltaikit, as mentioned by you, during the period of waiting for the “confirmed” trade, the order (a) can be changed to “done”/“cancelled” due to OrderCancelRequest from client; or (b) can be changed to an amended order due to OrderCancelReplaceRequest from client. In any case, the client has to “remember” the “original” order and wait for the “confirmed” trade for it).
@ltaikit, keen to know your idea, much appreciated.
(To be honest, there may or may not be the “confirmed” trade sent out to client - I don’t want to further complicate the case and I would therefore like to focus on the case that it always has the “confirmed” trade sent out to client at later stage).
I read your reply to “preliminary” and got to this
and this concerns me. If you’re going to have this “preliminary” thing and you don’t send a “confirmed” trade how would the client know their trade is good or not?
That aside, it sounds to me what you’re calling “preliminary” really isn’t “preliminary” but trades that may still be acted on up to a certain point in time e.g. end of trading day or some time after that where operationally it is not possible to make any more changes to a filled/partially filled order. So at the end of the day if you want to communicate a trade is now “confirmed” from the exchange (I’m assuming you’re with an exchange given the line of questions from your 3 forum posts), you have two possible options: 1) an ER with “done for day” or 2) a trade recap using the TradeCaptureReport. My preference in this case would be the TCR.
Keep in mind that the OrderCancelRequest should not be send if the order is already fully filled. The OrderCancelRequest is to cancel any unfilled quantity.
If you’re going to have this “preliminary” thing and you don’t send a “confirmed” trade how would the client know their trade is good or not?
For the above, there is a “confirmed” trade or the trade is not concluded finally - the client has to set expectation about it. I am indeed still thinking about this.
you have two possible options: 1) an ER with “done for day” or 2) a trade recap using the TradeCaptureReport. My preference in this case would be the TCR
On the other hand, based on my initial thought, there is a flow (as stated in my first post) that we will send a “preliminary” TCR to client and after a while, we then send a confirmed TCR to client to confirm that “preliminary” TCR - my another question is how we can convey this confirmed TCR to client?
@robertlau have a look at the Eurex T7 concept. This is an example that fits the description from @aaronp. Chapter 4.13.1 in their specification states the following:
Notifications about trades are only provided on the T7 architecture via Trade Capture Report (AE) messages. Information provided via Execution Reports (8, U8) is indicative only and needs to be confirmed via a Trade Capture Report (AE). For further details see chapter Preliminary Execution Report and Legally Binding Trade Notifications.
The reference is to Chapter 6.10.2 where it says:
All order and quote response information in ETI is preliminary; this includes Execution Reports (8) sent out for persistent and non-persistent orders as well as Quote Execution Reports (U8) sent out for quotes.
…
For these reasons, a participant application always needs to confirm the preliminary execution information with the corresponding legally binding Trade Notification message (Trade Capture Report (AE)).
In the case of Eurex, this is done for technical reasons. Matching and the distribution of ERs happen in memory for performance reasons and a crash may lead to a loss of very few executions. Hence the TCR to confirm because that information is only sent out once the execution has been written to disk.
Why does the user needs to obtain a preliminary ER/TCR from you? What is the downside for the user if you would only send out the confirmed ER/TCR?
@hanno.klein, it is really marvelous that you can dig out the Eurex specs. Looks like Eurex already has implemented the concept of preliminary trade + confirmed trade.
Why does the user needs to obtain a preliminary ER/TCR from you? What is the downside for the user if you would only send out the confirmed ER/TCR?
It is due to some technical requirements. Actually, we are doing a preliminary study on this topic and we know it will have a big impact to client side.
Back to my previous post - I actually have two queries:
Send preliminary ER trade(35=8) first and later confirm this ER trade - it seems this can be resolved by the preliminary Trade ER(35=8) + confirmed TCR(35=AE);
Send preliminary TCR trade(35=AE) first and later confirm this TCR trade? How to do so? Do you have any idea on this?
A word from a greyhair: That a peculiarity of german markets. The 35=AE ist calles “Schlussnote” or “Contract Note” which is the final legal confirmation. The essential part in the EUREX dox is the words “legally binding” and this reflects the above mentioned Schlussnote and was thus transferred into FIX logic where the ER TRADE was transferred to the preliminary exec report which exsist from the times when german exchanges used SWIFT 7775 and Deutsche Börse invented the VALUES API concept. So this is a relict of old times and folloes the juridical conepts (also used by Clearstream).
Also for my interests/and my current study, do you know how the German OMS/investor handle this preliminary trade ER(35=8)? One particular case might be:
Assume an investor submits a NewOrderSingle via an OMS and this new order results in partially filled ER in the German market.
I believe the OMS will receive the above preliminary partially filled ER. Will the OMS relay this preliminary partially filled ER to the investor? and can the investor cancel the partially filled order before receiving the confirmed TCR?
Relating to your question and pls consider this is for exchanges only and not covering a broker connection:
The ER refers to the status of the order in the exchange and the contract note contains (SWIFT: MT512) all nevessary and more detailed information about the trade settlement information including fees, commissions, counterparties , give up etc. Therfore the attribute „preliminary“ trade on the ER TRADE is a bit misleading since the
ER TRADE reflects a trade as the reason of changing the order status and
the contract notes is the legally binding message for both counterparties for purpose of settlement.
So it is not possible to revert the trade by sending a cxl order before receiving the conract note (35=AE)
It will even be hard to get in between both messages since they are dissiminated nearly at the exact same time. And it won’t offer a chance to change the order since the ER TRADE already changed the order attributes. And this is what is importaant for the order state change flow including order changes modify or cancel…
On your step 2.): Yes the OMS will forward the ER Trade to the investor and it will forward the contract note information (35=AE) to the the custodian. In many cases the DMA (you?) also offers custodian service connection as a full service for a partner client. This ist he most convenient way but not a must.
BTW: Exchanges recommend to establish two (FIX) session for seperating risk reasons: One for trading order flow and one for the backoffice trade flow including the contract notes 35=AE as well as an (besides ist reception in the trading session) additionally subscribable (for a second receipt) of any oft he ER messages.
You ll find that implemented in all Deutsche Börse access technologies (FIX, ETI) for all asset classes matching engines as well as in (nowadays FIX) TradeGate, Xontro or you name it minor/retail market access techniques reflecting a history of more than 40 years of electronically (SWIFT) supported trading and settlement in this country and also some time before FIX. But this is only for the historically interested few out there.
Good to see you all working hard here fro mmy retiremnets rocking chair in the early morning sun . Happy days from Uli
@robertlau orders and executions are separate entities. An order is simply the “vehicle” to get executions. Cancelling an order has no effect on existing executions and merely prevents further executions of the order. There is no connection to receiving confirmations of executions via TCRs.
@robertlau - FWIW, NYSE’s FIX interface Pillar does not have a “preliminary” concept. Once fills are sent via the ER msg they are “done” and considered “confirmed” unless the parties involved agrees to “bust” the trade fill. Busting a filled trade is a distinctly different concept than an order cancellation.
So I would still ask the question of "what’s the rational for this ‘preliminary’ "? In Eurex’s case there is a legal reason but as @111s pointed out it is a bit misleading.
Lastly, besides the document @111s referenced, please review the link I provided earlier on to understand the concepts within FIX Protocol. Try to avoid making things more complicated than necessary.
Thanks @ltaikit for your further reminders. The question of this ‘preliminary’ trade I asked is just a preliminary study and for my knowledge and there is no any concrete direction on this.
. Happy days from Uli