MT5 Trade Copier Architecture: Latency, Partial Close Sync and Why Cheap Copiers Fail
A trade copier looks simple on the surface — see a trade, copy a trade. The engineering below the surface decides whether your slave accounts stay in sync or drift into orphaned positions. This deep-dive covers the event pipeline, the three transport architectures, and the failure modes we have been paid to fix. It is the same standard we apply when clients hire MQL4/MQL5 developers for infrastructure projects like this one.
Table of Contents
What a Copier Actually Does
Strip away the marketing and a copier is a four-stage pipeline, executed once per trade event:
- 1. Detect. The master terminal fires
OnTradeTransactionfor every server-side trade event — order placement, fill, partial close, SL/TP modification, deletion. The copier subscribes to these events withDEAL_ENTRY_IN,DEAL_ENTRY_OUTand modification types as its vocabulary. - 2. Decide. Filter rules run: is this symbol in the copy list? Does it pass the news, spread and session guards? What is the scaled lot size on this slave, and is it within the slave's risk limits?
- 3. Transmit. The decision crosses the transport layer — an in-process call, a local socket, or a network relay — carrying the symbol, volume, direction, SL/TP and the master's position identifier.
- 4. Execute. The slave side maps the symbol (suffixes, currency aliases), validates broker lot constraints, and submits through
CTradewith bounded retry on requotes and busy errors.
Everything that makes a copier reliable lives in stages 1 and 4: event fidelity on the master, and disciplined execution on the slave. Stages 2 and 3 are where product features live — and where cheap copiers spend all their budget. The same event model is covered in the MQL5 EA architecture guide.
Three Architectures: Local, Socket Bridge, Cloud Relay
Every copier is one of these three. The choice is a latency-complexity trade-off, and most traders buy more architecture than they need.
| Architecture | Latency | Complexity | Best Use Case |
|---|---|---|---|
| Local terminal copy | <10 ms | Low — one terminal, multiple logged-in accounts | One trader, several personal or funded accounts |
| Socket bridge | 20-80 ms | Medium — two terminals on one VPS, IPC channel | One trader, different brokers, same machine |
| Cloud relay | 80-300 ms | High — remote server, auth, queues, retries | Cross-location copying or selling signals to subscribers |
The socket bridge is the workhorse for funded-account management: one master terminal on a VPS, one or more slave terminals on the same machine, an IPC channel between them. It gets you broker independence without the trust and latency cost of a third-party server.
The Latency Budget
Latency in a copier is not one number — it is a budget spent in three places. On a well-configured socket bridge: signal detection inside OnTradeTransaction costs under 5 ms; the transmit hop across the IPC channel costs 20 to 80 ms depending on framing and queue depth; the slave's CTrade submission to the broker costs 5 to 20 ms — roughly 30 to 105 ms total from master fill to slave order submitted.
What moves the needle is not shaving the IPC channel — it is placement. Master and slave terminals should live on the same VPS, and that VPS should sit in the same datacenter as the brokers' trade servers. A London VPS copying to a London-based broker adds 1 to 3 ms per network hop; a home PC adds 50 to 200 ms of residential jitter before the pipeline even starts.
Context matters more than absolute numbers. A daily swing copier can absorb 200 ms without any measurable difference; a gold scalper copying 15-pip targets can lose a quarter of its edge to 80 ms of drift. Decide the architecture from the strategy's holding period, not from the marketing sheet.
Synchronizing the Hard Parts
Copying an entry is easy. Keeping the slave's state proportional to the master's across every event type is where copiers earn their price — or lose the client money.
- Partial closes. When the master closes 40% of a position, the slave must close the same 40% — not the whole position. The event carries the volume in
DEAL_ENTRY_OUT, so the slave scales the fraction and leaves the remainder running with the same stop and target. - SL/TP modifications. A stop moved from -30 to -15 pips on the master must land at -15 pips on the slave, normalized to the slave's symbol point size. Copying the raw price is a classic bug when the two brokers quote different digits.
- Pending orders. Buy stops and sell limits have lifetimes. The copier must mirror placement, modification and expiry — and cancel the slave-side order when the master cancels.
- Symbol suffixes and aliases. EURUSD on the master may be EURUSD.a on the slave, XAUUSD may be GOLD, and indices may carry prefixes. A mapping table normalizes the master symbol and re-derives the slave symbol per broker — plus a quarantine for symbols the slave does not offer.
- Lot scaling and inverse copying. Scaling by balance ratio or fixed multiplier is standard; inverse copying flips buy to sell for hedged pairs of accounts. Both must respect the slave broker's lot step, min and max — a 0.013 lot on a 0.01-step broker gets rounded down, logged, and reported, not silently skipped.
- Orphaned position recovery. If the slave misses an event — a restart, a disconnect, a rejected fill — the two sides drift. On startup the copier reconciles: every open master position must have a matching slave position within tolerance, and every mismatch is logged and flagged for repair. This is the feature cheap copiers do not have.
Risk Controls That Must Be Built In
A copier is an execution amplifier — every mistake is multiplied by the number of slave accounts. The risk layer is not optional:
- Max lot per trade — hard ceiling, enforced before submission, independent of the scaling math.
- Max concurrent positions — a runaway master cannot stuff the slave with a hundred grids.
- Equity stop — if the slave's floating equity loss crosses a threshold, the copier stops opening new copies and optionally flattens.
- Friday auto-close — everything flat before the weekend gap risk, per account, at a configurable time.
- Desync notification — any reconciliation failure pushes an alert immediately; silent drift between master and slave is worse than a loud failure.
Failures We Have Seen
Every failure below came from a real client account before we rebuilt the copier. The common thread: polling instead of events.
- Missed partial closes. A polling copier samples open positions every 500 ms. It sees the volume change after a partial close but cannot distinguish it from a full close plus a new entry, so it guesses — usually wrong. The slave ends up with a full position where the master holds 40%.
- Orphaned slaves. A disconnect during an entry event. The event is gone forever, the master has a position, the slave has nothing, and nothing ever reconciles it. Days later the trader finds half his accounts flat.
- Double-copies from polling loops. The polling timer fires, sees a position it has not recorded, copies it — then the next poll runs before the record updates and copies it again. Two positions, double risk, and a margin call on the small account.
Transaction-event tracking beats polling for one structural reason: every fill generates exactly one OnTradeTransaction event with a unique deal ticket. You process it once, record it, move on. Polling has to infer events from ambiguous state snapshots.
Case Study: The Free AlgoSpecial MT5 Copier
We ship a production copier for free — the MT5 trade copier — and it is built on the same architecture described above: OnTradeTransaction on the master, reconciliation on startup, and a risk layer with per-trade risk limits, trailing stops on copied positions, and Friday auto-close so slave accounts finish the week flat.
Two architecture choices mattered. First, local-first design: the copier lives inside the terminals rather than behind a remote server, which keeps latency under 100 ms on a co-located VPS and keeps trade data out of anyone else's infrastructure. Second, reconciliation-as-first-class-feature: every startup compares master and slave state before copying anything new — the part that prevents orphaned positions.
Why free? Because a copier is infrastructure, and infrastructure is the best advertisement for how we engineer the paid work — the custom EAs, the prop-firm hardening, the migrations we deliver when clients hire MQL4/MQL5 developers for systems bigger than off-the-shelf tools.
Frequently Asked Questions
How does an MT5 trade copier work?
A copier watches the master account's trade events through OnTradeTransaction, filters each event against the copy rules, then transmits the decision to the slave account where CTrade executes it. Proper copiers react to events, while cheap ones poll open positions on a timer and guess what changed.
What latency should a good copier have?
Local copy inside one terminal: under 10 milliseconds. Socket bridge between two terminals on the same VPS: 20 to 80 milliseconds. Cloud relay across locations: 80 to 300 milliseconds. The most important latency decision is not the architecture — it is co-locating master and slave terminals in the same datacenter as the broker servers.
Can a copier copy partial closes?
Yes — an event-driven copier sees DEAL_ENTRY_OUT transactions with partial volumes and can scale the same fraction to the slave position, keeping both sides proportional. Polling-based copiers usually miss this entirely, because the position volume after a partial close looks like any other position change.
How do I copy trades to accounts with different symbol suffixes?
With a suffix-mapping table. The copier normalizes the master symbol (for example EURUSD), then appends the slave broker's suffix to produce EURUSD.a, EURUSDx or whatever the slave uses. The mapping must also translate currency symbols like XAUUSD to GOLD and handle brokers where indices carry prefixes.
Is a local copier better than a cloud copier?
For personal multi-account setups, yes — local or socket-bridge copiers are faster, cheaper and do not hand your trade data to a third-party server. Cloud relay copiers earn their complexity only when you are copying across locations or selling signals to external subscribers.
Build Your Copier on Events, Not Guesses
If your copier misses partial closes or leaves orphaned positions, the problem is architectural, not configurational. Start with our free copier — or tell us what it does not do and we will engineer it properly.