Status Quo
Well, buying and selling in a sequence and triggered by signals works smoothly.
The idea of bracket orders is not to map three orders simultaneously, which can also be done in a sequence. So it is not about trading strategy.
It is about the protection of the single order. With the help of an example, the difference and the importance becomes very clear in my opinion.
Example
If you currently place an order and then it is opened, this order waits for a signal to be closed again. If this signal does not come (for whatever reason!) the position remains permanently open.
So if a connection is interrupted or users simply do not actively intervene, in the worst case a huge loss can occur, simply because no signal comes.
This cannot happen if an order is placed with attached side orders.
Short Summary
https://interactivebrokers.github.io/tws-api/bracket_order.html
Technical aspects
* side orders are placed simultaneously and not sequentially
* Side orders are triggered only when the order is already filled (unlike OCO orders, where there is no hierarchy).
Conceptual aspects
* Protection of capital is the idea, buying and selling strategy is secondary
* Can be used as a simplified strategic component, alternative to "high-side sell limit" order and "low-side sell stop order" that correspond to an already open position.
From my personal point of view, an order can only run unobserved if certain safeguards are active for it. Especially when fully automated trading is performed.
Well, buying and selling in a sequence and triggered by signals works smoothly.
The idea of bracket orders is not to map three orders simultaneously, which can also be done in a sequence. So it is not about trading strategy.
It is about the protection of the single order. With the help of an example, the difference and the importance becomes very clear in my opinion.
Example
If you currently place an order and then it is opened, this order waits for a signal to be closed again. If this signal does not come (for whatever reason!) the position remains permanently open.
So if a connection is interrupted or users simply do not actively intervene, in the worst case a huge loss can occur, simply because no signal comes.
This cannot happen if an order is placed with attached side orders.
Short Summary
https://interactivebrokers.github.io/tws-api/bracket_order.html
Technical aspects
* side orders are placed simultaneously and not sequentially
* Side orders are triggered only when the order is already filled (unlike OCO orders, where there is no hierarchy).
Conceptual aspects
* Protection of capital is the idea, buying and selling strategy is secondary
* Can be used as a simplified strategic component, alternative to "high-side sell limit" order and "low-side sell stop order" that correspond to an already open position.
From my personal point of view, an order can only run unobserved if certain safeguards are active for it. Especially when fully automated trading is performed.
Rename
Have you seen this?
https://www.wealth-lab.com/Discussion/Bracket-orders-7419
https://www.wealth-lab.com/Discussion/Bracket-orders-7419
Hello Eugene,
thanks for the link.
1. This is a feature request because i do not want to programm sth.
2. OCO orders follow a different idea and work differntly
2a. OCO Orders do not have a priority in a group. Whichever is triggered first will cancel the others. It can happen that the stop order is executed before the "main order". You can easily see that when you use a limit order instead of a market order. In a Bracket order you have the "main order" called parent order. After the parent is filled the child orders can be triggered but not before that has happened. So, the three orders are grouped as unit and have a priority. How this behaviour can be implemented is linked above. First the parent order will be filled, then the bracket orders will be activated.
2b. I do not see how OCO orders currently work in an automated way. The reason is that the number of shares (buy + sell) need to manually updated in the order manager. This is a manuell step.
3. As Cone mentioned in the other thread.
I do not understand what is meant with the "same-bar exits" issue. It is about three orders that will be sent/placed (no exit logic involved) at the same time slot as many other orders. Attaching the bracket orders via parentId and synchronizing it via transmit flag. That doesn't break any WL design or concept of signals.
To sum it up. OCO orders are not the correct way for the technical and content related reasons. It is important that the three orders are placed in the same bar (time slot) and are "connected" as described. The attached orders will "guard" the order which would hang around when it does not get signaled at a later point.
thanks for the link.
1. This is a feature request because i do not want to programm sth.
2. OCO orders follow a different idea and work differntly
2a. OCO Orders do not have a priority in a group. Whichever is triggered first will cancel the others. It can happen that the stop order is executed before the "main order". You can easily see that when you use a limit order instead of a market order. In a Bracket order you have the "main order" called parent order. After the parent is filled the child orders can be triggered but not before that has happened. So, the three orders are grouped as unit and have a priority. How this behaviour can be implemented is linked above. First the parent order will be filled, then the bracket orders will be activated.
2b. I do not see how OCO orders currently work in an automated way. The reason is that the number of shares (buy + sell) need to manually updated in the order manager. This is a manuell step.
3. As Cone mentioned in the other thread.
QUOTE:
At this time, it's not possible to activate same-bar exits with Building Block Strategies.
I do not understand what is meant with the "same-bar exits" issue. It is about three orders that will be sent/placed (no exit logic involved) at the same time slot as many other orders. Attaching the bracket orders via parentId and synchronizing it via transmit flag. That doesn't break any WL design or concept of signals.
To sum it up. OCO orders are not the correct way for the technical and content related reasons. It is important that the three orders are placed in the same bar (time slot) and are "connected" as described. The attached orders will "guard" the order which would hang around when it does not get signaled at a later point.
A "same-bar exit" is when your "parent order" fills, the Order Manager can send one or more orders as a profit target and/or stop loss that could also execute on the same bar
Example:
Say you're trading 5-minute bars, the 10:00 bar ends, and you Auto-Place a limit entry order that will be active between 10:00:00.001 and 10:05:00. If the limit order is filled at 10:02, and you've programmed the AssignAutoStopTargetPrices() method, the Order Manager will immediately send the programmed stop and/or limit orders that can fill from 10:02 and 10:05.
That's the way it works and we´re not going to change the implementation just because the same thing could be done a different way.
Example:
Say you're trading 5-minute bars, the 10:00 bar ends, and you Auto-Place a limit entry order that will be active between 10:00:00.001 and 10:05:00. If the limit order is filled at 10:02, and you've programmed the AssignAutoStopTargetPrices() method, the Order Manager will immediately send the programmed stop and/or limit orders that can fill from 10:02 and 10:05.
That's the way it works and we´re not going to change the implementation just because the same thing could be done a different way.
Hello Cone,
first thanks for the explanation. This is only from technical point of view a similar thing but 100% not the same.
To really protect an open position, the side orders should be sent with the main order.
As said before, an order will stand alone if the signal cannot be sent or a manual intervention is not possible at a certain time.
For your example, this means that an order should be sent at "10:02" but may not be possible at that time. And then, do you really think that is worth 1000 bucks? (When the stop will not be placed and the price drops suddenly)
So, there is a big difference between the two implementations. The bracket order will not be filled at all or it has the guards. Your way seperates the buy and the sell signals. It can not be more different. There is a temporary split and it does not matter if it is at the same bar or the sell is triggered at later bar. It has a split.
It is very different!
I also don't understand why this is being discussed at all. In backtesting this has no effect, so nothing needs to be adjusted here. The sell signals SL+TP come from the exit strategy.
In live trading it protects money and enhance the WL software in this sense. It does not even affect the concept of signals. After the orders are placed the rest is executed on the broker side. As soon as a filled order disappears from the portfolio is resynced as with any other order.
first thanks for the explanation. This is only from technical point of view a similar thing but 100% not the same.
To really protect an open position, the side orders should be sent with the main order.
As said before, an order will stand alone if the signal cannot be sent or a manual intervention is not possible at a certain time.
For your example, this means that an order should be sent at "10:02" but may not be possible at that time. And then, do you really think that is worth 1000 bucks? (When the stop will not be placed and the price drops suddenly)
So, there is a big difference between the two implementations. The bracket order will not be filled at all or it has the guards. Your way seperates the buy and the sell signals. It can not be more different. There is a temporary split and it does not matter if it is at the same bar or the sell is triggered at later bar. It has a split.
QUOTE:
That's the way it works and we´re not going to change the implementation just because the same thing could be done a different way.
It is very different!
I also don't understand why this is being discussed at all. In backtesting this has no effect, so nothing needs to be adjusted here. The sell signals SL+TP come from the exit strategy.
In live trading it protects money and enhance the WL software in this sense. It does not even affect the concept of signals. After the orders are placed the rest is executed on the broker side. As soon as a filled order disappears from the portfolio is resynced as with any other order.
This is about securing real money, not a "look and feel" feature.
* existing concepts do not need to be adapted
* it is not redundant, it differs in that a position is secured at any time with opening and does not need another signal
* It improves security management / risk management
* It is best practice to open a position already with a SL
* It is risky to leave a position unsecured even temporarily regardless of the time period, but the longer the worse.
Especially when two different systems communicate with each other and the communication can be interrupted
* To provide another order type for the user would be user friendly. As well as other order types are selectable.
Ok, you can say that you don't care, but you can't say that the requirement is already implemented, just in a different way. This is simply not true!
* existing concepts do not need to be adapted
* it is not redundant, it differs in that a position is secured at any time with opening and does not need another signal
* It improves security management / risk management
* It is best practice to open a position already with a SL
* It is risky to leave a position unsecured even temporarily regardless of the time period, but the longer the worse.
Especially when two different systems communicate with each other and the communication can be interrupted
* To provide another order type for the user would be user friendly. As well as other order types are selectable.
Ok, you can say that you don't care, but you can't say that the requirement is already implemented, just in a different way. This is simply not true!
Hi MIH, I’m trying to understand what you’re looking for here. Would you like WL8 to submit a group of orders like a buy at market, a sell at limit and a sell at stop in one group at the same time?
We have to work within the reality of what the various broker APIs support. Additionally some brokers won’t allow an exit order to even be placed unless there’s an open position.
If there’s a supporting API for such a group order then by all means we can add this request to the development wish list but we have to research and see if it’s technically possible. If you already have some knowledge about a broker supporting this in an API let me know just so we can have the info recorded for when it comes time to implement the request.
We have to work within the reality of what the various broker APIs support. Additionally some brokers won’t allow an exit order to even be placed unless there’s an open position.
If there’s a supporting API for such a group order then by all means we can add this request to the development wish list but we have to research and see if it’s technically possible. If you already have some knowledge about a broker supporting this in an API let me know just so we can have the info recorded for when it comes time to implement the request.
Hello,
thanks for joining the discussion. I am aware that I can be a bit stubborn, please do not take this personally in any way.
At the moment your (Team) arguments just didn't convince me and I couldn't be told what I didn't understand.
I have already attached a concrete instruction as a link. It is about IB and the following implementations.
https://interactivebrokers.github.io/tws-api/bracket_order.html
https://interactivebrokers.github.io/tws-api/order_submission.html#order_attach
One result that has been discussed in several threads by now are OCO Orders.
However, these are not intended for the given context and work differently.
Corresponding posts can be read or can also be found in the course of this discussion.
thanks for joining the discussion. I am aware that I can be a bit stubborn, please do not take this personally in any way.
At the moment your (Team) arguments just didn't convince me and I couldn't be told what I didn't understand.
I have already attached a concrete instruction as a link. It is about IB and the following implementations.
https://interactivebrokers.github.io/tws-api/bracket_order.html
https://interactivebrokers.github.io/tws-api/order_submission.html#order_attach
One result that has been discussed in several threads by now are OCO Orders.
However, these are not intended for the given context and work differently.
Corresponding posts can be read or can also be found in the course of this discussion.
Thank you, so the enhancement would involve looking for an entry order accompanied by one or more exits all placed at the same time, and when this is seen, if the connected broker was IB, it could use IB’s bracket order.
In short, yes.
The detailed improvements are that the side orders are on hold but transferred at the same time. This is also a significant difference to OCO orders (parent child hirarchy and on hold status). Another point is that the open position does not have to wait on the complementary orders, which could fail for the reasons mentioned above.
This secures the positions and the portfolio even if there is no access/connection to the broker, either by WL or manually.
I think the automatic trading also gains quality and security, especially if it is not observed.
The detailed improvements are that the side orders are on hold but transferred at the same time. This is also a significant difference to OCO orders (parent child hirarchy and on hold status). Another point is that the open position does not have to wait on the complementary orders, which could fail for the reasons mentioned above.
This secures the positions and the portfolio even if there is no access/connection to the broker, either by WL or manually.
I think the automatic trading also gains quality and security, especially if it is not observed.
Alpaca also has this order type, and I'm pretty certain it can be configured in TDA using "legs" too.
Your point about access/comm is certainly a difference, and could make it worth pursuing even though it adds complexity.
Also, another difference would be the treatment of these exit orders following partial fill of the parent. Currently I think Wealth-Lab would only submit the child orders when the parent is fully filled.
Your point about access/comm is certainly a difference, and could make it worth pursuing even though it adds complexity.
Also, another difference would be the treatment of these exit orders following partial fill of the parent. Currently I think Wealth-Lab would only submit the child orders when the parent is fully filled.
According to the IB document it’s the same, the child orders are placed after the parent is completely filled.
And at Alpaca too - "once it is completely filled, two conditional exit orders are activated"
https://alpaca.markets/docs/trading/orders/#bracket-orders
https://alpaca.markets/docs/trading/orders/#bracket-orders
Thank you for taking a closer look at the topic.
Your Response
Post
Edit Post
Login is required