Updating stop price from an Order.

[NetTecture]

I absolutely agree. If you get a lot more professional than Ninja - i.e. talk about FIX.... you will see that this was pretty much an issue. Automated trading support in the broker protocol. A lot of stuff was added in version 5 for that - for example, to add to your example - contingency order (an order triggered after another order is filled). Lets transmit market entry, stop loss AND profit target in one run and only update them

But then, brokers are behind. Never understimate the amount of work that takes on the backend. I dont know of any broker supporting FIX v5

The best I have seen so far is Rithmic - and they are still on that mostly simplistic order handling. What they allow is "hold" Orders - orders that are running totally through the system but not sent to the exchange unless released, which means on release the order does not need any validation in their system (risk management) anymore.

And they support more complex triggers than you ever see in an exchange - you can have a trigger based on even other instruments, and the trigger is done in the rithmic system.

But order management is still on an "enter and cancel orders" level. As with most brokers.

OCO, contingency orders.... are something I think would be a nice next evolution from a broker interface point of view. I fully agree.

[r2kTrader]

Funny you mentioned in one order. I am just finishing up my trading class that overloads all the EnterLimit methods. I now pass everything in one line of code and do my order management all custom. Why have a seperate StopLoss as a line, just pass the SignalName and ProfitTarget and StopLoss all in one line via the overloaded method

I have 3 over loads. Parameters include: double stopLoss, double ProfitTarget, bool ATM

ATM was written to emulate the break even / then trail feature of NT's native ATM. I got the base code from the downloads (dont have the user's name handy, but it's the only one in there with these features) and then spiced it up to fit my needs. By incorporating the signalName into the EnterXLimit() call with my overloads, I can build and change my Set()'s for each order as my signal dictates. What I like is that I move my profitTarget higher while trailing with a stop. If it punches higher, I capture that.

It's working GREAT! so far. And my code is MUCH cleaner.

I'm trying to get it to fly without having to use advanced order management and I think I have it. It's very slick and really gives me the order management I was looking for. I'm just trying to fix an inflight issue (how ironic eh?)

I used TT when I was with a firm back in Chicago. The problem is the cost. They (TT) wanted like 3k per month for the FIX adapter to use NT. That was a joke.

Your post is well said. I would like to connect with you via PM if you are interested.

Regards,

I absolutely agree. If you get a lot more professional than Ninja - i.e. talk about FIX.... you will see that this was pretty much an issue. Automated trading support in the broker protocol. A lot of stuff was added in version 5 for that - for example, to add to your example - contingency order (an order triggered after another order is filled). Lets transmit market entry, stop loss AND profit target in one run and only update them

But then, brokers are behind. Never understimate the amount of work that takes on the backend. I dont know of any broker supporting FIX v5

The best I have seen so far is Rithmic - and they are still on that mostly simplistic order handling. What they allow is "hold" Orders - orders that are running totally through the system but not sent to the exchange unless released, which means on release the order does not need any validation in their system (risk management) anymore.

And they support more complex triggers than you ever see in an exchange - you can have a trigger based on even other instruments, and the trigger is done in the rithmic system.

But order management is still on an "enter and cancel orders" level. As with most brokers.

OCO, contingency orders.... are something I think would be a nice next evolution from a broker interface point of view. I fully agree.