Data Flow and Execution Speed in Copy Trading: Where the Time Goes

A copier's marketing page says 200 milliseconds. A trader runs it, times a trade with a stopwatch on two screens, and gets something closer to a second and a half. Both are true. They are measuring different parts of the same chain.

Execution speed in copy trading is not one number. It is a sequence of hand-offs, and if you cannot name them you cannot tell whether the delay you are experiencing is the copier's fault, your broker's, or physics.

The chain, named

There are two chains depending on what you are copying from.

Account to account:

 1  provider's broker fills the order
 2  something on the provider side notices          ← terminal tick or API event
 3  the event reaches the engine                    ← network
 4  the engine reconciles and applies the policy    ← compute
 5  the order reaches the follower's broker         ← network
 6  the follower's broker fills it                  ← broker execution

Channel to account:

 1  the provider types and sends the message
 2  the platform delivers it                        ← not yours to control
 3  the copier classifies it as a signal
 4  the copier parses symbol, direction, stop, targets
 5  the copier maps the symbol and sizes the trade
 6  the order reaches your broker                   ← network
 7  your broker fills it                            ← broker execution

In both chains, steps that belong to the copier are a minority of the elapsed time on a typical retail setup. Steps 1 and 6 in the first chain, and 2 and 7 in the second, belong to brokers and to a messaging platform. They are usually the largest contributors and they are the ones no vendor can honestly promise anything about.

Step 2 is the one nobody talks about

In the account-to-account chain, the second step is where most of the avoidable delay hides, and it is a design choice rather than a law of nature.

A copier running as a MetaTrader expert advisor typically does its work in OnTick — the function the terminal calls when a new price arrives for the chart's symbol. That is fine on EURUSD during London. It is not fine on a quiet instrument at 02:00, where ticks can be seconds apart. The provider's position changed the moment it was filled; the expert advisor does not find out until the next tick on its chart, which may have nothing to do with the symbol that was traded.

The fixes are well known and their absence is diagnostic:

• Run on a timer (OnTimer) rather than purely on ticks, so the observation interval is a number you chose rather than a property of the market.
• Watch the whole account, not one chart's symbol.
• Prefer a platform event or API callback where the platform provides one, and keep the timer as the backstop.

What a vendor's number actually measures

"200 ms" is a real measurement of something. The question is which segment. Common answers, in descending order of usefulness to you:

1. 01End to end, provider fill to follower fill, measured on live accounts at two named brokers. This is the number you care about and it is rarely the one published.
2. 02Engine-internal, from event received to order dispatched. Genuinely useful for comparing engines and completely silent about your experience.
3. 03Bench conditions — two accounts at the same broker, on the same VPS, in the same data centre, on EURUSD during London. Flattering and not reproducible at home.

None of this is dishonest, but averages hide the part that hurts. A copier with a 150 millisecond median and a two-second ninety-ninth percentile will feel slow exactly when it matters, because the tail events cluster around news, rollover and volatility — the moments when price is moving fastest.

What to ask for instead of a headline figure: a timestamped audit trail per copy, with at least four stamps — observed, decided, sent, confirmed. With those four you can compute every segment yourself on your own accounts and stop arguing about somebody else's benchmark.

What 200 milliseconds is worth

The honest answer is that it depends entirely on the instrument and the moment, and any vendor quoting you a universal cost of delay is guessing.

The frame that works is to convert time into price rather than debating time. Take an instrument you actually trade, sit with a chart, and ask: in a fifth of a second, how far does this typically move during the sessions I trade, and how far does it move in the first two seconds after a scheduled release?

For most major pairs in a normal session, the answer to the first question is a small fraction of a pip — genuinely negligible against a twenty or forty pip stop. The answer to the second question, on the same instrument, can be tens of pips. The same 200 milliseconds is worth almost nothing most of the time and a great deal for a few seconds a day.

That gives you the actual decision, which is not "how fast is the copier" but:

• If your trades are held for hours and entered away from releases, latency is close to irrelevant and you should spend your attention on sizing and filters instead.
• If your trades are scalps on gold or indices, or are frequently entered near releases, latency matters a lot — and so does the fact that it is variable, because the worst-case delay is what sets your worst-case fill.

Why a slippage limit beats raw speed

Here is the asymmetry that settles the argument.

Without a slippage limit, the cost of delay is unbounded. Whatever the price has done by the time your order arrives, you take it. A two-second delay through a release can hand you a fill twenty pips from the one the provider got, on a trade whose stop is thirty pips away, and the trade is broken before it starts.

With a slippage limit, the cost of delay is capped and converted into a skip. You define the maximum deviation you will accept from the provider's price. If the market has moved further, the copy is refused and logged. You lose the trade; you do not lose a trade at a price that makes no sense.

Three settings do this work, and they are worth more attention than the speed figure:

• Maximum deviation from the provider's fill. Expressed in points or as a fraction of the stop distance. The second version is better, because a five-point deviation means something different on a twelve-point stop than on an eighty-point one.
• Maximum spread at the moment of copy. Protects against the destination broker's overnight widening, which has nothing to do with the copier and everything to do with when the provider traded.
• Maximum age of the originating event. If a copy could not be placed within a few seconds, placing it late is usually worse than not placing it. A stale copy is a new trade wearing an old trade's clothes.

All three must produce a visible, reasoned skip. A slippage limit that silently drops trades is indistinguishable from an outage.

Requotes, partial fills and the things that are not latency

A few adjacent problems that get blamed on speed.

Requotes. Some account types respond to a market order by offering a new price rather than filling. The copier has to decide whether to accept within a tolerance or to abandon, and it needs to tell you which it did.

Partial fills. A larger volume can fill in pieces at different prices, or partially. The follower's position is then not the size the policy computed, and the engine must reconcile to reality rather than to intent — recording the actual filled volume and sizing subsequent partial closes against it.

Broker execution model. On instant execution the order is either filled at your price or requoted. On market execution it is filled at whatever is available. Two accounts on different models will show different apparent slippage on identical copies, and no amount of copier speed changes that.

Symbol trading hours. A provider trading an instrument with a wider session than your broker offers produces copies that are refused because the market is closed. That is a calendar problem, not a latency problem, and it should be logged as one.

Measure your own, in an afternoon

You do not need a laboratory.

1. 01Pick the instrument you actually trade most.
2. 02Over a normal week, pull the copier's audit trail and compute the four segments — observe, decide, send, confirm — for every copy.
3. 03Look at the median and the worst 1 percent, separately, for each segment. The segment with the worst tail is your bottleneck.
4. 04Separately, compare the provider's fill price with each follower's fill price on every copy, and express the difference in points and as a percentage of that trade's stop distance. That number is the actual cost of your latency, and it is the only one that appears in your account statement.
5. 05Repeat the exercise for the half hour around one scheduled release, and compare.

If step 4 is uncomfortable, the fix is more likely to be a tighter deviation limit and a news filter than a faster copier.

Where this fits

The engine design that determines how much of this chain the copier controls — and why a reconcile loop degrades to slow rather than to wrong — is in /blog/trade-replication-engine-explained. For reading the resulting skips, held copies and per-destination settings at a glance rather than in a log file, see /blog/cockpit-copy-trading.