Order state machine: FIX states, late fills and tests

Short answer: An order state machine tracks which status each order is in, from pending new to filled, canceled, rejected or expired, and decides which exchange reports may change it. Rank reports by cumulative filled quantity and status, so late messages cannot move an order backwards, and reconcile on any contradiction. In tests on 10,000 shuffled synthetic histories, last-message-wins failed 7,967; this design failed none.

This guide is for developers with a live integration and an order that looks stuck, filled twice, or canceled and filled at once. FIX values come from the FIX Trading Community's Order State Changes document (November 2023); Binance, Bybit and Kraken statuses from their documentation, read on 6 November 2026.

This is technical guidance, not a recommendation of any exchange or strategy; automated trading can lose money, and availability depends on your jurisdiction and each platform's terms. Article 99/A of Capital Markets Law No. 6362 treats activity by foreign crypto-asset platforms directed at Turkish residents as unauthorized.

Order lifecycle states a trading client needs

A client needs nine states: six reported by the venue and three that exist only on your side.

Pending cancel is not canceled, as the FIX document stresses, and unknown is not rejected. The crypto order management system guide places this inside a wider OMS.

FIX OrdStatus values and order state precedence

FIX OrdStatus (tag 39) has 14 values in FIX Latest; when several apply at once, the one with the highest precedence is reported.

• ExecType (150) is the event; OrdStatus is the status after it.
• Fills during a pending cancel keep OrdStatus 6. In scenario B.1.c the completing fill is reported as Pending Cancel and Filled arrives on the Order Cancel Reject (reason 0, too late to cancel), so derive state from CumQty and LeavesQty.
• Rejected can follow New, and Pending New is sent only in reply to a status request.
• Final status, not final quantity: scenario J.1.b busts a 5,000 execution on a canceled order, then reports a new 4,000 one.

The QuickFIX Python guide runs a FIX session on localhost.

Order status names on Binance, Bybit and Kraken

Venues name statuses differently, so map them in one adapter and raise an error on any unknown name.

• One event, three names. An IOC remainder is EXPIRED on Binance, canceled on Kraken and Canceled in FIX (I.1.b); Kraken also cancels, not rejects, a pending order that fails validation. See time in force.
• Names hide fills. Bybit's Cancelled derivatives orders may have an executed quantity, so read cumulative quantity, such as z in Binance's executionReport.
• Kraken sends floats and trade-only IDs. Its executions reference types cum_qty as a float and sends exec_id on trades only; its lifecycle guide's example shows filled_qty instead. Use json.loads(text, parse_float=Decimal): by default Python 3.11.3 read 1e400 as inf and 1e-400 as 0.0. Never deduplicate on a missing ID.

For integration work in general, see Fincode's exchange API integration page; naming Binance, Bybit or Kraken here does not mean Fincode integrates them or has built on them.

Order state transitions: legal, stale and contradictory

A report is applied when it moves the order forward, ignored when it is older than what you know, and escalated when it contradicts a final state.

Forward means a higher pair of cumulative quantity and rank: NEW 1, PARTIALLY_FILLED 2, final states 3. Quantity orders shuffled reports; rank breaks ties, such as a fill and a cancel confirmation both at 0.4. Keeping the maximum makes repeats harmless.

A late NEW after FILLED is usually a delayed acknowledgment, not an error. Alarm on contradictions and impossible content: FILLED below the order quantity, a bad quantity, or an unmapped status.

Unknown order status after a timeout or lost response

After a timeout the order may be working, filled or never received, so look it up under the same client order ID and act on neither guess.

Binance's Spot documentation says an HTTP 5XX leaves the execution status unknown, possibly a success, and that its -1007 timeout after 10 seconds does not always mean failure; check the user data stream, then query.

1. Keep the order UNKNOWN and block orders that would duplicate its exposure.
2. Watch the user data stream and query by client order ID; any valid report ends UNKNOWN.
3. Never resend under a new ID; see the client order ID guide.
4. Distrust an early not-found answer: Binance re-checks recvWindow before forwarding to the matching engine, but its timing section does not say how long a request may wait there.

Fincode's order gateway reference runs this lost-response case against a local mock exchange.

Late fills after a cancel request

A cancel races the matching engine, so fills can arrive after you send it, in any order across channels.

Three FIX cancel scenarios matter here: a fill before the cancel is accepted, so the cancel is rejected as too late (B.1.c); an acknowledgment crossing the cancel (B.1.e); and a cancel for an unknown order (B.1.f). Record nothing as canceled until the venue says so.

