Trading bot partial fills: reconciliation without overtrading

What a partial fill changes

A partial fill means the venue executed less than the requested quantity. If a bot sends a limit buy for 100 shares and receives fills of 30 at $50.00 and 20 at $50.04, it owns 50 shares, not zero and not 100. The remaining 50 may still be live. The bot's decisions must use confirmed exposure rather than the original request.

The volume-weighted average price is:

fill mathaverage price = Σ(fill quantity × fill price) / Σ(fill quantity)

(30 × $50.00 + 20 × $50.04) / 50 = $50.016

Fees can arrive per fill and may be charged in the quote currency, base asset, or another token. Store the raw fill records, not just a rounded average. They are needed for exact position cost, P&L, and later audits. Read market vs limit orders for why liquidity and order type change fill behavior.

Model the order lifecycle explicitly

A local boolean such as order_complete cannot describe reality. Keep the venue order ID and your own unique client order ID, then track requested quantity, cumulative executed quantity, remaining quantity, average price, fees, and the latest venue status.

WebSocket execution events are fast but not infallible: connections drop, messages can be delayed, and clients can restart. REST snapshots are slower but useful for repair. A robust bot consumes streaming events for normal operation and periodically checks a venue snapshot to find gaps.

Resize stops and bracket orders to confirmed exposure

Partial entries create a protection problem. If 40% of an entry fills, a stop for the full intended quantity may sell more than the bot owns and open an unintended short. Waiting for a complete fill before placing any stop leaves the first 40% unprotected. The safest policy depends on venue features, but the invariant is simple: protective order quantity should never exceed confirmed reducible exposure.

1. Receive a fill and update cumulative entry quantity.
2. Fetch or calculate the authoritative net position.
3. Create or resize reduce-only stop and take-profit orders for that quantity.
4. Confirm the new protection before removing the old protection where atomic amendment is unavailable.
5. When an exit partly fills, reduce its sibling order so the combined exits cannot exceed the remaining position.

Some venues offer native bracket, OCO, or attached orders; their behavior on partial fills differs. Test the exact broker implementation rather than assuming the labels mean the same thing everywhere. The concepts in order types explained and order book depth help predict when partial execution is likely.

Build reconciliation around authoritative facts

Reconciliation asks, “What does the venue say exists right now?” and compares that with local expectations. Run it on startup, on a timer, after reconnecting a stream, after an ambiguous submit or cancel, and before clearing a kill switch.

python · conceptual reconciliationdef reconcile(venue, local):
    remote_orders = venue.fetch_open_orders()
    remote_fills  = venue.fetch_recent_fills()
    positions     = venue.fetch_positions()

    snapshot = merge_by_venue_and_client_id(
        remote_orders, remote_fills, positions
    )
    differences = compare(local, snapshot)

    for diff in differences:
        if diff.increases_unknown_risk:
            safety_gate.trip("reconciliation_mismatch")
        else:
            record_and_repair(diff)

Compare at least these invariants:

• every local live order has a matching venue order or terminal fill/cancel event;
• every venue order belongs to a known strategy, manual workflow, or quarantine list;
• the sum of fills agrees with the venue position after fees and transfers;
• protective exit quantity does not exceed the position it can reduce;
• no supposedly closed trade still has a resting order;
• no event page is incomplete because pagination stopped early.

Do not “repair” uncertain state by automatically cancelling everything. First determine whether the snapshot is complete and current. A partial API result is not proof that an order disappeared. Retry read-only queries with bounded rate-limit-aware backoff, then escalate if the evidence remains inconsistent.

Failure tests worth running

Log every state transition with IDs and raw venue status. An order journal makes a race condition reproducible and supports the broader practices in trading bot logging and monitoring. Run the full lifecycle in a sandbox, then at the smallest possible live size; paper venues often simulate fills more cleanly than real books.

Frequently asked questions