Order Safeties for Automated Trading and Independent Risk Controls
Summary
The document collects operational safeguards for an automated trading script interacting with an exchange API. The proposed controls include prioritizing exits and stop orders, checking whether orders reached the venue, handling failed requests, monitoring venue availability, and ensuring that fills and protective orders are reconciled. It also emphasizes order quantity consistency and awareness of exchange order limits. These details illustrate how execution logic can account for partial failures and changing market conditions.
The accepted response highlights two broader controls: detect loops that repeatedly submit, cancel, or replace orders, and impose hard limits on those actions. It also recommends a separate process that listens for fills and can stop the trading process when risk limits are exceeded. The document is an exchange-specific discussion rather than a complete production design; its safeguards depend on venue behavior and do not establish that any particular retry or stop-order policy is universally safe.
Key ideas
- Prioritize protective orders and exits when an automated process handles exchange requests.
- Reconcile fills and verify that orders were received by the venue.
- Set hard limits on order submissions, cancellations, and replacements to contain runaway loops.
- Use an independent fill-monitoring risk process that can stop trading when limits are breached.
- Exchange-specific order limits and failure behavior should inform safeguards.
Tags
Full text
# What order safeties are there? # What order safeties are there? stackexchange, I am currently programming a script to use on the Bitmex API. In algo trading a lot can happen to cause an error in the script, so my question to you all was if I missed a safety and what kind of safeties y'all are using? This is the list of safeties and optimizations that I am using: - Use mark price for stoploss when calculating profit. - Complex calculations out of the main loop. - Use bucketed orders. - Order handling is priority over getting data (stoplosses first, then take profit order, then entry order, then price data). - Bitmex offline server safety, make sure there are no open trades when the server is offline. - Use Websocket API. - If request failed, retry request 1/2x (if there is no overload error) otherwise shut down. If request failed for entry order with overload error, if the running price is x% close to the entry price dont execute the order If request failed for stoploss / exit order with overload error, keep trying till it goes through (check if its possible to execute stoploss if running price already passed the appointed stoploss price) - If base order filled and straight below stoploss price, stoploss placement will get an error, if below cancel stoploss placement and exit at market. - 2th check from BitMEX side, check if base order has stoploss and takeprofit order. I already check on my side if after I submitted an order if BitMEX recieved it. - Max 10 stop orders (BitMEX limit). - Use 1 order quantity for the whole trade (same amount for entering an exiting a trade). I was wondering if I missed some? I am also curious what kind of safeties and optimizations y'all are using and willing to share? Thanks in advance! ## Answer by JoshK (score 3, accepted) https://quant.stackexchange.com/a/58718 The biggest risk as I've seen is from falling to loops. Make sure to check the quantities of orders, cancels, replaces. Have hard-breaks on any exceptions to those quantities. For your risk can you have a separate process that listens to fills? It's good practice to have a separate risk engine that can kill the trader if limits are breached.
Shown in full with attribution under the source's licence. Licence: CC BY-SA 4.0 (Stack Exchange)
This summary was written by Stratmill's research agent from the original; it is not a copy of the source.