Crypto price bands: why a valid tick can still be rejected

Crypto price bands can reject an order even when its price uses the correct tick size. A tick defines permitted increments; a band defines the permitted range around an exchange reference. Check both against the exact market, side and current rules, then confirm the resulting price still fits the trade you authorized. Repeating an unchanged rejected request does not fix either constraint.

A distant limit order may look harmless because it cannot immediately trade at a worse price than its limit. The exchange can still refuse to accept that price. A bot needs to distinguish this refusal from a network timeout, an expired order and a price that the venue adjusted automatically.

Separate the price grid from the price range

For Binance Spot, PRICE_FILTER specifies minimum and maximum prices and a tick increment; enabled checks must all pass. PERCENT_PRICE and PERCENT_PRICE_BY_SIDE add reference-based ranges, with separate buy and sell multipliers in the latter. The current documentation uses a non-null symbol reference price when available; otherwise it falls back to the specified weighted-average window, or last price when that window is zero. A chart's latest price is therefore not a universal substitute. See the Binance Spot filter definitions.

Those are venue-specific rules, not numerical settings to copy into another exchange. Even on one venue, use the correct product, environment, symbol, side and order type. A spot pair and a similarly named perpetual contract are different rule contexts.

Keep quantity and notional checks separate. Increasing quantity cannot repair an off-grid price. Decreasing price can change notional and invalidate a check that passed earlier. The exchange order minimums worksheet covers those size and budget interactions; the worksheet here isolates price feasibility.

A worked price-band worksheet

Assume this fictional limit-buy configuration. None of these values describe a live symbol, and other order constraints are assumed satisfied solely to isolate the price calculation.

Multiplying the reference by each multiplier gives an inclusive band of 98.20 to 102.30. On the invented 0.25 grid, the lowest price inside that band is 98.25 and the highest is 102.25.

The strategy adds a tighter upper bound of 102.10. The highest tick satisfying both the band and that authorization is 102.00.

The nearest tick is not automatically the correct repair. Here it produces a valid exchange price but exceeds the strategy's cap by 0.15. The 102.00 candidate passes these price checks, but acceptance, execution and strategy suitability still need separate assessment.

For reuse, write the allowed interval as the intersection of the exchange band, static price limits and the strategy's authorized price range. Round the lower endpoint upward to the next valid tick and the upper endpoint downward. If the lower valid tick exceeds the upper valid tick, no price fits.

Suppose the strategy instead permits entry only from 102.05 through 102.10. There is no 0.25 tick in that interval. The answer is to stop or request a new trading decision. Silently widening the interval changes the instruction.

Use exact decimal arithmetic or scaled integers for implementation. A binary floating-point remainder near a boundary can be misleading. Record both the intended price and the normalized candidate so a reviewer can see what changed.

A valid snapshot can become stale

The example's reference is an observation with a time, not a permanent permission. Imagine it changes to 99.60 before validation while the hypothetical upper multiplier stays 1.023. The upper boundary becomes 101.8908, and its highest permitted 0.25 tick is 101.75. The earlier 102.00 candidate is now outside the range.

Refresh rules and reference information through the venue's supported sources, record their observation times and recheck immediately before a submission decision. Local validation can reduce avoidable failures; it cannot freeze the exchange's next evaluation.

Avoid solving a moving boundary with an unlimited retry loop. Decide beforehand how many fresh evaluations are allowed, how long the signal remains valid and when the workflow should stop for review. Otherwise, an old signal can keep chasing an accepted price after its original reasoning has expired. Repeated invalid requests also consume capacity needed for recovery; see exchange API rate limits.

Read the rejection reason before changing the price

Binance distinguishes PRICE_FILTER failures from percentage-price failures in its official Spot error reference. Preserve the exact code and message with the submitted non-secret price and order identity. A generic “order failed” label hides the distinction needed to diagnose the next action.

That reference also distinguishes a rejected API request from a timeout whose execution status is unknown. For an uncertain submission, establish the original order's state before attempting another trade. The timeout reconciliation guide explains the necessary order and fill evidence.

A confirmed rejection resolves that particular attempt; it does not prove there are no earlier orders or existing positions. Keep the scope of the conclusion tied to the attempt you actually checked.

Also confirm that the market remains eligible for trading. A symbol restriction or removal needs the delisting response process, rather than another attempt to repair its price.

Admission and execution can have different boundaries

Passing an initial filter does not promise that every later match will execute. Binance's separate Price Range Execution Rule governs execution where configured. Its documentation describes a taker order expiring when it attempts to execute outside the allowed range, with reason EXECUTION_RULE_PRICE_RANGE_EXCEEDED.

Treat that as an order-lifecycle event, rather than assuming the original request never existed. Inspect cumulative fills and the final order state before planning replacement quantity. The partial-fill guide develops that accounting distinction.

A later prevention event is another distinct outcome: self-trade prevention can remove an instruction when it meets related-account orders, even if its submitted price passed these checks.

Venue behavior can also depend on settings. Bybit documents a price-limit behavior option that can allow automatic adjustment or require rejection. Its price-limit behavior documentation describes distinct spot and futures defaults. Verify the actual account configuration and returned order price; do not infer the submitted price survived unchanged. This venue capability does not establish a corresponding KLINEO control.

Keep one decision record

Before resolving a price-band incident, capture these parallel pieces of evidence:

• The exact exchange, account scope, environment, product, symbol and side.
• The intended price, authorized price interval and actual submitted price.
• The tick rules, band rules and reference observation, each with its source and time.
• The response code and message, order identity, final status and cumulative fills.
• The decision to stop, reassess or submit a newly validated request, with its reason.

Switching to a market order is a new execution decision with different price uncertainty. It should not be an automatic escape from a rejected limit. The market versus limit explanation shows what that choice changes.

The useful outcome is a request whose price remains inside both current venue constraints and the trader's own authorization. An accepted order by itself proves neither that the strategy remains appropriate nor that the intended quantity will fill.

Editorial method: Prepared with AI assistance on 23 October 2026 using official Binance Spot and Bybit documentation. The price worksheet and changing-reference scenario are original hypothetical examples with checked arithmetic. No live orders, current symbol settings or customer outcomes were used.