Generate bracket orders immediately server-side as conditional OCO set.

[hdo]

Description:
Currently, Bookmap generates bracket orders (take profit and stop loss) only after the parent order is filled and does so client side. This is rather risky if there’s a loss of connection or data feed issues. If the parent limit order fills during a connectivity issue, the position remains unprotected since the bracket orders aren't placed.

We had a broader discussion yesterday in our community on how people gear up for power and connectivity issues with UPS and multiple redundant internet connections or hosted servers. Non of that would actually be needed if Bookmap would create the brakets immediatelly servers side as conditional (to the parent order) OCO set.

Discussion and Proposed Solution
To my knowledge most brokers and protocols, including Rithmic, CQG, and Interactive Brokers, support submitting parent and bracket orders together as one atomic unit. This means that Bookmap could submit the parent order and the bracket OCO set conditionally linked to the parent order's fill status as a single transaction. By doing so, the bracket orders would be pre-configured and ready to activate as soon as the parent order is filled, ensuring protection even if connectivity issues occur. Implementing this change would significantly enhance the safety and reliability of trading operations by ensuring that positions are always protected.

[dxfcwfgyc]

I would also be happy about that.

[Andry API support]

As long as using bookmap core and not some addon:

• brackets with no trailing stop are server side
  
• brackets with trailing stop are client side
  

To verify that - you can place a lmt order with large offsets brackets and close bookmap and watch as bracket gets triggered from another app, like R Trader.
Otherwise, please let me know what I am missing.

[hdo]

The point is that those brackets are only created by Bookmap once it receives confirmation from the broker that the main order has filled.

So if you place a LMT order and then loose connectivity and the order fills while still offline there are zero brackets on the server exposing your capital to margin calls and yourself to bankruptcy (at least when trading futures).

People may consider this acceptable when trading prop accounts, but when trading personal capital the consequences can be severe.

It's not about brackets not being server side, the issues is that Bookmap only creates them once the main order fills. Brokers have server side mechanisms (conditional orders) to implement this in a proper and safe way.

[hdo]

I'm not sure why Bookmap decided to avoid using server-side conditional orders and chose to emulate them on the client side. This decision seems to create unnecessary problems and makes correct implementation more challenging. For instance, as mentioned in my IB/TWS issue thread, the client-side mechanism breaks down when a single order has multiple fills.

This client-side logic and the associated state machines add unnecessary code that needs to be tested and maintained. Even in the best-case scenario, this approach exposes future traders to fundamental risks. Brokers are in the best position to securely chain conditional orders (main + bracket OCO set) on their systems, and they already implement these mechanisms. Just use their mechanisms and don't reinvent the wheel.

Surly that's a design decision once made for a reason (simulated trading?), but I think it's time to reevaluate it. It's also really inconvenient from a usability point of view. Why would users only be able to see and adjust their brackets once the main order has filled at some point in the future? Whatever angle I try to look at it, it does not appear to be a good design choice to me.

[Svyatoslav]

For Rithmic specifically there are two types of brackets:
- bracket with normal stop - fully server-side
- bracket with trailing stop - this one is not, or at least was not supported by R API at the moment of implementation. So if you want the stop inside bracket to be trailing - we need to know which order is your bracket child order and make it trailing. This is problematic to achieve reliably without some additional IDs (also missing in API at that moment), so we had to do it client-side

If you want - send a normal bracket (NOT the one with trailing stop) from bookmap trade control panel (NOT from some addon, since addons can have their own implementations if they want to) and close bookmap. Then watch order behavior from something like R Trader.

CQG brackets are also server-side, as far as I remember. At the moment of implementation there were no "true" brackets, but there were OCO/OSO chains that you can fold into one another, so that's what we do there.

IB - don't remember from the top of my head. That one might be truly client side. If they actually have a server-side API we could add server-side implementation (not saying they don't - I just don't remember)
 

The point is that those brackets are only created by Bookmap once it receives confirmation from the broker that the main order has filled.

This isn't how it works on Rithmic, as far as I remember. Unless you use a trailing stop, but then see above.
 

[hdo]

Thank you for your reply. Highly appreciated.

This isn't how it works on Rithmic, as far as I remember. Unless you use a trailing stop, but then see above.

This is how IB currently appears to work. Brackets are server-side, but only create by Bookmap on a fill event and that currently it broken for an order that has multiple fills (same OCA ID is used across all brackets, but it needs to be unique per bracket).

I'll check Rithmic one more time. I' love to be wrong!

[hdo]

This isn't how it works on Rithmic, as far as I remember. Unless you use a trailing stop, but then see above.

You are right. I tested it a couple of times by placing a limit order and then firewalling Bookmap. It's interesting that R-Trader shows no hints regarding the conditional attached bracket as far as I can tell, but once the parent order fills, the bracket is indeed created server-side.

 So, my apologies for the noise. It's all good with Rithmic then, and the issue appears to be with IB/TWS only.

 May I also ask why we cannot see and adjust brackets in the UI/chart before the parent fills? Thanks!