You’ve got a small crypto futures strategy that trades several contracts, and you’ve just moved it from backtest to paper trading. The first rebalance asks for 0.037 BTC. Your simulator accepts it; the venue rejects it because the contract’s quantity step is 0.001 and the order rounds below its minimum notional. Your position stays flat while the backtest records a fill.
That gap is easy to dismiss as a formatting bug. It can also change which assets you hold, when you rebalance, and how much risk remains after an order fails. Treat each venue’s trading filters as part of the strategy’s execution rules, and make your backtest and paper adapter apply the same rules in the same order.
What exchange filters can invalidate an order?
Start with the instrument metadata your order actually needs: quantity increment, minimum quantity, minimum notional, price increment, and any order-size or price-band limits. Their names and scope vary by venue. A spot pair may have a different minimum from its perpetual contract; a filter can change while your strategy is running.
Consider a target position worth $12 in a contract whose minimum order value is $10. If the quantity step rounds your order down to $9.80, the order is invalid even though the unrounded target cleared the minimum. Rounding up to $10.20 may make it valid, but it also overshoots the target by $0.20. That difference can be material when the account is small or the strategy trades many instruments.
| Rule | What it constrains | Backtest consequence |
|---|---|---|
| Quantity step | Permitted changes in order size | Rounded size differs from the target |
| Minimum quantity or notional | Smallest acceptable order | Some trades become no-ops or require rounding up |
| Price tick | Permitted limit and trigger prices | Price rounding changes the order’s chance of execution |
| Price band or size cap | Venue-defined bounds on order fields | Orders can be rejected during volatile markets or large rebalances |
Where should you put rounding in the order path?
Round the order fields after calculating the desired position change and before deciding whether to submit. Keep the unrounded target for analysis, then derive an executable order from the current position, contract multiplier, and venue increments. For a sell quantity step of 0.001, a desired reduction of 0.0017 becomes either 0.001 or 0.002 depending on your stated rule. Those choices leave different residual positions, so “round to precision” is not a complete policy.
For quantities, flooring toward zero avoids accidentally increasing exposure beyond the requested change, but it can leave tiny residuals that never trade. Rounding to nearest keeps average error smaller, though it can cross the target. Minimum-notional handling needs its own decision: skip the trade, accumulate until it clears the threshold, or increase size and accept the overshoot. Don’t silently switch among these behaviors.
And preserve the reason an order did not happen. “No order: below minimum notional” tells you something different from “filled at zero.” In a portfolio rebalance, a skipped order may leave cash idle or keep exposure in the old asset; record that result in the account state.
How do you keep backtest and paper execution aligned?
Use one order-validation function in both paths where your system architecture allows it. Feed it the same point-in-time instrument rules, desired order, and account state. It should return either a normalized order or a specific rejection reason. The simulator can then apply its fill assumptions to normalized orders, while the paper adapter sends equivalent fields to the venue.
Keep a dated snapshot of filter metadata alongside each run. If a quantity increment or minimum changes, you need to know which rule the backtest used. Fetching today’s metadata to replay a year-old strategy can make old orders look invalid, or make historical orders appear possible when they weren’t.
When the paper venue reports a rejection, compare the submitted fields and the filter snapshot before changing the signal. If the backtest’s order normalizer produced 0.037 BTC while the venue allowed increments of 0.001 BTC, the mismatch sits in the adapter or metadata. If the submitted order was valid but never filled, you’re looking at execution behavior such as price, liquidity, or time in force.
What should you inspect before trusting the comparison?
For each rebalance, keep a small audit trail: target position, current position, raw order, normalized order, applicable filter version, and final status. Then compare the paper and simulated records for the same decision time.
- Did both paths use the same contract multiplier and quantity units?
- Did they apply the same rounding direction and minimum-order policy?
- Were the filter values valid when the order was created?
- Did a rejected or skipped order leave the same position and cash in both accounts?
Your strategy may still be sound when its first paper rebalance fails. But until the simulator can explain why that order would have been accepted, rounded, skipped, or rejected, its equity curve describes a different execution system from the one you’re trying to run.
← All posts
