TradeAon · Guides · Copy reconciliation
Copy trading · Reference

When a Copy Signal Is Lost: How Reconciliation Repairs It

By the TradeAon team · Published · Updated · 8 min read

Any system that moves a trade from one account to another across the public internet has to answer the same question: what happens on the rare occasion the message does not arrive? The follower is left in a state nobody chose — holding a position the master has already closed, or missing one the master still holds — and neither announces itself. This page describes the background process that compares the two accounts and repairs the difference, and why repairing one of those two cases is much harder than the other.

Key takeaways
Contents
  1. What a lost signal actually leaves behind
  2. Identity: the ticket, not the comment
  3. Closing an orphan: the safe direction
  4. Opening a missing position: the dangerous direction
  5. Why we refused to auto-open at first, and what changed
  6. What reconciliation still cannot do for you

What a lost signal actually leaves behind

When a master account opens or closes a position, that event is turned into a command and delivered to each follower. Delivery is kept deliberately lean, because every extra step sits directly on the latency path a trade has to travel. The consequence of that design — true of any low-latency delivery path, not just this one — is that a delivery which does fail does not announce itself.

TradeAon copy trading history table showing copied trades alongside a failed copy and an orphaned close that was reconciled. Real product UI, sample data.
Real UI · sample dataThe copy history table as it ships: every row is one delivery attempt. The red rows are failures the follower rejected, and the orphan row is a master close with no mapped follower ticket — the case reconciliation exists to repair.

Deliveries fail for boring reasons: a network blip, a terminal restarting at the wrong moment, a connection dropping mid-trade. The result is one of two divergences, and the asymmetry between them is worth stating plainly:

What was lostState it leavesRisk
A closeFollower holds a position the master no longer has (an orphan)Unmanaged exposure — nothing will ever close it
An openFollower never opened a position the master holds (a miss)Follower silently stops mirroring the master

The orphan is the more dangerous of the two, because the position stays open and no future signal refers to it. The master's later close instruction names a position the follower does not have; the orphan keeps running with no stop rule attached to it, through weekends and news events, until a human notices.

Detecting either case requires the same thing: a periodic comparison of what the master actually holds against what the follower actually holds. Each terminal reports its open positions roughly every ten seconds, and that snapshot is what makes the comparison possible.

Identity: the ticket, not the comment

Before anything can be compared, each copied position needs an identity linking it to the master position it mirrors. The obvious mechanism is the trade comment — stamp the master's position id into the follower's order and read it back later. That is how this worked originally, and it broke.

It broke for two reasons that both come from outside our control. Brokers are free to rewrite a position's comment, and an MT5 partial close leaves the surviving position with an empty comment. Once the comment is gone the position becomes unreachable: the comment scan misses it, the position-sync filter skips it, and even reconciliation goes blind to it. The failure compounds — the mechanism meant to catch problems is defeated by the same event that caused one.

So identity is the broker ticket, which is assigned by the broker, is unique, and cannot be rewritten. The mapping between master position and follower ticket is held server-side: in memory for reads, with a local database for durability and a cloud copy for disaster recovery. Reads never touch a database at all, which keeps the hot path cheap. The comment is still written, but only as a fallback.

This is the sort of decision that looks like over-engineering until the day it does not. The rule it encodes is general: never build identity on a field that something else is allowed to modify.

Closing an orphan: the safe direction

Closing is the primary direction and the one that runs by default, because closing an orphan cannot make anything worse. If the position is genuinely orphaned it should not be open; if it was already closed a moment earlier, the close simply does nothing. The operation is idempotent, and it cannot enter the market.

"Safe" still does not mean unconditional. Three guards apply:

GuardWindowWhat it prevents
FreshnessMaster snapshot must be under 30 s oldA master that went offline looking like a master holding nothing — which would close every follower position at once
GraceOrphan must persist 15 sRacing a close that is merely in flight, producing a duplicate
DedupOne close per position per 60 sRe-enqueueing the same close every cycle while the first is still executing

The freshness guard is the important one, and it protects against a failure mode that is much worse than the problem being solved. A disconnected master reports no open positions. Without that check, "the master holds nothing" and "we cannot see the master" are the same input — and the system would respond to a master's dropped connection by liquidating every follower. The rule that avoids it is simple to state: absence of data is not data.

Opening a missing position: the dangerous direction

The opposite repair — the master holds a position the follower never opened — is a different proposition entirely, because it enters the market. A mistake here does not fail to act, it acts wrongly, and it costs money at a price of its own choosing.

It therefore inherits everything above and adds five more guards, each answering a specific way auto-opening can hurt:

That last one deserves emphasis, because bypassing it is the standard way this feature causes damage elsewhere. If the repair path skips the gates the normal path enforces, it can open a position your risk settings would have refused — and it does so at the least convenient moment, when something has already gone wrong.

Why we refused to auto-open at first, and what changed

The open direction was deliberately left out of the first version. The reasoning was that auto-opening risks double entry at a stale price, which is a real risk and remains the reason for the age cap and the longer grace window.

Leaving it out turned out to be worse. A close that goes missing eventually attracts attention — the position sits there, visibly wrong. An open that goes missing is invisible: nothing is on the follower account to look at, and the divergence quietly persists forever. The account is no longer mirroring its master and there is nothing on screen to say so.

What settled the argument was an incident rather than an argument. During an EA restart, a master position was dropped by the liveness check and stayed missing on the follower with nothing in the system able to detect it. The gap was found by manual comparison. That is the failure mode the open direction exists for, and it is why it was added with five guards rather than not added at all.

The trade-off is now explicit and worth stating for anyone evaluating a copy system: a repair mechanism that can only close is safer per action but leaves an entire class of failure permanently unhealed. Being unable to make a mistake is not the same as being correct.

What reconciliation still cannot do for you

Reconciliation is a safety net for delivery failures. It is not a guarantee that two accounts will match, and it is worth knowing exactly where its authority ends.

The practical habit that catches what remains is a comparison of open positions on both accounts at the end of the session, especially after any period where a terminal restarted or a connection dropped. Automation should shrink the number of times you need to check, not the importance of checking. The whole reason this component exists is that a difference between two accounts is invisible until someone compares them — and the same is true of the differences it cannot repair.

TradeAon is a technical automation tool, not financial advice. Trading involves substantial risk of loss. You are responsible for your own strategy, risk and capital.