You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
IB relative order
- Thread starter promagma
- Start date
Quote from promagma:
I use IB relative orders a lot. I use 0.01 offset so it is a limit order that floats inside the bid/ask spread, and I am getting good executions.
If I switch to unbundled pricing, is this usually "adding liquidity" and would get a rebate? I asked IB but haven't heard back.
Yes, it is - most of the time. The case in which you would not be adding liquidity is the following:
- smart router routes your bid of 25.07 to ISLAND
- an offer to sell at 25.07 shows up at ARCA
- smart router re-routes your order and takes the ARCA offer
In this case you are taking liquidity.
Quote from IBsoft:
Yes, it is - most of the time. The case in which you would not be adding liquidity is the following:
- smart router routes your bid of 25.07 to ISLAND
- an offer to sell at 25.07 shows up at ARCA
- smart router re-routes your order and takes the ARCA offer
In this case you are taking liquidity.
When using unbundled pricing, is there any max commission per order like the bundled pricing? If not, there might have no upside in trading bulletin board stocks with unbundled pricing.
Can I switch from bundled to unbundled back and forth a lot of times during the day? In order words, does this scheme work real time?
Thanks!
I believe that another situation, in which a REL order takes liquidity rather than adding it, is when the order interacts with a hidden order already resting on an ECN.
The REL order, I believe, is one of the most powerful and most underappreciated features offered by IB.
Here is my proposal for improving the REL order.
Case #1): A positive, non-zero offset. Retain existing functionality: order advances forward with the spread, but does not roll back.
Case #2): A zero offset. Order advances forward and rolls back with the spread. Retain existing functionality. (Was this feature ever debugged?)
Case #3): New functionality. Allow a negative offset. A negative offset REL order would act like a trailing limit order. Similar to a trailing stop, but it is a limit, not a stop. It would advance forward with the spread, but it would not roll back. Rolling back would make little sense with a negative offset.
The REL order, I believe, is one of the most powerful and most underappreciated features offered by IB.
Here is my proposal for improving the REL order.
Case #1): A positive, non-zero offset. Retain existing functionality: order advances forward with the spread, but does not roll back.
Case #2): A zero offset. Order advances forward and rolls back with the spread. Retain existing functionality. (Was this feature ever debugged?)
Case #3): New functionality. Allow a negative offset. A negative offset REL order would act like a trailing limit order. Similar to a trailing stop, but it is a limit, not a stop. It would advance forward with the spread, but it would not roll back. Rolling back would make little sense with a negative offset.
Quote from jimrockford:
I believe that another situation, in which a REL order takes liquidity rather than adding it, is when the order interacts with a hidden order already resting on an ECN.
The REL order, I believe, is one of the most powerful and most underappreciated features offered by IB.
Here is my proposal for improving the REL order.
Case #1): A positive, non-zero offset. Retain existing functionality: order advances forward with the spread, but does not roll back.
Case #2): A zero offset. Order advances forward and rolls back with the spread. Retain existing functionality. (Was this feature ever debugged?)
Case #3): New functionality. Allow a negative offset. A negative offset REL order would act like a trailing limit order. Similar to a trailing stop, but it is a limit, not a stop. It would advance forward with the spread, but it would not roll back. Rolling back would make little sense with a negative offset.
Good point about hitting the hidden order.
case 2: it now works
case 3: My initial reaction is negative for 2 reasons:
- relative orders put burden onto our system, because as the market moves we have to generate transactions to keep the order up-to-date at the exchanges
- by bidding a tick behind the best bid, you would be essentially chasing the up-ward trending market up to the point when it reverses at which point you would get filled; i.e. you would be buying the local highs
(granted that is also to some extent what the case 1 does, however, by the order being better than the market, the likelihood of an early fill is substantially higher)
Quote from IBsoft:
case 2: it now works
case 3: My initial reaction is negative for 2 reasons:
- relative orders put burden onto our system, because as the market moves we have to generate transactions to keep the order up-to-date at the exchanges
- by bidding a tick behind the best bid, you would be essentially chasing the up-ward trending market up to the point when it reverses at which point you would get filled; i.e. you would be buying the local highs
(granted that is also to some extent what the case 1 does, however, by the order being better than the market, the likelihood of an early fill is substantially higher)
Case 2: Zero-offset REL orders, which do roll back. Good that it works now.
Case 3: My proposal to add negative-offset REL orders, which do not roll back, and which act as trailing limit orders.
Point A: Problem of resource usage. The amount of computational and bandwidth resources required, per order, by my proposed trailing limit order type, would be almost exactly the same required by IB's currently existing trailing stop order type. I don't understand how one could be considered too resource intensive, but not the other.
Point B: Trading strategy. A trailing limit order would automate the very traditional and very widely practiced strategy of entering a trend by waiting for a pullback. This strategy should not be rejected based on an assumption that all pullbacks grow into reversals of trend. If this view were correct, then the world would be full of morons who became millionaires by using trailing stops. The reality is that many traders attempt, and I believe that many succeed, in profiting from trends by entering on small pullbacks. These traders attempt to distinguish small pullbacks from trend reversals. If a trader can, on average, make good guesses as to where to place trailing limits, then he can profit.
A trader might, perhaps, for example, place a trailing limit to buy (sell) slightly above (below) a perceived upward (downward) trendline, drawn along the local bottoms (tops) of the perceived uptrend (downtrend). He might also place a trailing stop exit some distance below (above) his perceived trendline, to protect against those situations in which the small pullback does actually grow into a full-blown reversal of trend.
The trailing limit order is, in many ways, the opposite of a trailing stop. The trader might place a trailing stop if he believes the pullback will continue to grow. The trader might place a trailing limit if he believes pullbacks will remain small and not reverse the trend. Both order types will require almost exactly the same amount of system resources.
IB initially resisted customer demands for trailing stops. Anyone who, like IB once did, thinks those using trailing stops are making a mistake, in a particular situation, can bet against them by placing a trailing limit positioned to take advantage of the trailing stops.
Both order types have their disadvantages. Trailing stops might suffer severe slippage under some market conditions, for example. Trailing stops are widely used, and I believe that trailing limits, if made available, might eventually also be widely used, in a wide variety of ways.
Quote from jimrockford:
Case 2: Zero-offset REL orders, which do roll back. Good that it works now.
Case 3: My proposal to add negative-offset REL orders, which do not roll back, and which act as trailing limit orders.
Point A: Problem of resource usage. The amount of computational and bandwidth resources required, per order, by my proposed trailing limit order type, would be almost exactly the same required by IB's currently existing trailing stop order type. I don't understand how one could be considered too resource intensive, but not the other.
Point B: Trading strategy. A trailing limit order would automate the very traditional and very widely practiced strategy of entering a trend by waiting for a pullback. This strategy should not be rejected based on an assumption that all pullbacks grow into reversals of trend. If this view were correct, then the world would be full of morons who became millionaires by using trailing stops. The reality is that many traders attempt, and I believe that many succeed, in profiting from trends by entering on small pullbacks. These traders attempt to distinguish small pullbacks from trend reversals. If a trader can, on average, make good guesses as to where to place trailing limits, then he can profit.
A trader might, perhaps, for example, place a trailing limit to buy (sell) slightly above (below) a perceived upward (downward) trendline, drawn along the local bottoms (tops) of the perceived uptrend (downtrend). He might also place a trailing stop exit some distance below (above) his perceived trendline, to protect against those situations in which the small pullback does actually grow into a full-blown reversal of trend.
The trailing limit order is, in many ways, the opposite of a trailing stop. The trader might place a trailing stop if he believes the pullback will continue to grow. The trader might place a trailing limit if he believes pullbacks will remain small and not reverse the trend. Both order types will require almost exactly the same amount of system resources.
IB initially resisted customer demands for trailing stops. Anyone who, like IB once did, thinks those using trailing stops are making a mistake, in a particular situation, can bet against them by placing a trailing limit positioned to take advantage of the trailing stops.
Both order types have their disadvantages. Trailing stops might suffer severe slippage under some market conditions, for example. Trailing stops are widely used, and I believe that trailing limits, if made available, might eventually also be widely used, in a wide variety of ways.
The trailing stops are based on simulated stops. As the market moves we don't resend the stops to the exchange; hence they do not consume exchange bandwidth.
Oh, now I see what you mean. Trailing limits would not require greater resources to monitor, than would trailing stops, but actually changing the resting order prices would require greater resources.
This is a very minor point relating to relative orders but I think it may be (or might have been) a bug in TWS. A few weeks ago I had my default order type set to relative orders. I decided to close out my last few positions of the day by using the TWS command to close all positions. I understood that this command would place sell or buy limit orders at the bid or ask depending on whether I was long or short, respectively. I think I had used it before and it worked as I expected. Instead, the command placed a group of relative orders. I assume that the close position feature of TWS should override the default order type feature.