How to reverse a position in a bracket order when profit taker is hit?

[flying_dutchman]

OP wants to trigger everything automatically and have all orders ready at the start. They refer it as parent/child orders because that is how the API refer to orders that execute in cascade. Child orders are set and ready to be submitted when the parent order has entered the market. If the parent did not enter the market, a child order does not get triggered.

One way to set up the whole system would be to set a bracket order (3 orders) with a profit taker and a stop loss, depending on a parent for initial execution.

Then set another bracket order to sell again at the profit taker level with the parent being a limit order at that 110 level.

OP basically wants that bracket order to reserve automatically.

There's also another option with conditional orders, but a limit order is essentially that, a condition to enter the market.

https://www.interactivebrokers.com/en/trading/orders/conditional.php

Yup, that's exactly it. I'm developing an automated trading bot.

Basically, I'd like to put as much of the order management on IB's servers as much as possible, rather than having my bot run multiples times of the day and/or monitor the market in real time. Ideally, I would submit all orders possibly needed at market open and then the bot would just shut down and let IB handle the rest.

However, I'm starting to realize this isn't a good idea. What if a limit order only gets partially filled? For an intraday strategy (no holding overnight), the closing order's quantity would need be updated before the market closes. Or I could just use all or nothing orders. Either way, I'm thinking of running my algorithm not just before market open but near market close as well. This would be more complicated but whatever.

In my field (software development), we always strive to come up with designs that are the simplest, easiest to maintain, fault tolerant, etc. My original post was to see how much of my strategy I could have IB handle on their servers and not mine, which would be ideal.

 

[guest_trader_1]

Yup, that's exactly it. I'm developing an automated trading bot.

Basically, I'd like to put as much of the order management on IB's servers as much as possible, rather than having my bot run multiples times of the day and/or monitor the market in real time. Ideally, I would submit all orders possibly needed at market open and then the bot would just shut down and let IB handle the rest.

However, I'm starting to realize this isn't a good idea. What if a limit order only gets partially filled? For an intraday strategy (no holding overnight), the closing order's quantity would need be updated before the market closes. Or I could just use all or nothing orders. Either way, I'm thinking of running my algorithm not just before market open but near market close as well. This would be more complicated but whatever.

In my field (software development), we always strive to come up with designs that are the simplest, easiest to maintain, fault tolerant, etc.

The joys of trying to become rich the easy way. You have a 'FillOrKill' order. That would solve the size problem, but I don't think you can get away without adding some spaghetti code in there. Trading forces you to write the shittiest code ever, it is inevitable

 

[flying_dutchman]

Trading forces you to write the shittiest code ever, it is inevitable

I'm starting to realize that...when I try to write trading code that's readable, re-usable, etc. it actually does the opposite. I've given up on applying "best practices" to trading code.

Side comment: do you happen to know how the execution condition work? https://interactivebrokers.github.io/tws-api/order_conditions.html

When applied to an order, does it execute the order when one of *your* other orders with the same symbol and exchange gets filled? Or does it execute when *any* order at all (from anyone else) with the same symbol and exchange gets filled?

 

[guest_trader_1]

I'm starting to realize that...when I try to write trading code that's readable, re-usable, etc. it actually does the opposite. I've given up on applying "best practices" to trading code.

Side comment: do you happen to know how the execution condition work? https://interactivebrokers.github.io/tws-api/order_conditions.html

When applied to an order, does it execute the order when one of *your* other orders with the same symbol and exchange gets filled? Or does it execute when *any* order at all (from anyone else) with the same symbol and exchange gets filled?

Good question, bear in mind that the initial clientId can create isolated clients, with the 0 being the master of all ids. You are allowed to run multiple clients against the gateway with different ids, those ids will create independent contexts per client. The clientId = 0 will listen to anything you do with your account.

I understand these conditions as part of a client context, with the master id being able to listen to all of them.
So if you mean someone else as another account, I don't think that would be the case. These conditions must be part of an account context with the option to separate independent executions via the clientId.

 

[flying_dutchman]

Good question, bear in mind that the initial clientId can create isolated clients, with the 0 being the master of all ids. You are allowed to run multiple clients against the gateway with different ids, those ids will create independent contexts per client. The clientId = 0 will listen to anything you do with your account.

I understand these conditions as part of a client context, with the master id being able to listen to all of them.
So if you mean someone else as another account, I don't think that would be the case. These conditions must be part of an account context with the option to separate independent executions via the clientId.

Thanks! That's what I was hoping for...I'll have to test it first in a paper account just to confirm. I'm thinking I can stimulate a bracket order by applying the execution condition on 2 "child" orders in an oca group that won't be active until the "parent" one has been executed. Advantage of this over an actual bracket order is that the child orders can have different quantities so one of the child orders can be a sell limit on touch order with quantity 2x that of the parent to reverse the position.

I'm wondering if a LIT order that reverses a position counts as a single order rather than 2 in terms of commission costs.

 

[Bad_Badness]

I would follow RM advice and keep it simple. Once you introduce closing orders with a reversing position and bracket you add a host of testing scenarios that, as a professional test manager or a seasoned development manager would tell to yank out that code and stop it.

Here is why:

Every order type has inherent complexity. The orders need to be submitted from the brokers, to the Exhange and then executed. Any decent automation code verifies the execution before proceeding. Pretty straight forward with an Open or Close position order.

Now add a bracket. A bit more logistics and you hope the OCA-OCO, works OK. But now verify it and take into account overfills. What does you code look like now. How do you know what the brokers "overfill protection" actually does? How will your code react in ALL circumstances and the instruments you are using?

Now suppose you overfill, for reason XYZ. What happens if you bracket again. Write the code to verify that, WITH the recovery from an overfill.

What happens when the same reason for the first overfill happens again on closing the reverse? Write the execution verification code for that. Now write the code that corrects the overfill.

You just went from 5 branches to about 25 branches in complexity. Now test that 25 branch code. All for what benefit?

But you can do anything you want, write any code you want. But when comes to production quality code, one simply doesn't open cans of worms that are not needed. Lastly, I could come up with a bunch more scenarios that need to be checked and tested. These are just the obvious ones.