Skip to content
01TX
Insights

Connectivity

Symbol mapping is where most MT-to-LP bridges go wrong first

4 min read

Connect an MT5 server to a liquidity provider for the first time and the first real problem tends to be the symbol table, not latency or routing.

On the MetaTrader side a symbol is whatever the broker configured: EURUSD, EURUSD.m, EURUSDm, #EURUSD, depending on the account type and who set it up. The LP calls the same instrument EUR/USD or EURUSD, or sometimes gives you a security ID to look up. Matching the names is the easy part and everyone gets there. The rest of the mapping is what causes trouble later.

Digits first. Most FX symbols on MT have 5 digits (3 for JPY pairs), though plenty of servers run 4 and 2, and an LP may stream more decimals than the platform can display. Somewhere the bridge has to round, and the direction matters. Round the bid down and the ask up and the spread is never narrower than the LP's. Round to nearest and every so often you'll show a price better than anything you can hedge at. It's a fraction of a pip, but it's the same fraction on every tick.

Contract size is the one that costs money

A standard FX lot is 100,000 units of the base currency and most people stop checking there. Metals and indices are where servers disagree with each other. Say XAUUSD is set up at 100 ounces per lot on the MT side, but the mapping assumes 1 ounce per lot at the LP. A one lot buy then hedges 1 ounce instead of 100. Flip the numbers and you hedge a hundred times too much. Nothing errors out. Orders fill, the client sees a normal fill, and the mismatch turns up as exposure nobody expected, usually when someone reconciles positions at the end of the day.

Minimum size and step are the same kind of problem. MT will take 0.01 lots without complaint. The LP might not accept an order that small on that pair, or might want multiples of a larger increment. Those orders have to go somewhere: pooled until they're big enough, internalized, or rejected. It's better to decide that on purpose than to find out from a reject message.

Then there are symbols that exist on one side only. The MT server lists a crypto CFD or an index the LP never quoted, or the LP streams a pair nobody enabled. Decide what the bridge does with an order on an unmapped symbol (rejecting is a sensible default) and make it loud in the logs. A silent default is how a client ends up trading something that sits unhedged.

Check it when the bridge starts

Keep the whole thing in one table: MT symbol, LP symbol, digits, contract size, volume step, minimum size, rounding rule. Then have the bridge read the real symbol specs from the MT server at startup and compare them to the table. If they disagree, refuse to trade that symbol and say why in the log. Brokers change contract specs now and then and nobody tells the person who owns the bridge, so the check has to run on every start, not once at setup.

Test every symbol with a small order before going live, including the boring ones. The pairs you assumed were fine are the ones nobody tested.

None of this is clever engineering, just a spreadsheet with a startup check, but hedging, reconciliation and P&L all quietly assume the table is right.

Building something that runs into these problems directly?