Trade Copier Latency:
Routing, Acceptance and Fill Time

Trade copier latency is not one universal number. A copied action passes through several observable stages: the source event is detected, routing rules are applied, a destination request is submitted, the destination responds, and the order may later fill partly or completely. Each stage needs its own endpoints and evidence.

The owner reports TradeCopier routing latency of 10–15 ms. A public dated result dataset has not been released, so this is a team-reported range rather than an independently verified benchmark. It does not describe broker acknowledgement, first-fill time, complete-fill time or an end-to-end guarantee.

Separate routing, acceptance and execution

MetaQuotes explains that a successful OrderSend return is not itself proof of execution. Its OnTradeTransaction documentation shows that one request can produce several later events whose arrival priority is not guaranteed. cTrader’s Open API messages likewise distinguish accepted, partly filled, filled, rejected and other outcomes. These platform examples support the stage distinction; they do not prove a TradeCopier timing result.

Define the endpoints before measuring

A timing value is interpretable only when its start and end events are named. “From master trade to slave execution” can combine source-platform observation, copier processing, network travel, broker handling and market fill conditions. Changing either endpoint changes the statistic.

For a routing measurement, record when the collector first observes an eligible source event and when it hands the destination request to the connector. For an acceptance measurement, record when documented acceptance evidence reaches the collector. For fill timing, reconcile execution records rather than inferring a fill from a returned request.

The prospective execution-quality study methodology defines event codes, denominators, clock rules, exclusions, percentiles and a versioned template pack. It currently contains no product measurements.

Use compatible clocks and state their uncertainty

Use a monotonic clock for elapsed intervals inside one process or clock domain. Use an unambiguous UTC representation for chronology; RFC 3339 defines an Internet date-time format. Do not subtract timestamps from different machines unless their offset, synchronization and uncertainty are recorded.

NTP version 4 documents a network time protocol, but using NTP is not a promise of a fixed accuracy on every path. Store the producing clock, actual timestamp resolution, clock-domain ID, recent offset estimate, uncertainty estimate and synchronization sample time. More decimal places do not create more accuracy.

If the clock-quality gate fails, retain the order outcome and any valid same-clock interval. Mark the affected cross-system duration invalid instead of quietly publishing it.

Measure a distribution and keep failures visible

One average can hide a long tail. Report a named percentile method, valid sample count, missing count, minimum, median, eligible tail percentiles and maximum for each exact route stratum. Keep platform pair, connector version, broker or account alias, region, instrument, order type, quantity band, demo/live environment and observation dates with the result.

Rejected, timed-out, partly filled and unresolved attempts remain in reliability denominators even when they have no valid fill latency. Otherwise a report can appear faster simply by discarding the outcomes users most need to understand.

A passive limit order should not be pooled with a marketable order’s fill interval. Its placement or acceptance time can be measured, while the eventual fill depends on later market interaction. Similarly, demo and live observations belong in separate strata.

Do not treat price difference as a latency stopwatch

A follower price can differ from a source price because the two accounts see different executable quotes, spreads, liquidity, feeds, order rules, size, broker handling or market movement. Copier processing can contribute to elapsed time, but price difference alone cannot identify its cause.

Before calculating a difference, choose the reference: source-fill VWAP, destination ask for a buy or bid for a sell at arrival, or an order constraint such as a limit price. Preserve the reference timestamp and quote age. The slippage cost calculator demonstrates one declared reference-to-fill calculation, while the bid–ask spread and all-in cost calculator separates a same-instrument spread from entered commission, slippage and financing. Neither calculation proves that latency caused the result.

Diagnose the stage that changed

1. Confirm source eligibility. Was the source action observed, and did mapping, sizing or a filter deliberately exclude it?
2. Check submission evidence. Is there a destination request ID or connector record, and which software version produced it?
3. Read the destination state. Separate local call return, acceptance, rejection, working order and execution records.
4. Reconcile quantity. Add linked partial fills and compare resulting positions under the destination account model.
5. Inspect clocks. Verify timezone, clock domain, synchronization sample, offset and uncertainty before comparing timestamps.
6. Segment the incident. Compare like platform pairs, regions, instruments, order types and conditions instead of combining unlike routes.
7. Preserve unknown outcomes. A timeout is not a rejection. Check actual broker records before any supported recovery action.

The orders, deals and positions reference includes a generic reconciliation ledger for this investigation. TradeCopier’s activity-log page describes the product context for operational records.

What a credible latency statement must include

A public result should name the exact metric and endpoints, protocol version, software build, route matrix, broker/account aliases, demo or live environment, instruments, order types, quantity bands, regions, sample dates, stopping rule, valid and missing counts, failed and unresolved outcomes, clock uncertainty, exclusions and calculation code. The row-level dataset should be released in redacted form when permissions allow.

Lower measured routing time does not guarantee a fill price, lower slippage, profit or protection from loss. Results describe the tested versions, routes, conditions and period; they do not establish worldwide performance or every future market state.

For a linear Forex pair with known open and close fills, the linear Forex price-move P&L calculator can reproduce a result from explicit units, currency conversion and user-entered costs. Keep that arithmetic separate from any claim that latency caused the result.

Primary references

• MetaQuotes: OrderSend result semantics
• MetaQuotes: OnTradeTransaction event model
• cTrader Open API: model messages
• IETF RFC 3339: Date and Time on the Internet
• IETF RFC 5905: Network Time Protocol Version 4

Sources were checked on September 21, 2026. Platform behavior and documentation can change.