Why an Exchange Rejects Your Order: Min Notional

A rejection is a published number, not a fault

When an order is refused, the message is short and the cause is rarely mysterious. Every venue publishes the constraints that an order has to satisfy, pair by pair, and it publishes them to anyone who asks. The rejection is the venue applying a number it already told you.

That matters for two reasons. The first is practical: knowing where the number lives turns a support ticket into a lookup. The second is that the same lookup tells you how much room you have, which is what determines whether an order is possible at all at your account size.

The three constraints every pair carries

Strip away the naming and almost every spot market enforces three things:

1. A price increment. Your limit price must be a multiple of it. A price that is not a multiple gets rejected, not rounded.
2. A size increment. Your quantity must be a multiple of it, usually subject to a minimum quantity as well.
3. A minimum order value. The order has to be worth enough, measured in the quote currency, for the venue to accept it.

Binance and OKX both enforce all three. They differ in what they call them, which is the source of most of the confusion when you move between venues.

What Binance publishes for BTCUSDT

Binance exposes its constraints as named filters on each symbol. Reading exchangeInfo for the BTCUSDT pair on 2026-10-15 returned this set:

Four of those deserve a second look, because they are the ones that surprise people.

The minimum value is enforced on market orders. The NOTIONAL filter on this pair carried applyMinToMarket as true and applyMaxToMarket as false. The field names describe the behaviour: the 5 USDT floor applies when you send a market order, the 9,000,000 USDT ceiling does not. That is why a tiny market buy can be refused on a pair where the equivalent limit order would also fail, but for a reason you did not look for.

There are two different maximum sizes. LOT_SIZE caps a limit order at 9,000 BTC; MARKET_LOT_SIZE caps a market order at 125.58015654. A market order is capped far lower than a limit order because a market order has to be filled immediately against resting liquidity, and the venue limits how much of the book one order may consume.

Your price has to stay near the market. PERCENT_PRICE_BY_SIDE multiplies a recent average price to produce a band. On this pair the bid side allowed x1.2 above and x0.5 below; the ask side allowed x2 above and x0.8 below. A limit order priced far outside that band is rejected even though it sits inside PRICE_FILTER.

Amendments are limited. A single order may be amended 10 times. If you manage a resting order by amending it repeatedly, it will at some point stop accepting changes.

The pair itself also has to be tradeable. Of the 3,729 symbols the endpoint listed on the same read, 1,380 carried a status of TRADING and 511 of those were quoted in USDT. An order on a pair that is halted, or that has not started trading, is rejected for a reason that has nothing to do with your numbers.

The error message names the filter that failed

You do not have to guess which constraint you tripped. Binance’s Spot API documentation lists the rejection text it returns, and each message names the filter, so the fix is determined by the message rather than by trial and error. The failures arrive as a generic code with a specific suffix:

Two rules follow from that table. The first is that -1013 is not one error; the suffix is the error, and reading only the numeric code throws away the diagnosis. The second is that a MIN_NOTIONAL failure and a NOTIONAL failure mean different things on the same pair - one is a floor, the other a range - so the fix is not always “buy more”.

OKX reports the same class of problem through its own sCode and message pairs rather than Binance’s codes, and the message text is what identifies the failed field. Compare it with the instrument’s tickSz, lotSz and minSz rather than translating a Binance code into an OKX one; the field names differ, so the mapping is not one-to-one.

What those numbers mean in practice

Take the smallest order the pair accepts. The quantity must be a multiple of 0.00001 BTC and worth at least 5 USDT. At a price near 81,824 USDT per BTC, one step of 0.00001 BTC is about 0.82 USDT - well under the floor. So the binding constraint for a small order is not the step size at all; it is the 5 USDT minimum, which is reached at roughly 0.00006111 BTC. Rounding that up to a multiple of the step gives 0.00007 BTC.

Now take the other end. The largest market order is 125.58015654 BTC. That is a little over 10 million USDT at the same price - above the 9,000,000 USDT NOTIONAL ceiling, though on this pair the ceiling is not applied to market orders. For a limit order, the 9,000 BTC cap is far larger than the value cap, so the value cap binds first.

The lesson generalises: for a pair, exactly one constraint usually binds at each order size, and which one it is changes as the order grows.

OKX publishes the same three under different names

OKX’s Get instruments endpoint describes the same three constraints with a different vocabulary:

OKX also publishes a constraint Binance expresses with multipliers, but describes differently. Three fields - initPxLmtPct, floatPxLmtPct and maxPxLmtPct - define price-limit bands as percentages, documented as “the floating price-limit band during normal trading, e.g. 0.03 represents 3%” and a hard ceiling on deviation from the index price. The example values in OKX’s documentation are attached to a worked example instrument, not to a live market, so read them as a description of the field rather than a current limit on any pair you trade.

Two venue-specific details in that table are worth noting. maxMktSz on OKX is documented in USDT for spot and margin, not in the base currency, while maxLmtSz is in the base currency - a unit change that is easy to miss when you copy a number across. And state is not a boolean: post_only means the instrument is live but accepts only post-only orders, so a market order on a pair in that state is rejected even though the pair is trading.

How to size an order that passes

The sequence that avoids rejected orders is short and mechanical.

1. Read the pair’s constraints first. Fetch the instrument record for the exact pair. Do not assume a value that worked on another pair.
2. Compute the quantity from the increment. Divide your intended size by the step size, round down, and multiply back. Rounding down keeps you inside your risk budget; rounding up spends more than you decided to.
3. Check the result against the minimum value. Multiply the rounded quantity by your intended price and compare it with the minimum order value. If it falls short, add one step and check again.
4. Snap the price to the tick. Round the price to the nearest allowed multiple, then confirm it still sits inside the percentage band relative to the recent average.
5. Confirm the pair is tradeable. Check the status field before you build the order, not after it is rejected.

Step 2 is where a manual calculation most often goes wrong, in both directions. A calculator that returns an unrounded quantity, or a quantity rounded to a number of decimal places rather than to a multiple, will produce an order that is rejected for a reason that looks like a venue fault but is arithmetic.

Where to read the numbers yourself

Both venues publish these values through public, unauthenticated endpoints, which is the right way to check them - exchange documentation goes stale and help-centre screenshots go staler.

• Binance: GET https://api.binance.com/api/v3/exchangeInfo?symbol=BTCUSDT returns the full filter set for one pair. Without the symbol parameter it returns every listed symbol, which is a large response but shows how much the values differ across markets.
• OKX: the Get instruments endpoint documented at the API reference returns tickSz, lotSz, minSz and the max* caps per instrument ID.

Both responses are structured data, so a script can check an order before sending it rather than after it fails. If you would rather work the other way around, the position size calculator derives a quantity from a risk budget, and the trading fee calculator shows what the fill is expected to cost - neither replaces the venue’s own filter check, and both are more useful once you know which constraint is binding.

If you are choosing between the two venues rather than debugging an order, the Binance profile, the OKX profile and the Binance vs OKX comparison cover the structural differences. For how order type changes what you pay rather than what you may send, see maker and taker orders; for how size interacts with the resting book once the order is accepted, see spread, depth and slippage.

Risk note. The values in this article are a snapshot of what two venues’ public endpoints returned on 2026-10-15, and venues change tick sizes, step sizes and minimum order values without notice. Read the live values for the pair you are about to trade rather than relying on any figure reproduced here. Nothing in this article is investment advice, and a correctly sized order that passes every filter can still lose money.