Magic Number Collisions When Running Multiple EAs on One Account

What a magic number actually is

A magic number is an integer you assign in your EA’s code, attached to every order it sends, purely so your own logic can later filter through open positions and recognize which ones belong to it. When an EA loops through PositionsTotal() to check whether it should trail a stop, move to break-even, or close on a signal, it typically filters that loop by matching each position’s magic number against its own. That’s the entire mechanism. It’s worth being precise about what this is not: it’s not a broker-level construct, it’s not enforced by the MT5 server, and it’s not guaranteed unique by the platform in any way. It’s a convention that only works because your code respects it — the terminal will happily let two completely different EAs open positions tagged with the identical magic number, and nothing about the platform will warn you that this happened.

Where the collision actually comes from

This becomes a real problem the moment you’re running more than one EA on the same account and either of them uses a magic number that wasn’t deliberately chosen to be unique. It happens more than people expect because a huge number of tutorials, template repositories, and purchased EAs ship with the same handful of default magic number values — something like 123456, or 0, copied straight out of a widely circulated example. Deploy two EAs that both trace back to a shared tutorial lineage, and there’s a real chance they’re both tagging their trades with the exact same number without either developer having thought about it, because neither one was written with the assumption that it would ever share an account with anything else.

What it actually looks like when it happens

The failure doesn’t announce itself as a magic number problem. It shows up as something that looks like a bug in your strategy logic: a position that closes earlier than your exit rule should have allowed, a trailing stop that seems to move in the wrong direction, a lot size that appears to have doubled on what should have been one independent entry. The reason it’s so easy to misdiagnose is that the EA doing the unexpected closing or modifying isn’t malfunctioning at all — it’s working exactly as coded, managing a position it correctly believes belongs to it, because the magic number said so. It just happens to be managing a position that a different EA actually opened. People can spend real time auditing entry and exit logic for a bug that doesn’t exist in either EA individually, because the bug only exists in the interaction between the two, and nothing in either EA’s own code or logs points to the other EA as the cause.

The deeper issue: magic number collisions and netting accounts don’t interact the way people assume

There’s a subtler layer underneath this that matters even if you’re careful about assigning unique magic numbers. MT5 accounts run in one of two modes: hedging, where opposite-direction positions on the same symbol can coexist as separate tickets, or netting, where the server automatically merges all positions on a given symbol into a single net position regardless of which EA, or which magic number, opened them. If your account is in netting mode and you run two EAs trading the same symbol — one going long, one going short — the server doesn’t keep them separate just because your code tags them with different magic numbers. It nets them into one position at the account level, and each EA’s internal bookkeeping, which assumes it’s tracking an independent position it fully controls, is now out of sync with what the server actually holds. The magic number is a purely client-side concept; netting behavior is a purely server-side one, and the two don’t communicate. An EA can be completely correct about “here is the position I believe I own” while being completely wrong about what the broker’s server is actually doing with your net exposure on that symbol.

The exposure problem beyond identification

Even setting aside outright collisions, running multiple EAs on shared capital creates a risk-sizing blind spot that’s easy to miss. Most EAs compute their position size — their lot_size, or a risk-percentage-derived version of it — based on the account’s current free margin, on the assumption that they’re the only thing consuming it. Two EAs, each independently sizing a new position off the same free margin figure at roughly the same moment, can jointly commit far more account risk than either was individually designed to take on, because neither one has any visibility into what the other is about to do. This isn’t a bug in either EA’s position-sizing formula. It’s a structural blind spot that only exists once you stop running one system in isolation, and it’s invisible in a single-EA backtest, since a single-EA backtest has no reason to model concurrent, uncoordinated risk-taking from a second source.

Auditing for it after the fact

If you already suspect this has been happening — an account with more than one EA deployed and a history of unexplained early exits or odd lot sizes — it’s checkable retroactively without much effort. Pulling the account’s trade history through mt5.history_deals_get() and grouping by magic number is the fastest way to see the actual picture: if a magic number you believed belonged to one specific EA shows entries and exits that don’t match that EA’s own logged decisions, or shows position sizes inconsistent with what that EA’s lot_size configuration should ever produce, that’s a strong signal something else is writing to the same tag. Cross-referencing the deal history’s magic number column against each EA’s own internal log of what it opened and closed, timestamp by timestamp, will usually surface a collision within a few minutes of looking, once you know to look for it specifically rather than assuming the count of open positions and the count your own EA believes it owns should always agree.

Making the collision visible instead of discovering it live

The practical fix is cheap relative to the failure mode it prevents. Maintain an explicit registry — even a plain text file, or a dedicated field inside the JSON config you already use for start_hour, end_hour, lot_size, sl, and tp — that reserves a specific magic number for each deployed strategy before it ever goes live, and treat a new deployment’s magic number as something you check against that list rather than something you accept from a template. Alongside that, it’s worth explicitly confirming whether the account is running in netting or hedging mode before deploying a second EA onto a symbol you’re already trading, since that single account-level setting determines whether “separate magic numbers” is actually sufficient to keep two strategies’ positions independent, or whether the server is quietly merging them regardless of what either EA’s code believes. And where multiple systems share one account, sizing decisions are worth computing against total account exposure rather than each EA’s isolated view of free margin — which usually means a small shared risk-tracking layer sitting above the individual EAs, rather than trusting each one’s internal math to account for capital it doesn’t know is being used elsewhere.