Automation can follow a rule faster and more consistently than a person. It can also repeat an ambiguous instruction with the same consistency. A sound setup defines not just when to start, but how much it may trade, what counts as completion and what happens when the system is unsure.
The most useful controls address ordinary events: a partial fill, a delayed acknowledgement, a condition that stays true and a cancellation that has not yet reached the exchange.
What activates the order
“Buy above $100” leaves several possibilities. Should the order fire whenever price is above $100, only on a crossing from below, or after a candle closes above it? Which price is checked: last trade, mark, index or best ask? What happens if the automation is enabled when the condition is already true?
Multiple conditions introduce another timing question. Must they be true simultaneously, or can one event remain remembered until another occurs later? Insilico’s conditional-order documentation, for example, explicitly defines its AND conditions as simultaneous. That definition is useful only if it matches the intended idea.
State whether a trigger may act once, once per candle or repeatedly after a reset. A price staying above a threshold should not accidentally turn a single intended entry into a stream of new orders.
A timeout does not prove that nothing happened
Suppose an instruction requests 100 units, 40 fill and then the connection times out. Resending a fresh 100-unit order can produce 140 units even if the first remainder was cancelled, or as many as 200 if the original order later completes.
The safe next action depends on the venue’s recorded state. Check the original order identifier, fills, remaining quantity and current position before deciding what is still needed. Where the API supports an idempotent client identifier, use its documented behavior so retrying the same instruction does not create an independent duplicate. Do not assume every API provides that protection.
The FIX order-state specification demonstrates another ordinary race: an order can fill while its cancellation is pending, and the cancellation can be rejected because it arrived too late. A request and its confirmed result are separate events.
Exposure that can still be created
Suppose the maximum intended long position is 300 units. You already hold 200 and have an active buy for 100. Your remaining capacity is zero, even though the position screen currently shows only 200.
For a simple one-direction setup, count filled position plus all buy quantities that can still execute. More complex portfolios need rules for offsetting positions, conditional orders and contracts with different multipliers. The basic principle remains: an unfilled order is a commitment, not unused capacity.
Useful boundaries include maximum order size, total exposure, permitted instruments, an adverse-price limit and an expiry time. Recheck those boundaries when an order is replaced or an algorithm submits its next slice. A valid first order does not ensure every later child order remains within the intended risk.
Stop, cancel, and close
Stopping new submissions, cancelling working orders and flattening a filled position are three different actions. A “stop” button should have a meaning you can verify in account state.
After an interruption, reconcile before resuming. After cancellation, inspect the remaining orders. After a close instruction, inspect the remaining position. If an exit is intended only to reduce exposure, use the venue’s documented reduce-only behavior where available and understand how it handles partial fills or insufficient position size.
A small rehearsal should include an already-true trigger, a partial fill, a lost connection and a cancellation. The goal is to explain each resulting state and show that no extra position appears merely because a message was delayed. Reliable automation begins with an instruction that remains unambiguous when events arrive in an inconvenient order.