An accepted order is not necessarily a filled order. A partial fill means only part of the requested quantity executed, while the remainder stays open, is canceled, or expires. Automation that treats “submitted” or “accepted” as “complete” can create oversized stops, incomplete hedges, duplicate retries, and positions that differ from the strategy’s internal state.

Short answer: model every order as a state machine, use cumulative filled quantity as the source of truth, size protective actions to actual exposure, and reconcile orders and positions after every interruption.

Key takeaways

• Order acceptance confirms receipt, not full execution.
• Protective orders must follow actual filled quantity.
• Polling and streaming updates can arrive late, duplicated, or out of order.
• Cancel requests race with fills and require final reconciliation.
• Unknown states should pause dependent actions rather than trigger blind retries.
• DRKN can review visible account risk but does not replace execution controls.

Why do partial fills occur?

An order interacts with available liquidity under its price and time-in-force rules. A limit order may find only some quantity at the chosen price. A market order can sweep several levels, fill partially under protection rules, or encounter venue limits. Large orders, thin books, fast markets, precision constraints, and self-trade prevention all affect execution.

Time-in-force changes the outcome. Immediate-or-cancel orders fill available quantity and cancel the rest. Fill-or-kill orders aim for all-or-none behavior under venue rules. Good-til-canceled orders can remain open and continue filling later. Automation must know which behavior it requested and not assume every exchange implements labels identically.

How does a partial fill break strategy state?

Suppose a bot requests a 10-unit long and receives 4 units. If it immediately places a 10-unit reduce-only stop, the exchange may reject, resize, or later close more than intended depending on position mode and venue rules. If it records the full 10 internally, the next rebalance starts from a false position.

Hedges are similarly fragile. A partially filled spot purchase paired with a full futures short creates temporary net short exposure. In copy trading, follower quantity diverges from the leader. A later scale-out expressed as 50% may reduce different absolute amounts in each account.

What order state machine should automation use?

At minimum model: created, submitted, accepted, partially filled, filled, cancel pending, canceled, rejected, expired, and unknown. Store exchange order ID, client order ID, requested quantity, cumulative filled quantity, remaining quantity, average fill price, fees, and the latest trusted update sequence or timestamp.

Transitions must be idempotent. A duplicate fill event must not add the quantity twice. An older “accepted” message arriving after “partially filled” must not move the order backward. If stream continuity is lost, query the exchange’s order endpoint and rebuild state before issuing dependent instructions.

Mid-article CTA: Use DRKN to review what the account actually holds—exposure, leverage, concentration, and liquidation distance—while execution software handles verified order states and the user controls sensitive actions.

How should stops and take-profits follow fills?

Protection should reflect confirmed exposure. One design updates reduce-only protective quantity as cumulative fills increase. Another cancels the unfilled remainder after a timeout and protects only the filled amount. The correct method depends on strategy, venue semantics, and the risk of briefly unprotected fills.

Avoid creating multiple independent stops without tracking their aggregate quantity. When one exit fills, sibling orders may need cancellation. Confirm whether the venue supports linked orders, reduce-only flags, and trigger behavior. Even native order links require reconciliation after outages or manual account changes.

What is the cancel-fill race?

A cancel request does not prove the remaining quantity stopped trading. The exchange can fill more units while cancellation is in flight. The client may receive a cancel acknowledgment and a fill update in an unexpected order. Therefore “cancel sent” is an intermediate state, not a final quantity.

After cancellation, fetch final order status and current position. Use the final cumulative fill to resize protection and update strategy state. If the result is unknown, stop creating dependent orders and escalate. Guessing is especially dangerous when a retry could increase exposure.

What does a robust reconciliation checklist include?

Imagine a breakout bot requests 2 BTC, reports 0.8 BTC filled, then loses its websocket connection. A robust recovery is:

1. Freeze new strategy actions for that instrument. 2. Query the order by exchange or client order ID. 3. Query current position, open orders, and recent fills. 4. Compare cumulative fills with the internal ledger using trade IDs. 5. Detect whether the remaining quantity is still live. 6. Resize reduce-only protection to verified exposure. 7. Resume only after order, fill, and position state agree. 8. Record the interruption and test the recovery path later.

Run reconciliation periodically even without an obvious failure. Manual trades, liquidations, fee deductions, and missed events can create silent drift.

How do you test partial-fill behavior safely?

Use a sandbox or minimum-risk environment. Submit limit orders sized and priced to encourage a partial execution, then exercise cancel, reconnect, duplicate event, out-of-order event, and retry paths. Confirm that filled quantity never decreases, duplicate trade IDs do not double-count, and protective quantity never exceeds verified exposure.

Include property-style tests: for every event sequence, internal net position should converge to exchange position after reconciliation. Test precision rounding and minimum order constraints. Simulate a process crash between exchange acceptance and database commit—the same ambiguous boundary that creates duplicate orders.

How does DRKN complement execution controls?

DRKN can add account-aware interpretation after execution: Is the resulting position larger than planned? Did leverage or liquidation distance change? Is exposure concentrated? It should not be presented as an exchange matching engine, guaranteed fill monitor, or autonomous repair mechanism unless those capabilities are independently implemented and verified.

Prevent repeat effects with duplicate webhook order controls, connect partial fills to copy-trading tracking error, and isolate permissions with separate API keys.

FAQs

Is a partially filled order still open?

It may be. The remainder can stay open, cancel, or expire depending on status and time-in-force. Query the venue’s final state.

Should automation retry the unfilled quantity?

Only after verifying order and position state and applying fresh risk and price checks. A blind retry can duplicate exposure.

Can reduce-only orders remove all partial-fill risk?

No. They can limit accidental position reversal, but quantity, trigger, race, and venue-specific behavior still require reconciliation.

Does DRKN guarantee that automated fills are correct?

No such guarantee is made. DRKN is positioned around educational account-risk review; execution software and users must verify actual exchange state.

Sources

• Binance Spot API order status definitions
• Coinbase Advanced Trade order management
• FIX Trading Community order-state changes

Risk disclaimer: Automated crypto and leveraged trading can cause rapid losses. This article is technical education, not investment advice or an execution guarantee. Human review and venue-specific testing are required before publication and deployment.