The sample does not model trade busts (FIX ExecType Trade Cancel): it raises Broken when a final report shows less than it knows, as in J.1.b, but ignores a lower quantity on a non-final report. Add a correction event if your venue busts trades; Bybit's BustTrade execution type is a takeover liquidation, not a bust.

Tested Python: an order state machine with property tests

About 60 lines of standard-library Python, tested on 10,000 synthetic histories with repeats, shuffling, lost responses and cancel races.

Setup: Python 3.11.3 on Windows, 6 November 2026, seeds 0 to 9,999, no network or keys. osm.py:

from decimal import Decimal

RANK = {"NEW": 1, "PARTIALLY_FILLED": 2,
        "FILLED": 3, "CANCELED": 3, "EXPIRED": 3, "REJECTED": 3}
FINAL = {s for s, r in RANK.items() if r == 3}

class Broken(Exception):
    """A report contradicts what is known: stop this order and reconcile."""

def dec(x):
    if isinstance(x, float):
        raise TypeError("pass quantities as str or Decimal, not float")
    try:
        return Decimal(x)
    except ArithmeticError:                 # "" or "abc": NaN, rejected below
        return Decimal("NaN")

class Order:
    def __init__(self, qty):
        self.qty, self.filled, self.status = dec(qty), Decimal(0), None
        if not (self.qty.is_finite() and self.qty > 0):
            raise ValueError(f"bad order quantity {qty}")
        self.timed_out = self.cancel_sent = False

    @property
    def state(self):
        if self.status is None:             # nothing heard from the venue
            return "UNKNOWN" if self.timed_out else "PENDING_NEW"
        if self.cancel_sent and self.status not in FINAL:
            return "PENDING_CANCEL"
        return self.status

    def timeout(self):                      # new-order response lost
        if self.status is None:
            self.timed_out = True

    def send_cancel(self):                  # True: a cancel may go out now
        ok = self.state in ("NEW", "PARTIALLY_FILLED")
        self.cancel_sent |= ok
        return ok

    def cancel_rejected(self):              # e.g. too late to cancel
        self.cancel_sent = False

    def report(self, status, cum):
        cum = dec(cum)
        if status not in RANK or not (cum.is_finite() and 0 <= cum <= self.qty):
            raise Broken(f"bad report {status} {cum}")
        if (status in ("NEW", "REJECTED") and cum) or \
           (status == "FILLED" and cum < self.qty) or \
           (status == "PARTIALLY_FILLED" and not 0 < cum < self.qty):
            raise Broken(f"{status} with cumulative quantity {cum}")
        if self.status:
            old, new = (self.filled, RANK[self.status]), (cum, RANK[status])
            if new == old and status == self.status:
                return "duplicate"
            if new == old or (self.status in FINAL and cum > self.filled) \
                    or (status in FINAL and cum < self.filled):
                raise Broken(f"{self.status} {self.filled} then {status} {cum}")
            if new < old:
                return "stale"
        self.status, self.filled = status, cum
        return "applied"

test_osm.py checks that filled quantity never falls, a final state never changes and the end state matches the venue's:

import random
from decimal import Decimal
from osm import Order, Broken, FINAL

class LastMessageWins(Order):               # the common bug, for comparison
    def report(self, status, cum):
        self.status, self.filled = status, Decimal(cum)

def venue(rng, qty):
    """What the mock venue really did to one order: (status, cum qty)."""
    steps, cum = [("NEW", "0")], Decimal(0)
    while rng.random() < 0.6 and cum + Decimal("0.3") < qty:
        cum += Decimal(rng.randint(1, 3)) / 10
        steps.append(("PARTIALLY_FILLED", str(cum)))
    end = rng.choice(["FILLED", "CANCELED", "EXPIRED"] + ["REJECTED"] * (cum == 0))
    steps.append((end, str(qty) if end == "FILLED" else str(cum)))
    return steps[rng.random() < 0.2:]       # sometimes no NEW report

