A Stop Loss Does Not Always Save a Position

I used to treat a stop loss like a seat belt: choose a level and the position will exit there. A stop is only an instruction to try exiting when a condition is met.

A stop market order can become a market order after the trigger. In a fast move, the fill may be worse than the trigger. A stop limit gives a price boundary, but it may never fill if the market jumps past it. Buying at 100 with a stop at 95 can still mean an exit near 90 when the next available bids are there.

Liquidity matters. The stop does not create buyers or sellers. In a thin order book, one order can consume several price levels. Compare position size with available volume and spread, not only with chart distance.

A stop placed too close is hit by normal noise. A stop placed too far makes the potential loss unreasonable. Place it where the original thesis becomes invalid, not at a round number that feels comfortable.

Before entering, write the invalidation condition, maximum loss, partial-fill plan, and what happens if the exchange or API fails. For bots, add cooldowns and a kill switch so retries cannot become repeated orders.

A stop is one layer of risk management. It does not replace sizing, exposure limits, or the acceptance that markets do not owe us a clean exit.

Operations and validation

Stops face exchange maintenance, timeouts after an order was accepted, stale websockets, and partial fills. A bot should persist order state, use an idempotent client order ID, and reconcile before retrying. A trailing stop can be hit by normal retracements, so test spread, fees, latency, and gaps. Convert risk into cash and total exposure; the existence of a stop is not proof that risk is finished.

Stop-market and stop-limit solve different problems

A stop-market prioritizes leaving and can fill far from the trigger. A stop-limit prioritizes price, but the position may remain open. Choose using spread, depth, position size, and behavior during volatility.

Gaps and partial fills are normal risks. Persist requested quantity, filled quantity, average price, and final status. An API timeout does not always mean failure because the exchange may have accepted the order. Reconcile before retrying and use an idempotent client order ID.

Backtests should include spread, fees, slippage, latency, gaps, and intrabar order. Paper trading validates integration; its simulator does not guarantee production liquidity. Follow with a very small amount to validate the order state machine.

Derive position size from cash risk and invalidation distance. Never widen a stop because size was too large. A stop needs exposure limits, monitoring, cooldowns, and a kill switch.

Checklist before relying on a stop

Confirm whether the exchange triggers on last, mark, or index price. Define who handles partial fills and how long the bot waits before canceling the remainder. Test a restart while an order is pending. Restrict the API key to required trading permissions and disable withdrawals. Compare expected loss with loss after fees and slippage. A consistently large difference means the risk model needs correction, not merely a wider stop.

Sources

• https://www.investor.gov/introduction-investing/investing-basics/glossary/stop-order
• https://www.cmegroup.com/education/courses/trading-and-analysis/stop-orders.html
• https://www.sec.gov/investor/pubs/assetallocation.htm