“Cancel” Is a Request: When Cancellation Races With Execution

You press Cancel. A fill arrives while the app is showing the spinner.

That can happen without the venue violating your instruction. The cancellation still has to reach the point where the venue can apply it. Until then, the order’s remaining quantity may keep trading.

The investigation turns on the sequence of events and what each acknowledgment confirms.

Start with a partly filled order

Harbor is a fictional exchange for BAG, a fictional instrument quoted in dollars. Its order book holds buy and sell instructions waiting for a compatible counterparty. The matching engine selects those counterparties and records executions, also called fills. A working or resting remainder is the unfilled quantity still available to trade.

Harbor uses fully displayed orders, whole units, and one-dollar price ticks. Better prices have priority, then earlier orders at the same price; trades use the resting order’s price. Participants have different owners. New orders and cancellation requests take effect in a definite processing sequence on this one book.

M1 requested ten units at a $100 buy limit, so it can pay $100 or less. Its good-till-canceled instruction allows an unfilled remainder to keep working under Harbor’s rules. It bought four from seller S1 and three from seller S2. Seven have executed; three remain as a buy order at $100. Another buy order, B1, waits at $99, and seller S3 offers five at $101. S3’s price exceeds M1’s limit, so those two orders cannot trade.

The owner now requests cancellation of M1. We call the request C1 so we can distinguish it from the order it targets. Harbor’s gateway receives and validates client requests before they reach the engine’s ordered processing path. Receipt at that gateway does not yet mean the order has been removed.

Three different races

For Harbor, compare these alternative sequences from that same starting state:

What Harbor processes next	M1’s resulting outcome
C1 before any further eligible seller	Seven bought; three canceled
S4 sells two at $100, then C1	Nine bought; one canceled
A seller fills all remaining three, then C1	Ten bought; cancellation rejected as too late

In the middle case, the cancellation succeeds. It removes one unit still working. It does not undo the two-unit execution that happened first.

Figure 4.1. If cancellation takes effect first, seven units remain executed and three are canceled. If a two-unit sell precedes it, nine are executed and one canceled. If all three working units trade first, ten execute and Harbor rejects the cancellation as too late.

These are Harbor’s business outcomes, not a promise about every venue’s status strings or reject codes. FIX, a standard for electronic trading messages, has order-state examples that explicitly include executions while cancellation is pending and rejection when the request arrives after the order has filled. FIX order-state changes, scenarios B.1.b and B.1.c

A trade reversal or correction is a separate process under its own rules. Canceling an outstanding order does not automatically reverse its previous executions.

A plausible timeline

Use the middle case. Harbor assigns processing numbers to commands on this market: S4 gets 105 and C1 gets 106. Those numbers establish which instruction takes effect first; they are illustrative positions, not times of day:

Event	What it establishes
The user clicks Cancel	Local intent
Harbor’s gateway receives C1	A request reached that service
S4 is processed as command 105	Two more units execute against M1
C1 is processed as command 106	M1’s final working unit is removed
The app receives the fill and cancellation outcome	The client can reconcile nine executed and one canceled

The table is an illustrative ordering, not measured latency. A gateway can receive C1 while another path already has S4 ahead at the sequencing point. The user-facing click time alone cannot establish which command wins.

Figure 4.2. The user clicks Cancel and the gateway receives C1. S4 is ahead at the engine and command 105 fills two units before command 106 cancels the remaining one. The final reports establish nine executed and one canceled, regardless of when the screen updates.

There are also two directions of travel. A fill can already have happened while its notification is traveling toward the client and the cancellation request is traveling toward the venue. FIX documents this crossing-message case. FIX order-state changes, scenario B.1.b

Within an ordered session, do not casually explain every surprising message by saying the network reordered it. The apparent reversal may involve opposite directions, multiple channels, or client processing. Establish which order the protocol actually guarantees.

Harbor puts new orders and cancellations into the same logical command order. The diagram’s branches represent different command handlers, not permission for a cancellation to reach backward and change an earlier fill.

Pending cancel still carries exposure

While C1 has no confirmed outcome, the app should continue accounting for M1’s working remainder. It also needs to apply newly confirmed fills.

After S4, M1 has nine units executed and one still working, with cancellation pending. Once cancellation succeeds, the live remainder becomes zero and the one unfilled unit is recorded as canceled.

In FIX terminology, cumulative quantity is how much has executed in total, and leaves quantity is how much remains available to execute. The simple active-order equation, order quantity equals cumulative fills plus leaves, has terminal-state exceptions. A canceled order can have zero leaves without having filled its original quantity. FIX Trade specification, section 3.1.2

For Harbor’s unchanged ten-unit order, the business accounting is:

10 requested = 9 executed + 1 canceled unfilled
0 remains executable

The interface should communicate both facts. A large “Canceled” label beside the original ten-unit order can mislead the owner into believing no purchase occurred.

Acknowledged by which component?

A transport acknowledgment can establish delivery. A gateway acknowledgment can establish receipt. A venue’s final cancellation outcome establishes that a specific remaining order interest was removed. The exact meanings depend on the documented API.

Coinbase provides a particularly useful example: its FIX 5.0 mass-cancel report acknowledges processing of the mass request, while individual canceled execution reports establish the affected orders’ outcomes. A successful mass-request response should not be interpreted as every targeted order already canceled. Coinbase FIX 5.0 mass-cancel messages

Ordering can vary by API as well. Kraken documents sequencing for chained unacknowledged amends and cancels through FIX, but does not guarantee that transaction ordering through its WebSocket path. Read the protocol-specific contract before assuming two rapid requests take effect in send order. Kraken request-chaining caveat

A timeout leaves a question to resolve

Now lose the connection after C1 leaves the app.

C1 may never have reached Harbor. It may be waiting. It may have canceled the last unit while the response was lost. Or M1 may have filled completely before the cancellation could take effect.

The local timeout cannot distinguish these cases.

In our client design, M1 stays unresolved until reconnect recovery and authoritative order and execution information establish its outcome. Retrying C1 follows Harbor’s documented request-identity rules. A real venue may reject a duplicate, return an existing result, or offer a different recovery path.

Submitting a replacement buy while treating the first order as canceled is more dangerous. If the first remainder is still live, both orders can trade. “No response” is not evidence that exposure disappeared.

What an operator should reconstruct

For this incident, gather M1’s acceptance and fill history, C1’s identity and responses, the venue’s relevant sequencing evidence, and the client’s connection and message-processing history. Keep the command ordering separate from the time the screen changed.

Once command 105 and command 106 are established, the main case has a concrete answer: nine units bought, one canceled. The owner can still dislike the outcome, but the reconstruction explains which instruction removed which quantity.

If a connection or engine interruption prevents the final reports from arriving, the app must keep the outcome unresolved until it recovers authoritative order and execution records. Only then can it show the completed purchase and removed remainder accurately. Pressing Cancel establishes intent; the venue’s resulting order state establishes how much stopped trading.