Why Brokers Rename the Same Instrument, and How Symbol Resolution Works
By the TradeAon team · Published · Updated · 8 min read
Spot gold is one market. Depending on which broker you opened an account with, it is called XAUUSD, XAUUSDm, XAUUSDs, XAUUSD.cash, XAUUSD.spot, GOLD or GOLDm. Your TradingView alert only knows one of those names. This page explains how that gap is closed, in enough detail that you can predict what will happen to your own symbols — including the case where automatic matching should not be trusted.
- Broker suffixes encode account type, not a different market —
mfor micro,cfor cent,.proand.rawfor spread model. - Resolution runs as a nine-step ladder, stopping at the first rung that produces an answer. The early rungs are exact and safe; the last two are guesses.
- The built-in table covers 34 canonical instruments mapped across 106 distinct broker spellings, and does most of the real work.
- A custom mapping sits at rung 2 and beats everything below it. If a symbol matters to you, pin it there rather than relying on the guessing rungs.
- The guessing rungs are validated before their answer is accepted — digit runs must match, so a Nasdaq signal can never land on gold or the Dow. An instrument your broker does not carry resolves to nothing rather than to a near-neighbour (section 05).
One market, seven names
There is no standards body for retail broker symbol names. Each broker names instruments to suit its own account types and its own back office, and the result is that the same underlying market carries a different string at every venue. This is invisible while you trade manually — you click the instrument in the terminal and it is simply there — and becomes very visible the moment a machine has to find it by name.
It matters in two places. When a TradingView alert arrives, the symbol in the payload came from TradingView's naming, which usually will not match your broker's. And when a trade is copied from one account to another, the master's name has to be resolved against the slave's list, which may be a different broker entirely with a different convention. The second case is harder, because both ends are moving.
The problem is bounded, though. Retail brokers pick from a fairly small set of conventions, which is why a lookup table plus a few rules gets most of the way there.
What the suffixes actually mean
Most variation is a base name with something bolted on. The suffix is nearly always describing the account type or the pricing model, not a different instrument, which is what makes stripping it a reasonable move.
| Pattern | Example | Usually means |
|---|---|---|
m | XAUUSDm | Micro account — smaller contract size |
c | EURUSDc | Cent account |
s | US500s | Standard account, or a broker's own series marker |
.pro / .raw / .ecn | GBPUSD.pro | Spread model — raw spread plus commission rather than marked-up |
.cash / .spot | USOIL.cash | Spot CFD rather than a dated futures contract |
.mini / .micro | GBPUSD_micro | Reduced contract size |
| Prefixes | M_EURUSD | Same idea, on the other end of the string |
The normaliser strips 78 suffix patterns and 18 prefix patterns, then removes non-alphanumeric characters and any trailing digits. On top of that sits a hand-built table of 34 canonical instruments — gold, silver, oil, the major indices, the major and cross FX pairs, bitcoin and a few agricultural CFDs — expanded across 106 distinct broker spellings. That table is what resolves the cases no rule could derive, such as GOLD and XAUUSD being the same thing, or DJ30, US30, DJIA and DOW being four names for the Dow.
The nine-step resolution ladder
Resolution is not one clever algorithm. It is nine attempts in a fixed order, and the first one that returns a symbol wins. The ordering is the whole design: the cheap, certain methods run first, so a guess is only ever reached when everything reliable has already failed.
| Rung | Method | Certainty |
|---|---|---|
| 1 | Exact match, case-sensitive | Certain |
| 2 | Your custom mapping | Certain — you defined it |
| 3 | Base mapping table | Certain |
| 4 | Built-in canonical table (34 instruments) | Certain — hand-verified pairs |
| 5 | Exact match, case-insensitive | Certain |
| 6 | Both sides normalised, then compared | High — validated before accepting |
| 7 | Fuzzy similarity, threshold 0.55 | Good — validated before accepting |
| 8 | Fuzzy similarity, threshold 0.45 | Low — validated, and logged as low-confidence |
| 9 | Give up, return nothing | — |
Here is the ladder resolving real symbols against a micro-account broker whose list is XAUUSDm, EURUSDm, US30m, BTCUSDm, USOIL.cash, XAGUSDm:
XAUUSDm -> XAUUSDm rung 1 (exact) GOLD -> XAUUSDm rung 4 (canonical table) XAUUSD -> XAUUSDm rung 4 (canonical table) DJ30 -> US30m rung 4 (canonical table) BITCOIN -> BTCUSDm rung 4 (canonical table) WTI -> USOIL.cash rung 4 (canonical table) SILVER -> XAGUSDm rung 4 (canonical table) EURUSD.pro -> EURUSDm rung 7 (fuzzy, 0.55)
Notice how much lands on rung 4. The hand-built table is doing the heavy lifting for exactly the instruments where naming diverges most — metals, indices and crypto — while the fuzzy rungs are left to mop up spread-model suffixes the table does not enumerate.
Results are cached per symbol and per candidate list, so this ladder is walked once and then answered from memory. Changing the broker's symbol list clears the cache, because a cached answer computed against a different list would be meaningless.
Why stripping suffixes is not enough on its own
An obvious question: if the suffixes are known, why not just strip them from both sides and compare? That is rung 6, and on its own it would be unreliable, because the stripping is greedy and sometimes takes too much.
Two real examples from the same normaliser:
XAUUSD -> XAUUSD EURUSD -> EURUSD
XAUUSDm -> XAUUS EURUSDm -> EURUS
equal? NO
The base name ends in D, the micro suffix is m, and dm is itself in the suffix list because some brokers use it. So XAUUSDM matches the longer dm rule before the shorter m rule and loses a character it should have kept. Normalised comparison therefore fails on one of the most common cases in retail trading.
It fails in the other direction too. US30 and US30m both normalise to US — the suffix goes, then the trailing-digit rule removes the 30. Those two happen to be the same instrument so the answer is right, but US30 and US100 would also both reduce to US, and those are emphatically not the same market.
This is the reason the canonical table sits at rung 4, above normalisation. A hand-verified pair beats a derived one, so the common cases never reach the fragile rule. Normalisation is a fallback for the long tail, not the primary mechanism — and if it were the primary mechanism, gold on a micro account would not resolve.
Where automatic matching stops being safe
Every rung so far has been trying to answer "which of these broker symbols is the one I was asked for". There is a different and more dangerous question underneath it: what if the instrument is not on this broker's list at all?
Fuzzy similarity cannot answer that on its own, because similarity is measured against whatever candidates happen to exist. When the right answer is absent, a fuzzy match will still return the closest thing that is present — and something is always closest. Index CFDs are the sharp edge here, because their entire identity is the number: US30, US100, US500, NAS100 and SP500 share a naming pattern and differ only in digits.
So the guessing rungs — normalised comparison and both fuzzy passes — do not get to decide alone. Their answer is validated before it is accepted, and the decisive test is that the digit runs on both sides must be identical. A similarity score is not trusted for this, because normalisation strips trailing digits: US100 and US30m both reduce to US and would score a perfect match against each other. Comparing the numbers directly is the only reliable separator.
The result, against the same micro-account list as before, is that an instrument the broker does not carry produces no match rather than a wrong one:
NAS100 -> (no match) Nasdaq is not on this broker's list NAS100 -> US100m resolved normally when the broker does carry it US100 -> (no match) against a list holding only US30m US30 -> US30m digits agree, so this still resolves
A signal that resolves to nothing is reported as a symbol that could not be resolved on the target account and no order is placed. That is the correct outcome: a rejected signal costs you a missed trade, while a signal quietly redirected to the wrong instrument costs you a position you never intended and does not look like an error from the outside.
What this does not do is tell you in advance which instruments your broker offers. Treat automatic resolution as a convenience for instruments that exist under some name, not as a substitute for checking. The defences are straightforward:
- Confirm the instrument is in your broker's Market Watch before you point a strategy at it. This is the check nothing else can do for you.
- Pin anything important with a custom mapping (section 06). Rung 2 beats every guessing rung.
- Test on a demo account first with a single micro lot and confirm the position opened on the instrument you meant, not merely that the alert was accepted.
- Read the event log after the first live signal on a new symbol — the resolved broker symbol is shown there, so a wrong match is visible immediately rather than at the end of the session.
This is also why the rejection messages are worth knowing. A signal that is rejected is a signal that did not trade; a signal that resolves to the wrong instrument is far more expensive, and it does not look like an error from the outside.
Custom mappings: the override that always wins
A custom mapping is a direct instruction: when you see this name, use that one. It is checked at rung 2, so it overrides the canonical table, normalisation and both fuzzy rungs. Adding one clears the cache immediately, so the next signal uses the new rule rather than a remembered answer.
Custom mappings are stored per installation and kept in two places — the cloud database as the source of truth, with a local JSON file written alongside as a backup, so a database outage does not lose your naming rules. On startup the cloud copy is preferred and the local file is refreshed from it; if the cloud is unreachable, the local file is used.
They are worth defining in three situations in particular. First, when your broker uses a naming convention the built-in table does not cover — regional index CFDs and exotic crosses are the usual candidates. Second, when a symbol currently resolves through rung 7 or 8 and you would rather it be certain than merely probable. Third, when you copy between two brokers whose names disagree in a way neither side's convention explains.
The general principle: automatic matching is there so you do not have to configure the obvious cases, not so you can skip thinking about the ones that matter. If a symbol carries real size, spend the minute it takes to pin it.