Reducing Limit Order Churn from Rounded Fair Prices

Summary

The document describes a trading-system issue in which a fair-price estimate is rounded to price increments and alternates between adjacent ticks. When the system amends a resting limit order whenever its target differs from the order price, this oscillation can trigger repeated, unnecessary amendments.

The response suggests that the underlying fair-price estimate may itself be unstable and observes that coarser rounding can suppress small fluctuations. The example is brief and provides no diagnostic procedure, smoothing method, tests, or evidence that coarser rounding is suitable in every market. It therefore points to estimate stability as a potential root cause, while leaving open how to distinguish genuine price changes from noise and how to balance fewer amendments against pricing accuracy and execution risk.

Key ideas

• Rounded fair-price estimates can alternate between adjacent ticks and cause repeated limit-order amendments.
• The response identifies instability in the underlying fair-price estimate as a possible root cause.
• Coarser rounding may suppress small fluctuations, though the document gives no evaluation of its trade-offs.
• The example offers no tested smoothing or filtering method for separating noise from meaningful price changes.

Tags

# Function price output hops around sometimes due to rounding


# Function price output hops around sometimes due to rounding












Say we have a function for estimating the fair price of a security. The function gives outputs rounded to the nearest 0.5 (that is, the raw output is not a rounded float, but can have a decimal part in between 0 and 0.99).

Now, a trading system takes this input and amends the price of a limit order if the price calculated by this function of ours does not match the price of our order in the orderbook.

The problem is, due to rounding off, the output has a tendency to hop around at times, such as at any given time `t`:

```
px(t0) = 100.0
px(t1) = 100.5
px(t2) = 100.0
px(t3) = 100.5
px(t4) = 100.0
px(t5) = 100.5
```

This causes the system to needlessly amend the limit order too frequently.

How does one get around this problem?

## Answer by wildbunny (score 1)

https://quant.stackexchange.com/a/44862

The root cause is surely that your fair price is quite unstable? Rounding can only serve to stabilise your output value, for example rounding to 0 decimal places would result in 100 for all values.

Shown in full with attribution under the source's licence. Licence: CC BY-SA 4.0 (Stack Exchange)

This summary was written by Stratmill's research agent from the original; it is not a copy of the source.