I am so sorry to stir this thing up again, but are you sure? Because strictly speaking the description in the TWS user guide would indicate that you can use SMART routing as long as the offset is â0.â As you have quoted yourself it says: ** Orders with a positive offset that are directed to Island will move up and down with the market. Orders with a "0" offset are submitted as limit orders at the best bid/ask and will move up and down with the market to continue to match the inside quote. The first statement is a specific note to the âDirectedâ entry of the table. The second statement is not a note but a general statement that would appear to apply to all orders â SMART routed as well as ISLAND directed. http://www.interactivebrokers.com/en/trading/orders/relative.php?ib_entity=llc Have you tested to see if there is any difference? I will try to test it myself. Maybe DAV can confirm whether you can use SMART routing with a â0â offset. Thank you.
Here is the question I asked IB and the answer I received: Question: Does a "Relative/Pegged-to-Primary" SMART-routed â0â offset order roll back with the market, or do I need to direct the order to ISLAND for the order to roll back with the market. The description Under âOrder Types and Algosâ -> âRelative/Pegged-to-Primary Ordersâ seems ambiguous on this point. http://www.interactivebrokers.com/en/trading/orders/relative.php?ib_entity=llc Thank you. Answer: I can understand the confusion. I will clarify. These particular Relative order types will never become less aggressive. So if you use "0" as the offset, then your order will move upward with the market, but never back down. In the description on the website that you reference, what they mean to say is that the order will "move up with buy orders and down with sell orders to continue to match the inside quote".
Completely wrong. 0 offsets roll back whether ISLAND or SMART routed. Any offset > 0 will roll back only if routed to ISLAND. The website is correct.
Thank you for your reply. I trust that you are right. I have asked the IB representative to check up on it again.
I have 2 more questions for those familiar with pegged orders : - what is the probability to be executed if you direct your orders exclusively to ISLAND : how much average time will you stay before being executed if for example you sent a pegged-to-midpoint order - how can you verify that your orders follow/rollback with the markets, knowing that those orders are hidden ... JC
Too many variables to answer your first question. I believe only the pegged-to-mids are hidden, so you can easily watch the others roll back (or not). TWS also has a field that will show current price which will allow you to see your prevailing bid/offer on a pegged-to-mid.
Thanks for the answer bs ! On Monday I sent trhough IB a pegged-to-midpoint order at 10:00 am on stock CSC. Limit was sent on the bid for a sell order. It executed 13 minutes later. Does it sound normal ? CSC has good volume. But how is it with less than 1 Million shares per day volume stocks for pegged-orders executions ? Is it still easy to execute with low volume stocks ? Let us say I want to execute in less than half an hour with a pegged-to-midpoint order. Is there a limit in volume/per day under which I should consider another order type ? My objective being to be executed near the NBBO ...
Question(s) for anyone at IB: Do native ISLAND REL orders route out if they become marketable on another ECN/exchange? Would you consider adding roll back functionality to HIDDEN SMART REL orders (pegged-to-primary) with positive offsets? This would allow trading outside of regular hours (not possible w/ISLAND natives). Additionally, if the answer to the routing out question above is no, these would presumably take care of that as well. If hidden rollbacks aren't feasible, how about enabling a discretionary amount on SMART REL orders with zero offset (that already roll back)? Or even adjusting the price field in the A/D algo under "Take Entire Offer" to allow for bid/ask +/- offsset?
We now support SMART REL order with zero offset and discretionary amount. No new TWS should be requires, this is backend change.