def run(cls, seed, qty=Decimal("1")):
    rng = random.Random(seed)
    truth = venue(rng, qty)
    msgs = truth + rng.choices(truth, k=rng.randint(0, 3))   # repeats
    rng.shuffle(msgs)                       # REST and stream, any order
    events = [("report", m) for m in msgs]
    for local in ("timeout", "cancel"):
        events.insert(rng.randint(0, len(events)), (local, None))
    venue_rejects_cancel = truth[-1][0] in ("FILLED", "EXPIRED", "REJECTED")
    o, i = cls(qty), 0
    while i < len(events):
        kind, msg = events[i]
        before = (o.state, o.filled)
        if kind == "report":
            o.report(*msg)
        elif kind == "timeout":
            o.timeout()
        elif kind == "cancel" and o.send_cancel() and venue_rejects_cancel:
            events.insert(rng.randint(i + 1, len(events)), ("cancel_rejected", None))
        elif kind == "cancel_rejected":
            o.cancel_rejected()
        stayed = before[0] not in FINAL or o.state == before[0]
        if o.filled < before[1] or not stayed:
            return False, events[:i + 1]
        i += 1
    return (o.state, o.filled) == (truth[-1][0], Decimal(truth[-1][1])), events

for cls in (Order, LastMessageWins):
    bad = [s for s in range(10_000) if not run(cls, s)[0]]
    print(f"{cls.__name__}: {len(bad):,} of 10,000 runs wrong")
print("shortest failure:", min((run(LastMessageWins, s)[1] for s in bad), key=len))

done = Order("1")
done.report("CANCELED", "0.4")
for case in [("NEW", "0"), ("PARTIALLY_FILLED", "0.6"), ("EXPIRED", "0.4"),
             ("PartiallyFilledCanceled", "0.4"), ("FILLED", "1e400"),
             ("FILLED", ""), ("NEW", 0.0)]:
    try:
        print(case, "->", done.report(*case))
    except (Broken, TypeError) as e:
        print(case, "->", type(e).__name__, e)

Output of python test_osm.py:

Order: 0 of 10,000 runs wrong
LastMessageWins: 7,967 of 10,000 runs wrong
shortest failure: [('report', ('PARTIALLY_FILLED', '0.3')), ('report', ('NEW', '0'))]
('NEW', '0') -> stale
('PARTIALLY_FILLED', '0.6') -> Broken CANCELED 0.4 then PARTIALLY_FILLED 0.6
('EXPIRED', '0.4') -> Broken CANCELED 0.4 then EXPIRED 0.4
('PartiallyFilledCanceled', '0.4') -> Broken bad report PartiallyFilledCanceled 0.4
('FILLED', '1e400') -> Broken bad report FILLED 1E+400
('FILLED', '') -> Broken bad report FILLED NaN
('NEW', 0.0) -> TypeError pass quantities as str or Decimal, not float

• The tests catch real bugs. Mutating the sample to apply stale reports failed 7,967 runs, as last-message-wins did; treating only lower quantity as stale failed 4,225.
• The paths ran. An instrumented copy counted 7,897 repeated reports, 20,137 stale ones, 2,026 unknown orders later settled and 1,479 cancel rejects, 821 after the final report.
• Not covered: amendments, busts, order lists, several cancels at once, restarts and real venues.

Frequently asked questions

What are the order lifecycle states?

Pending new, new, partially filled, pending cancel, filled, canceled, rejected and expired, plus unknown after a lost response. Filled, canceled, rejected and expired are final.

What is the difference between OrdStatus and ExecType?

ExecType (tag 150) says why a FIX ExecutionReport was sent; OrdStatus (tag 39) is the order's status after it.

What should a bot do when an order status is unknown?

Block duplicate exposure and look the order up by client order ID, on the stream and by query. Never resend it under a new ID.

Should an order state machine raise errors on illegal transitions?

Only on contradictions, such as a fill above a final report's quantity; log and ignore reports that are merely older.

Sources

• FIX Trading Community: FIX Application Layer, Order State Changes (FIX Latest as of EP284, November 2023) (opens in a new tab)
• FIX Latest OrdStatus code set, tag 39, on Orchimate (fiximate.fixtrading.org redirects there) (opens in a new tab)
• Binance Spot API documentation: Enum definitions (order status, execution types) (opens in a new tab)
• Binance Spot API documentation: REST API (HTTP return codes, -1007 timeout, timing security) (opens in a new tab)
• Binance Spot API documentation: User Data Stream (executionReport fields) (opens in a new tab)
• Bybit V5 API documentation: Enums (orderStatus, execType) (opens in a new tab)
• Kraken API documentation: WebSocket v2 executions channel (opens in a new tab)
• Kraken documentation: Order lifecycle guide (opens in a new tab)
• Capital Markets Law No. 6362, including Article 99/A (Turkish), mevzuat.gov.tr (opens in a new tab)

This guide is general information about software and markets, not investment, legal or tax advice. Automated trading can lose money, past or backtested performance does not guarantee future results, and the rules that apply depend on your jurisdiction and your exchange's terms. Sources, checks and corrections: see the editorial policy.