Imported from previous forum
Hi,
I am using a Public Order ID concept to inform the replenished quantity of iceberg orders on the market data feed. i.e. Every time an iceberg order’s visible size trades and gets replenished, the newly added quantity to the book will be informed to the market using an add order message with the newly generated public order ID. This way, the chance of the market finding out about iceberg orders in the book is reduced.
I want the participants to know the new Public Order ID of their orders through the Execution Reports so that they can identify their orders on the market data feed. Is it acceptable if I use a separate Execution Report with ExecType=D (Restated) along with a new Public Order ID to inform users about the replenished quantity?
Eg :
- Buy Iceberg Order in the book : 3000(17000), OrderID = O1, PublicOrderID = O1
- Sell order aggresses for 3000 and trades with the visible size 3000.
- Buy Order replenishes : 3000(14000), OrderID = O1, PublicOrderID = O2
Is it ok to send the following Execution Reports?
-
OrderID = O1, PublicOrderID = O1/, ExecType = Trade, ExecQty = 3000, LeavesQty = 17000, DisplayQty = 0
-
OrderID = O1, PublicOrderID = O2, ExecType = Restated, ExecQty = 0, LeavesQty = 14000, DisplayQty = 3000, ExecRestatmentReason = 99 (Other)
There is more than one comment to make on this question. You have left out OrderQty and CumQty in your example. The fiel for the executed qty is not ExecQty but LastQty. If you add OrderQty=17000 and CumQty=3000 then the equation OrderQty=CumQty+LeavesQty no longer holds as your first ER still has LeavesQty=17000 and only the second one has the reduced amount of 14000.
I concur with Aaron that the objective should be the least number of messages and in this case the solution is fairly straightforward by using SecondaryOrderID (198) for the public ID issued by the marketplace. OrderID (37) stays the same while SecondaryOrderID changes for every replenishment. In a hit and take market, the users would then use RefOrderID (1080) with RefOrderIDSource (1081) = 0 as part of NewOrderSingle to reference the ID they saw in the public market data feed. This feature was added by OMX a few years ago for the scenario you are describing.
Regards,
Hanno.
Hi,
I am using a Public Order ID concept to inform the replenished quantity of iceberg orders on the market data feed. i.e. Every time an iceberg order’s visible size trades and gets replenished, the newly added quantity to the book will be informed to the market using an add order message with the newly generated public order ID. This way, the chance of the market finding out about iceberg orders in the book is reduced.
I want the participants to know the new Public Order ID of their orders through the Execution Reports so that they can identify their orders on the market data feed. Is it acceptable if I use a separate Execution Report with ExecType=D (Restated) along with a new Public Order ID to inform users about the replenished quantity?
Eg :
- Buy Iceberg Order in the book : 3000(17000), OrderID = O1, PublicOrderID = O1
- Sell order aggresses for 3000 and trades with the visible size 3000.
- Buy Order replenishes : 3000(14000), OrderID = O1, PublicOrderID = O2
Is it ok to send the following Execution Reports?
OrderID = O1, PublicOrderID = O1/, ExecType = Trade, ExecQty = 3000, LeavesQty = 17000, DisplayQty = 0
OrderID = O1, PublicOrderID = O2, ExecType = Restated, ExecQty = 0, LeavesQty = 14000, DisplayQty = 3000, ExecRestatmentReason = 99 (Other)
Thanks Aaron & Hanno for the quick response.
My interest too is to only send minimum number of Execution Reports (ER), informing the trade as well as the new Public Order ID for the replenished order. However, according to the matching engine implementation I am working with, I find 1 scenario where this cannot be done using just 1 ER. I’ve explained it below.
Generallt, there are 3 types of executions an iceberg order can participate in.
1.
Buy Iceberg Order in the book : 3000(17000), OrderID = O1
Aggressing Sell order for 2000 (<3000).
a. 1 ER to inform the trade. Public Order ID send as O1. No new public order ID generated as there was no replenishment. Participant knows the latest Public Order ID which is O1. This is fine.
Buy Iceberg Order in the book : 3000(17000), OrderID = O1
Aggressing Sell order for 5000 (>3000).
a. 1 ER to inform the visible size trade for 3000 sent. Public Order ID sent as O1.
b. Order Replenishes. New Public Order ID = O2 generated
c. 1 ER to inform the hidden size trade for 2000 sent. Public Order ID sent as O2.
This is fine too. Paricipant knows the latest Public Order ID which is now O2
Buy Iceberg Order in the book : 3000(17000), Order ID = O1
Aggressing sell order for 3000 (=3000).
a. 1 ER to inform the trade. At this point, as the replenishment has not happened yet, the exchange does not know about the new Public Order ID. Therefore, it will send Public Order ID as O1
b. Order Replenishes. New Public Order ID = O2 generated
In the above scenario, I dont have a way of informing the participant that the latest public order ID is O2. Hence my suggestion of sending a 2nd ER with ExecType = Restated just to inform the Public Order ID and the display quantity
My question is, according to your suggestions, at step (a), are you supposed to know what the final Publc Order ID of the order is going to be, which in the above example I have only derived in step (b)? Or is sending a 2nd ER only in the 3rd scenario as I initially inquired a better option?
Hanno makes a good point re: explicitly identifying the refreshed peaks while also explicitly identifying the original public order ID.
I guess the underlying limitations of the matching engine may drive your final choice of implementation, are you able to share these to help the recommendations?
There is more than one comment to make on this question. You have left out OrderQty and CumQty in your example. The fiel for the executed qty is not ExecQty but LastQty. If you add OrderQty=17000 and CumQty=3000 then the equation OrderQty=CumQty+LeavesQty no longer holds as your first ER still has LeavesQty=17000 and only the second one has the reduced amount of 14000.
I concur with Aaron that the objective should be the least number of messages and in this case the solution is fairly straightforward by using SecondaryOrderID (198) for the public ID issued by the marketplace. OrderID (37) stays the same while SecondaryOrderID changes for every replenishment. In a hit and take market, the users would then use RefOrderID (1080) with RefOrderIDSource (1081) = 0 as part of NewOrderSingle to reference the ID they saw in the public market data feed. This feature was added by OMX a few years ago for the scenario you are describing.
Regards,
Hanno.Hi,
I am using a Public Order ID concept to inform the replenished quantity of iceberg orders on the market data feed. i.e. Every time an iceberg order’s visible size trades and gets replenished, the newly added quantity to the book will be informed to the market using an add order message with the newly generated public order ID. This way, the chance of the market finding out about iceberg orders in the book is reduced.
I want the participants to know the new Public Order ID of their orders through the Execution Reports so that they can identify their orders on the market data feed. Is it acceptable if I use a separate Execution Report with ExecType=D (Restated) along with a new Public Order ID to inform users about the replenished quantity?
Eg :
- Buy Iceberg Order in the book : 3000(17000), OrderID = O1, PublicOrderID = O1
- Sell order aggresses for 3000 and trades with the visible size 3000.
- Buy Order replenishes : 3000(14000), OrderID = O1, PublicOrderID = O2
Is it ok to send the following Execution Reports?
OrderID = O1, PublicOrderID = O1/, ExecType = Trade, ExecQty = 3000, LeavesQty = 17000, DisplayQty = 0
OrderID = O1, PublicOrderID = O2, ExecType = Restated, ExecQty = 0, LeavesQty = 14000, DisplayQty = 3000, ExecRestatmentReason = 99 (Other)
I am working in another market implementing this same behavior. We are sending the additional restatement when there is a replenishment. I recommend you send the additional restatement in scenario #3.
Thanks Aaron & Hanno for the quick response.
My interest too is to only send minimum number of Execution Reports (ER), informing the trade as well as the new Public Order ID for the replenished order. However, according to the matching engine implementation I am working with, I find 1 scenario where this cannot be done using just 1 ER. I’ve explained it below.
Generallt, there are 3 types of executions an iceberg order can participate in.
1.
Buy Iceberg Order in the book : 3000(17000), OrderID = O1
Aggressing Sell order for 2000 (<3000).
a. 1 ER to inform the trade. Public Order ID send as O1. No new public order ID generated as there was no replenishment. Participant knows the latest Public Order ID which is O1. This is fine.
Buy Iceberg Order in the book : 3000(17000), OrderID = O1
Aggressing Sell order for 5000 (>3000).
a. 1 ER to inform the visible size trade for 3000 sent. Public Order ID sent as O1.
b. Order Replenishes. New Public Order ID = O2 generated
c. 1 ER to inform the hidden size trade for 2000 sent. Public Order ID sent as O2.
This is fine too. Paricipant knows the latest Public Order ID which is now O2
Buy Iceberg Order in the book : 3000(17000), Order ID = O1
Aggressing sell order for 3000 (=3000).
a. 1 ER to inform the trade. At this point, as the replenishment has not happened yet, the exchange does not know about the new Public Order ID. Therefore, it will send Public Order ID as O1
b. Order Replenishes. New Public Order ID = O2 generatedIn the above scenario, I dont have a way of informing the participant that the latest public order ID is O2. Hence my suggestion of sending a 2nd ER with ExecType = Restated just to inform the Public Order ID and the display quantity
My question is, according to your suggestions, at step (a), are you supposed to know what the final Publc Order ID of the order is going to be, which in the above example I have only derived in step (b)? Or is sending a 2nd ER only in the 3rd scenario as I initially inquired a better option?
Hanno makes a good point re: explicitly identifying the refreshed peaks while also explicitly identifying the original public order ID.
I guess the underlying limitations of the matching engine may drive your final choice of implementation, are you able to share these to help the recommendations?
There is more than one comment to make on this question. You have left out OrderQty and CumQty in your example. The fiel for the executed qty is not ExecQty but LastQty. If you add OrderQty=17000 and CumQty=3000 then the equation OrderQty=CumQty+LeavesQty no longer holds as your first ER still has LeavesQty=17000 and only the second one has the reduced amount of 14000.
I concur with Aaron that the objective should be the least number of messages and in this case the solution is fairly straightforward by using SecondaryOrderID (198) for the public ID issued by the marketplace. OrderID (37) stays the same while SecondaryOrderID changes for every replenishment. In a hit and take market, the users would then use RefOrderID (1080) with RefOrderIDSource (1081) = 0 as part of NewOrderSingle to reference the ID they saw in the public market data feed. This feature was added by OMX a few years ago for the scenario you are describing.
Regards,
Hanno.Hi,
I am using a Public Order ID concept to inform the replenished quantity of iceberg orders on the market data feed. i.e. Every time an iceberg order’s visible size trades and gets replenished, the newly added quantity to the book will be informed to the market using an add order message with the newly generated public order ID. This way, the chance of the market finding out about iceberg orders in the book is reduced.
I want the participants to know the new Public Order ID of their orders through the Execution Reports so that they can identify their orders on the market data feed. Is it acceptable if I use a separate Execution Report with ExecType=D (Restated) along with a new Public Order ID to inform users about the replenished quantity?
Eg :
- Buy Iceberg Order in the book : 3000(17000), OrderID = O1, PublicOrderID = O1
- Sell order aggresses for 3000 and trades with the visible size 3000.
- Buy Order replenishes : 3000(14000), OrderID = O1, PublicOrderID = O2
Is it ok to send the following Execution Reports?
OrderID = O1, PublicOrderID = O1/, ExecType = Trade, ExecQty = 3000, LeavesQty = 17000, DisplayQty = 0
OrderID = O1, PublicOrderID = O2, ExecType = Restated, ExecQty = 0, LeavesQty = 14000, DisplayQty = 3000, ExecRestatmentReason = 99 (Other)
Sending a restatement to convey a change in SecondaryOrderID is certainly an option. LastQty would be zero because no execution took place. ExecRestatementReason should be as explicit as possible (user-defined values of 100 and above are allowed).
An alternative which may or may not be possible within your matching engine is the following. An incoming reserve (iceberg) order initially qualifies with its entire amount (17000) and causes a single atomic matching event resulting in a single ER back to the participant with the overall traded qty, one or more trading prices (FillsGrp) and the latest public order ID. The market data feed sees a single new order with a full or partial DisplayQty and one or more trades. If the order is able to trade 10 times and gets replenished 10 times, it defeats the purpose of hiding the order if you publically send out 10 orders and 10 trades of equal size. Your matching engine must be able to issue a public order ID at the end of its atomic transaction whenever LeavesQty>0, i.e. something is left over. You then only show up to DisplayQty of LeavesQty (or everything if LeavesQty<=DisplayQty). The public order ID then goes into the ER back to the participant and to the market data output.
DisplayQty is intended to be able to limit the qty shown but not the qty traded. If you get a reserve order that does not trade at all when entered then you have the same scenario compared to yours below when it trades exactly at one of the boundaries of DisplayQty (3000/6000/9000/…). I would not use the private order ID (O1) as initial public order ID. You simply need issue two IDs initially (private+public), followed by one (public) in case of a replenishment.
Hope it helps,
Hanno.
Thanks Aaron & Hanno for the quick response.
My interest too is to only send minimum number of Execution Reports (ER), informing the trade as well as the new Public Order ID for the replenished order. However, according to the matching engine implementation I am working with, I find 1 scenario where this cannot be done using just 1 ER. I’ve explained it below.
Generallt, there are 3 types of executions an iceberg order can participate in.
1.
Buy Iceberg Order in the book : 3000(17000), OrderID = O1
Aggressing Sell order for 2000 (<3000).
a. 1 ER to inform the trade. Public Order ID send as O1. No new public order ID generated as there was no replenishment. Participant knows the latest Public Order ID which is O1. This is fine.
Buy Iceberg Order in the book : 3000(17000), OrderID = O1
Aggressing Sell order for 5000 (>3000).
a. 1 ER to inform the visible size trade for 3000 sent. Public Order ID sent as O1.
b. Order Replenishes. New Public Order ID = O2 generated
c. 1 ER to inform the hidden size trade for 2000 sent. Public Order ID sent as O2.
This is fine too. Paricipant knows the latest Public Order ID which is now O2
Buy Iceberg Order in the book : 3000(17000), Order ID = O1
Aggressing sell order for 3000 (=3000).
a. 1 ER to inform the trade. At this point, as the replenishment has not happened yet, the exchange does not know about the new Public Order ID. Therefore, it will send Public Order ID as O1
b. Order Replenishes. New Public Order ID = O2 generatedIn the above scenario, I dont have a way of informing the participant that the latest public order ID is O2. Hence my suggestion of sending a 2nd ER with ExecType = Restated just to inform the Public Order ID and the display quantity
My question is, according to your suggestions, at step (a), are you supposed to know what the final Publc Order ID of the order is going to be, which in the above example I have only derived in step (b)? Or is sending a 2nd ER only in the 3rd scenario as I initially inquired a better option?
Other markets are doing what Hanno suggests: Put the identifier that changes with each replenishment into SecondaryOrderID(190). We should probably document this as a recommended practice, possibly on FIXwiki.
Hanno makes a good point re: explicitly identifying the refreshed peaks while also explicitly identifying the original public order ID.
I guess the underlying limitations of the matching engine may drive your final choice of implementation, are you able to share these to help the recommendations?
There is more than one comment to make on this question. You have left out OrderQty and CumQty in your example. The fiel for the executed qty is not ExecQty but LastQty. If you add OrderQty=17000 and CumQty=3000 then the equation OrderQty=CumQty+LeavesQty no longer holds as your first ER still has LeavesQty=17000 and only the second one has the reduced amount of 14000.
I concur with Aaron that the objective should be the least number of messages and in this case the solution is fairly straightforward by using SecondaryOrderID (198) for the public ID issued by the marketplace. OrderID (37) stays the same while SecondaryOrderID changes for every replenishment. In a hit and take market, the users would then use RefOrderID (1080) with RefOrderIDSource (1081) = 0 as part of NewOrderSingle to reference the ID they saw in the public market data feed. This feature was added by OMX a few years ago for the scenario you are describing.
Regards,
Hanno.Hi,
I am using a Public Order ID concept to inform the replenished quantity of iceberg orders on the market data feed. i.e. Every time an iceberg order’s visible size trades and gets replenished, the newly added quantity to the book will be informed to the market using an add order message with the newly generated public order ID. This way, the chance of the market finding out about iceberg orders in the book is reduced.
I want the participants to know the new Public Order ID of their orders through the Execution Reports so that they can identify their orders on the market data feed. Is it acceptable if I use a separate Execution Report with ExecType=D (Restated) along with a new Public Order ID to inform users about the replenished quantity?
Eg :
- Buy Iceberg Order in the book : 3000(17000), OrderID = O1, PublicOrderID = O1
- Sell order aggresses for 3000 and trades with the visible size 3000.
- Buy Order replenishes : 3000(14000), OrderID = O1, PublicOrderID = O2
Is it ok to send the following Execution Reports?
OrderID = O1, PublicOrderID = O1/, ExecType = Trade, ExecQty = 3000, LeavesQty = 17000, DisplayQty = 0
OrderID = O1, PublicOrderID = O2, ExecType = Restated, ExecQty = 0, LeavesQty = 14000, DisplayQty = 3000, ExecRestatmentReason = 99 (Other)
[ original email was from John Harris - john.harris@bondmart.com ]
Jim, I don’t see how this approach solves the problem, which I understand to be preventing detection of reserve orders. If we “put the identifier that changes with each replenishment into SecondaryOrderID(190),” wouldn’t recipients of the public (FIX) market-data feed infer the presence of a reserve order from the use of tag 190?
Other markets are doing what Hanno suggests: Put the identifier that changes with each replenishment into SecondaryOrderID(190). We should probably document this as a recommended practice, possibly on FIXwiki.
Hanno makes a good point re: explicitly identifying the refreshed peaks while also explicitly identifying the original public order ID.
I guess the underlying limitations of the matching engine may drive your final choice of implementation, are you able to share these to help the recommendations?
There is more than one comment to make on this question. You have left out OrderQty and CumQty in your example. The fiel for the executed qty is not ExecQty but LastQty. If you add OrderQty=17000 and CumQty=3000 then the equation OrderQty=CumQty+LeavesQty no longer holds as your first ER still has LeavesQty=17000 and only the second one has the reduced amount of 14000.
I concur with Aaron that the objective should be the least number of messages and in this case the solution is fairly straightforward by using SecondaryOrderID (198) for the public ID issued by the marketplace. OrderID (37) stays the same while SecondaryOrderID changes for every replenishment. In a hit and take market, the users would then use RefOrderID (1080) with RefOrderIDSource (1081) = 0 as part of NewOrderSingle to reference the ID they saw in the public market data feed. This feature was added by OMX a few years ago for the scenario you are describing.
Regards,
Hanno.Hi,
I am using a Public Order ID concept to inform the replenished quantity of iceberg orders on the market data feed. i.e. Every time an iceberg order’s visible size trades and gets replenished, the newly added quantity to the book will be informed to the market using an add order message with the newly generated public order ID. This way, the chance of the market finding out about iceberg orders in the book is reduced.
I want the participants to know the new Public Order ID of their orders through the Execution Reports so that they can identify their orders on the market data feed. Is it acceptable if I use a separate Execution Report with ExecType=D (Restated) along with a new Public Order ID to inform users about the replenished quantity?
Eg :
- Buy Iceberg Order in the book : 3000(17000), OrderID = O1, PublicOrderID = O1
- Sell order aggresses for 3000 and trades with the visible size 3000.
- Buy Order replenishes : 3000(14000), OrderID = O1, PublicOrderID = O2
Is it ok to send the following Execution Reports?
OrderID = O1, PublicOrderID = O1/, ExecType = Trade, ExecQty = 3000, LeavesQty = 17000, DisplayQty = 0
OrderID = O1, PublicOrderID = O2, ExecType = Restated, ExecQty = 0, LeavesQty = 14000, DisplayQty = 3000, ExecRestatmentReason = 99 (Other)
John, the assumption not stated in this discussion is that all orders regardless of type would be given a SecondaryOrderID(190). Of course, orders that are not replenished would maintain the same SecondaryOrderID(190) throughout the life of the order.
So this will provide a certain amount of protection for reserved (iceberg) orders, though sophisticated market participants could still likely predict and discover these orders within a couple of immediate orders. I am amazed at the amount of knowledge about market structure that exists in the more sophisticated market participants. There really is a multiple level playing field out there. Of course to a certain extent this has always been the case.
People for years complained about locals, market makers, specialists, large players with access to the floor in open-outcry. Now we have HFT and sophisticated algo trading participants that have replaced the locals. It seems as though all markets (not just financial markets) have an endemic amount of information asymmetry, at the point where this asymmetry becomes averse to the benefits of participants, new markets form.
Exchanges were the place where people met geographically to perform trade. Now exchanges are the places where computer systems (semi-autonomous agents) meet geographically (colocation) to perform trade.
Jim, I don’t see how this approach solves the problem, which I understand to be preventing detection of reserve orders. If we “put the identifier that changes with each replenishment into SecondaryOrderID(190),” wouldn’t recipients of the public (FIX) market-data feed infer the presence of a reserve order from the use of tag 190?
Other markets are doing what Hanno suggests: Put the identifier that changes with each replenishment into SecondaryOrderID(190). We should probably document this as a recommended practice, possibly on FIXwiki.
Hanno makes a good point re: explicitly identifying the refreshed peaks while also explicitly identifying the original public order ID.
I guess the underlying limitations of the matching engine may drive your final choice of implementation, are you able to share these to help the recommendations?
There is more than one comment to make on this question. You have left out OrderQty and CumQty in your example. The fiel for the executed qty is not ExecQty but LastQty. If you add OrderQty=17000 and CumQty=3000 then the equation OrderQty=CumQty+LeavesQty no longer holds as your first ER still has LeavesQty=17000 and only the second one has the reduced amount of 14000.
I concur with Aaron that the objective should be the least number of messages and in this case the solution is fairly straightforward by using SecondaryOrderID (198) for the public ID issued by the marketplace. OrderID (37) stays the same while SecondaryOrderID changes for every replenishment. In a hit and take market, the users would then use RefOrderID (1080) with RefOrderIDSource (1081) = 0 as part of NewOrderSingle to reference the ID they saw in the public market data feed. This feature was added by OMX a few years ago for the scenario you are describing.
Regards,
Hanno.Hi,
I am using a Public Order ID concept to inform the replenished quantity of iceberg orders on the market data feed. i.e. Every time an iceberg order’s visible size trades and gets replenished, the newly added quantity to the book will be informed to the market using an add order message with the newly generated public order ID. This way, the chance of the market finding out about iceberg orders in the book is reduced.
I want the participants to know the new Public Order ID of their orders through the Execution Reports so that they can identify their orders on the market data feed. Is it acceptable if I use a separate Execution Report with ExecType=D (Restated) along with a new Public Order ID to inform users about the replenished quantity?
Eg :
- Buy Iceberg Order in the book : 3000(17000), OrderID = O1, PublicOrderID = O1
- Sell order aggresses for 3000 and trades with the visible size 3000.
- Buy Order replenishes : 3000(14000), OrderID = O1, PublicOrderID = O2
Is it ok to send the following Execution Reports?
OrderID = O1, PublicOrderID = O1/, ExecType = Trade, ExecQty = 3000, LeavesQty = 17000, DisplayQty = 0
OrderID = O1, PublicOrderID = O2, ExecType = Restated, ExecQty = 0, LeavesQty = 14000, DisplayQty = 3000, ExecRestatmentReason = 99 (Other)
[ original email was from John Harris - john.harris@bondmart.com ]
Thank you, Jim.
I agree with your observations, as well. I support open publication of rules and messaging specifications by exchanges, but people will use these to discern patterns and uncover useful information - that is inevitable, and even prudent.
Perhaps the display rules supported in FIX need to be elaborated a bit to incorporate a time element. We can instruct the exchange to create a random, visible size, but to my knowledge, not to vary the replenishment cycle. If order makers could randomly vary their refresh rates within certain bounds, that might help with obfuscation.
John, the assumption not stated in this discussion is that all orders regardless of type would be given a SecondaryOrderID(190). Of course, orders that are not replenished would maintain the same SecondaryOrderID(190) throughout the life of the order.
So this will provide a certain amount of protection for reserved (iceberg) orders, though sophisticated market participants could still likely predict and discover these orders within a couple of immediate orders. I am amazed at the amount of knowledge about market structure that exists in the more sophisticated market participants. There really is a multiple level playing field out there. Of course to a certain extent this has always been the case.
People for years complained about locals, market makers, specialists, large players with access to the floor in open-outcry. Now we have HFT and sophisticated algo trading participants that have replaced the locals. It seems as though all markets (not just financial markets) have an endemic amount of information asymmetry, at the point where this asymmetry becomes averse to the benefits of participants, new markets form.
Exchanges were the place where people met geographically to perform trade. Now exchanges are the places where computer systems (semi-autonomous agents) meet geographically (colocation) to perform trade.
Jim, I don’t see how this approach solves the problem, which I understand to be preventing detection of reserve orders. If we “put the identifier that changes with each replenishment into SecondaryOrderID(190),” wouldn’t recipients of the public (FIX) market-data feed infer the presence of a reserve order from the use of tag 190?
Other markets are doing what Hanno suggests: Put the identifier that changes with each replenishment into SecondaryOrderID(190). We should probably document this as a recommended practice, possibly on FIXwiki.
Hanno makes a good point re: explicitly identifying the refreshed peaks while also explicitly identifying the original public order ID.
I guess the underlying limitations of the matching engine may drive your final choice of implementation, are you able to share these to help the recommendations?
There is more than one comment to make on this question. You have left out OrderQty and CumQty in your example. The fiel for the executed qty is not ExecQty but LastQty. If you add OrderQty=17000 and CumQty=3000 then the equation OrderQty=CumQty+LeavesQty no longer holds as your first ER still has LeavesQty=17000 and only the second one has the reduced amount of 14000.
I concur with Aaron that the objective should be the least number of messages and in this case the solution is fairly straightforward by using SecondaryOrderID (198) for the public ID issued by the marketplace. OrderID (37) stays the same while SecondaryOrderID changes for every replenishment. In a hit and take market, the users would then use RefOrderID (1080) with RefOrderIDSource (1081) = 0 as part of NewOrderSingle to reference the ID they saw in the public market data feed. This feature was added by OMX a few years ago for the scenario you are describing.
Regards,
Hanno.Hi,
I am using a Public Order ID concept to inform the replenished quantity of iceberg orders on the market data feed. i.e. Every time an iceberg order’s visible size trades and gets replenished, the newly added quantity to the book will be informed to the market using an add order message with the newly generated public order ID. This way, the chance of the market finding out about iceberg orders in the book is reduced.
I want the participants to know the new Public Order ID of their orders through the Execution Reports so that they can identify their orders on the market data feed. Is it acceptable if I use a separate Execution Report with ExecType=D (Restated) along with a new Public Order ID to inform users about the replenished quantity?
Eg :
- Buy Iceberg Order in the book : 3000(17000), OrderID = O1, PublicOrderID = O1
- Sell order aggresses for 3000 and trades with the visible size 3000.
- Buy Order replenishes : 3000(14000), OrderID = O1, PublicOrderID = O2
Is it ok to send the following Execution Reports?
OrderID = O1, PublicOrderID = O1/, ExecType = Trade, ExecQty = 3000, LeavesQty = 17000, DisplayQty = 0
OrderID = O1, PublicOrderID = O2, ExecType = Restated, ExecQty = 0, LeavesQty = 14000, DisplayQty = 3000, ExecRestatmentReason = 99 (Other)
John, one can choose to only use SecondaryOrderID (alongside OrderID) on ExecutionReports which are private and then always use OrderID or even the generic field MDEntryID on the public market data messages. The same content can be delivered in different fields withiin different contexts (private vs public) to enhance obfuscation.
Jim, I don’t see how this approach solves the problem, which I understand to be preventing detection of reserve orders. If we “put the identifier that changes with each replenishment into SecondaryOrderID(190),” wouldn’t recipients of the public (FIX) market-data feed infer the presence of a reserve order from the use of tag 190?
[ original email was from John Harris - john.harris@bondmart.com ]
Thank you, Hanno - much appreciated.
John, one can choose to only use SecondaryOrderID (alongside OrderID) on ExecutionReports which are private and then always use OrderID or even the generic field MDEntryID on the public market data messages. The same content can be delivered in different fields withiin different contexts (private vs public) to enhance obfuscation.
Jim, I don’t see how this approach solves the problem, which I understand to be preventing detection of reserve orders. If we “put the identifier that changes with each replenishment into SecondaryOrderID(190),” wouldn’t recipients of the public (FIX) market-data feed infer the presence of a reserve order from the use of tag 190?