Order Rejections
Understand crypto spot order rejections, balance checks, tick sizes, minimum notional, price bands, rate limits and safe recovery workflows.
Reading progress — saved on this device
An order rejection means the venue did not accept the instruction into the executable order state. Rejections can result from account balances, order-format rules, market protections, system limits or temporary venue conditions.
Rejected, cancelled and unacknowledged are different states
Rejected: the venue explicitly says the order was not accepted. Cancelled: an order existed and was later removed before full execution. Unknown/unacknowledged: the client does not know whether the venue accepted the message.
Those states require different responses. Only an explicit rejection provides strong evidence that no live order was created under that request—subject to correctly interpreting the venue API and order ID.
Common rejection categories
| Category | Examples | Typical fix |
|---|---|---|
| Balance/reserve | Insufficient quote asset, funds already reserved by open orders | Reconcile available balance rather than headline account balance |
| Quantity/notional | Below minimum size, above maximum, invalid step size | Round to allowed lot increment and satisfy min/max |
| Price formatting | Invalid tick size / too many decimals | Quantise to permitted price increment |
| Protection rules | Price outside venue band, market-order protection breached | Reprice or reduce size; do not bypass blindly |
| Order compatibility | Unsupported TIF/order type combination, post-only would cross | Adjust instruction while preserving intent |
| System/rate limits | Too many requests, maintenance, market paused | Back off, query state and follow venue status rules |
Safe rejection and uncertainty workflow
For automation, log the original parameters, timestamp, client order ID, HTTP/WebSocket response and subsequent order-state query. That creates an auditable trail instead of relying on the user-interface message alone.
Worked example
You submit a spot limit buy for 0.001 BTC at £80,003.27. The venue requires price increments of £0.10 and a minimum notional of £10.
The quantity gives roughly £80 notional, so the minimum is satisfied, but the price is invalid because £80,003.27 is not aligned to the £0.10 tick. The venue explicitly rejects the order.
Resubmitting at £80,003.20 or £80,003.30 may satisfy the tick rule, but which direction you round changes the economic instruction. A buy rounded upward can become more aggressive; a sell rounded downward can do the same.
Common mistakes and misunderstandings
- Treating every API error or timeout as proof of rejection.
- Blindly retrying an uncertain order without querying venue state.
- Using total balance instead of available balance after reserved open orders.
- Rounding price/quantity in a direction that unintentionally makes the order more aggressive.
- Ignoring market-specific tick size, lot size and minimum notional metadata.
Knowledge checkpoint
Q1. What is the difference between an explicit rejection and an unacknowledged/timeout state?
Q2. Why can available balance be lower than total account balance?
Q3. How can rounding to a valid tick accidentally change a buy order’s aggressiveness?
Q4. What should an automated client do before retrying an order after a timeout?
FAQ
❓ Does rejection mean I lost money?
A rejected order is normally not accepted for execution, so it should create no fill. The larger risk is misclassifying an uncertain state as rejection.
❓ Why is my balance insufficient when funds are visible?
Other open orders, holds, fees or settlement rules can reduce the balance available for the new order.
❓ What is tick size?
The permitted price increment for a market, such as £0.10. Prices not aligned to it can be rejected.
❓ Should I automatically retry every rejected order?
No. First identify and correct the cause; for timeouts or unknown states, query order status before any retry.
Summary
- Order rejection means the venue did not accept an instruction under its validation rules.
- Explicit rejection, cancellation and unknown acknowledgement states must be distinguished.
- Common causes include balance, minimums, tick/lot sizes, protection rules and rate limits.
- Safe retry logic queries state and preserves the original execution intent.
This building block explains execution mechanics and risk. It is not a recommendation, signal or instruction to trade any cryptoasset.
Want this in a personalised order?
Take the crypto assessment and get a custom path of 10 modules matched to what you already know. Free, no card required.
Build my path →