forex-scalping.com

Rounding prices to tick size before an order goes out

Invalid price errors on order sends often come down to one thing. The price the EA calculated has more decimal places than the symbol allows, or it isn't a multiple of the symbol's tick size.

On most FX pairs the tick size equals the point, so rounding to the number of digits is enough. On some symbols, especially indices, metals and a few CFDs, the tick size is larger than the point. A symbol might show two decimals but only allow prices in steps of 0.25 or 0.5. Rounding to two decimals isn't enough there.

The safe approach is to read the tick size from the symbol properties at runtime and round every price to a multiple of it before sending. In MQL5 that's SYMBOL_TRADE_TICK_SIZE. Divide the price by the tick size, round to the nearest whole number, multiply back. Then normalise to the symbol's digits to clean up floating point leftovers.

Do this for entry prices on pending orders, stop losses and take profits. Market orders usually take the current price, but the stop and target attached to them still need rounding.

It's a small function, but it removes a whole class of rejected orders, and it means the same EA can run on a symbol with an unusual tick size without changes.

It's the kind of thing that only shows up when you move an EA to a new symbol, which is exactly when you're least likely to be watching closely. Running the EA on a demo of any new symbol for a day and checking the journal for rejections is a cheap way to catch it before it matters.

A quick way to see which symbols on your account need this is to print the tick size and point for every symbol in the Market Watch once, and look for any where the two differ.

Direction of rounding matters for stops and targets. Rounding to the nearest tick is fine most of the time, but for a stop loss you might prefer to always round away from the entry so the stop is never tighter than intended, and for a take profit always toward the entry so it's never further than intended. That way rounding can only make the risk slightly smaller and the target slightly closer, never the reverse. It's a minor detail on FX pairs, where a single tick is tiny, but on symbols with large tick sizes it can change the distance by a noticeable amount, enough to affect position sizing if the stop is very tight.

Lot sizes have the same issue. Each symbol has a minimum volume, a maximum volume and a volume step. A position size calculation that gives 0.137 lots will be rejected on a symbol with a 0.01 step unless it's rounded down to 0.13. Rounding down rather than to the nearest step keeps the risk at or below what the sizing logic intended. A combined helper that rounds both prices and volumes using the symbol's own properties covers most of the common rejection reasons in one place, and it's easy to unit test with a few example inputs for different symbols and edge cases.

Broker symbol properties can change. A broker might change tick sizes on an index after a contract change, or adjust volume steps on a metal. An EA that read these values once on initialisation and cached them will keep using old values until it's restarted. Reading them fresh before each order, or at least once per session, is safer. The performance cost is very small compared with the cost of an order being rejected at the moment you actually need it to go through, especially on a closing order during a fast move where every second counts. The cost of reading the properties is a function call or two, which is nothing compared with a slow order.

Tick size rounding catches a lot of EA developers on gold and indices. A useful pattern in MQL5 is to fetch SYMBOL_TRADE_TICK_SIZE and round to the nearest multiple of it, rather than using NormalizeDouble with the digits only. It is also worth checking the stop level setting, since some brokers require stops to be a minimum distance from the price, and that distance can widen around news. Both errors appear most often around the London open and US data, when prices move quickly between the calculation and the send.

Comparing prices for equality is a related trap. Two doubles that should be equal, like a calculated level and a quote, often differ in the last few decimal places due to floating point representation. Checking whether a price has reached a level should use a small tolerance, such as half a tick, rather than an exact equality test. Many hard to reproduce bugs in EAs come from code that waits for price to equal a level exactly, and the comparison simply never returns true even though the chart shows the level being touched clearly. MQL has NormalizeDouble and comparison helpers that reduce this, but a tolerance check is still the safer habit. Write it once as a small function and use it everywhere rather than repeating the comparison by hand in different places.