How to Design a Reproducible Trade Execution Quality Study

What an execution-quality study measures

A copied-trade execution-quality study observes one eligible source action and the evidence produced as that action moves toward one destination account. It asks whether a destination request was submitted, what state the destination reported, whether any quantity filled, how long separately defined stages took, and how destination quantity and price compared with predeclared references.

The study cannot prove profitability, future fills or broker superiority. Client-observed timestamps also cannot reveal every internal broker or venue stage. A slower observed interval can coexist with a better price, while a fast route can still meet a rejection, unavailable liquidity or a different destination quote. The protocol therefore reports timing, outcomes, price differences and data completeness separately.

The owner has reported TradeCopier routing latency of 10–15 ms. No public dated dataset currently defines that figure’s endpoints, route mix, sample size, clocks, exclusions or percentile. It is not a result under this protocol and must remain separate from broker acknowledgement and fill time.

Define the event boundary before collecting data

The word observed is deliberate. Unless a provider timestamp is stored and labeled separately, an event time means the collector received evidence of that event. A successful request call is not the same as a fill. MetaQuotes states in its OrderSend documentation that a successful return does not itself mean a trade was executed. Its OnTradeTransaction documentation also describes multiple later transactions and warns that arrival priority is not guaranteed.

Protocol v1.0 event boundaries

Code	Recorded event	Meaning
T0	source_event_observed	The instrumented collector first observes an eligible source event.
T1	route_processing_started	Normalization, mapping, sizing and policy evaluation begin.
T2	destination_submit_started	The destination request is handed to the connector or API.
T3	destination_submit_returned	The local connector or API call returns; this is not automatically acceptance or execution.
T4	destination_acceptance_observed	A documented accepted or placed state is observed.
T5	destination_first_fill_observed	The first destination execution record is observed.
T6	destination_final_fill_observed	Cumulative filled quantity reaches the protocol’s requested-quantity definition.
TX	terminal_outcome_observed	A rejection, cancellation, expiry, timeout or unresolved reconciliation horizon is recorded.

Use platform-native order, deal and position identifiers as separate fields. MetaTrader’s basic trading principles distinguish those records. cTrader Open API model messages likewise expose distinct execution states and fields. The FIX order-state specification (PDF) provides another documented example of separate execution-report purpose, order status, execution identifiers and quantities such as cumulative, last and remaining quantity. Each connector version needs an explicit mapping to the normalized states above.

Freeze the study plan and sampling rule

Register the study before the observation window. Record a stable study ID, protocol version and file hash; start and end rules; software and connector versions; demo or live environment; route strata; order scenarios; reference-price rule; censor horizons; clock-quality gate; planned sample targets; exclusions; aggregation method; analysis-script version; redaction policy; and amendment procedure. A result-dependent stopping rule is not acceptable: do not stop because early results look favorable or extend only because a desired number was missed.

The primary observation unit is one destination route attempt: one eligible source action sent toward one configured destination account under one frozen configuration version. Use a copy-group ID to link all followers of one source action and a separate attempt ID for every destination. Multiple followers of one source event are correlated observations; extra rows do not make them independent tests.

Predeclare the dimensions that can materially change the result: source and destination platform and connector version, broker or account alias, demo or live environment, account model, route and region, instrument and contract, side, action, order type, time in force, requested quantity band, trading session, scheduled-news condition and software build. Do not pool unlike routes into one headline percentile merely to increase the sample.

Use clocks that answer the intended timing question

Store two time representations for locally observed events. Use RFC 3339 UTC for chronology and record inspection, following RFC 3339. Use a monotonic clock for elapsed intervals inside one process or clock domain. A trace ID can connect distributed events, as described by W3C Trace Context, but it is not a clock and does not make timestamps comparable.

For every clock domain, preserve the clock source, recorded resolution, synchronization method, most recent offset estimate, uncertainty estimate and sync-sample time. NTP version 4 describes a network time protocol; using NTP does not create a universal accuracy guarantee. Never describe nanosecond storage as nanosecond accuracy unless the complete measurement system supports that precision.

• Calculate a duration directly when both endpoints share a monotonic clock domain.
• For cross-host timestamps, publish the offset and uncertainty policy and invalidate the affected interval when the quality gate fails.
• If a wall clock steps, retain valid same-clock monotonic intervals and mark affected wall-clock differences invalid.
• Keep provider-origin timestamps in separate fields with their source and resolution; do not silently replace collector observations.
• Leave a missing endpoint blank. A missing response is not zero milliseconds and does not prove that nothing happened.

Calculate each latency stage separately

Elapsed metrics and their boundaries

Metric	Formula	Interpretation
Internal route	T2 − T0	Source-event observation through the start of destination submission.
Destination call	T3 − T2	Local connector/API call and its network path as observed by the collector.
Acceptance observation	T4 − T2	Time until accepted-state evidence reaches the collector.
First-fill observation	T5 − T2	Time until the first execution evidence is observed.
Complete-fill observation	T6 − T2	Time until cumulative execution reaches the declared requested quantity.
Source to first fill	T5 − T0	An observed end-to-end interval containing both software and destination stages.

internal_route_ms is the only candidate in this table for a narrowly worded copier-routing result, and only when T0 and T2 are truly instrumented. Destination acceptance, first fill and complete fill include other systems and market processes. Pending or passive orders belong in their own stratum because later fill time depends on market interaction; their placement and acceptance intervals can still be measured.

Keep every outcome in the reliability denominator

Latency observations and outcome counts answer different questions. A rejected or timed-out attempt may have no valid fill interval, but removing it from the study would hide reliability information. Report integer numerators and denominators for submission, acceptance, any fill, complete fill, rejection, partial fill, unresolved outcome, unintended duplicate and measurement completeness rates.

Outcome formulas

Rate	Numerator	Denominator
Submission rate	Submitted attempts	Eligible attempts
Acceptance rate	Accepted attempts	Submitted attempts
Any-fill rate	Attempts with at least one fill	Submitted attempts
Complete-fill rate	Attempts completely filled within the frozen horizon	Submitted attempts
Unresolved rate	Attempts unresolved at the reconciliation horizon	Submitted attempts
Measurement completeness	Attempts with all required primary fields	Eligible attempts

For a proportion, publish the numerator, denominator, percentage and interval method. The NIST handbook’s discussion of confidence intervals for proportions explains the Wilson construction, which avoids impossible negative or above-one bounds produced by a simple symmetric approximation.

Predeclare the price and quantity references

First calculate the destination volume-weighted average fill price: sum each fill price multiplied by its fill quantity, then divide by total filled quantity. For a buy, adverse price difference is positive when the destination price is higher; for a sell, it is positive when the destination price is lower.

Do not blend three different comparisons:

1. Source-fill reference: compare destination VWAP with source-fill VWAP and label the result source-to-follower fill divergence.
2. Destination-arrival reference: compare with the destination ask for a buy or bid for a sell captured immediately before submission, subject to the predeclared quote-age rule.
3. Order-constraint reference: compare with a limit, stop or stop-limit rule to test compliance with that instruction.

A midpoint is not an executable-side quote and must be labeled separately. If a money amount is derived, retain contract multiplier, currency, conversion pair, rate, provider and timestamp. Fill ratio is cumulative filled quantity divided by normalized requested quantity. Keep normalized destination quantity separate from original source quantity so symbol mapping and rounding do not disappear inside the comparison.

Declare censoring, exclusions and missing data

Freeze separate horizons for acceptance, first fill, completion and final reconciliation. At the horizon, classify the attempt by its last verified state instead of inventing a latency. Link retries to the original attempt and report instruction-level outcomes after allowed recovery separately from attempt-level outcomes.

Never remove a broker rejection, copier validation failure, rate limit, connection loss, timeout, partial fill, unresolved state, duplicate submission or large latency observation merely because it makes the result worse. Retain a screened row for corrupt telemetry, a proven duplicate record, an operator action outside the armed study and a scenario outside the frozen sampling frame. Missing quotes affect the price metric; unsynchronized clocks affect the corresponding cross-clock interval; a missing final fill affects completion latency. Those records can still contribute valid outcomes and other valid stages.

Every exclusion needs a code, factual reason, reviewer and UTC time. Do not impute missing timestamps, trim valid tail observations or silently convert nulls to zero in the primary analysis.

Report distributions with their sample counts

Protocol v1.0 uses the empirical nearest-rank definition for p50, p95 and p99. Sort the valid observations and choose the one-based value at rank ceil(p × n). Other quantile definitions can produce different results; R’s sample-quantile documentation shows why the selected method must be named.

A tail percentile from a tiny group is not decision-grade evidence. This protocol requires at least 20 valid observations in an exact stratum for a reportable median, 100 for p95 and 1,000 for p99. These are publication gates for this protocol, not universal statistical laws or guarantees of precision. If a gate is missed, report the count and say that the percentile was withheld.

Every table must show the route stratum, observation window, number of distinct test dates, protocol and software version, valid sample count, missing/excluded count, minimum, eligible percentiles, maximum and clock-quality rule. Do not lead with a combined “average execution speed.”

Publish a reproducible evidence package

Download the version 1.0 study-template pack. It contains a prospective manifest, CSV schemas for attempts, events, fills, quotes, clock samples and summaries, synthetic test vectors, a dependency-free percentile script, a change log and file checksums. The synthetic rows are calculation fixtures, not product evidence.

A future result release should include suitably redacted row-level data, a data dictionary, frozen manifest, calculation code, expected outputs, checksums, amendments and deviations. Use aliases rather than logins; exclude credentials, access tokens, private keys and personal information. Do not label a first-party study independent unless an identified external party actually designed, ran or audited it and that role is disclosed.

Limit the conclusion to the measured system

Any later finding applies only to the named software versions, routes, accounts, platforms, regions, instruments, quantities, sessions, environments and dates. Demo results do not establish live execution quality. Small-order tests do not establish outcomes for larger sizes. A client-observed destination response is not every internal broker stage. Uptime needs a separate continuous-availability methodology and cannot be inferred from an order sample.

Price divergence can reflect market movement, feeds, spreads, liquidity, order size, order rules, broker behavior, network delay or copier processing. Lower routing latency does not guarantee less slippage, a fill, a trading return or protection from loss. The responsible conclusion is a bounded description of what was observed, including what could not be measured.

Primary references used for protocol v1.0

• IETF RFC 3339: Date and Time on the Internet
• IETF RFC 5905: Network Time Protocol Version 4
• W3C Trace Context
• MetaTrader 5: orders, deals and positions
• MetaQuotes: OrderSend result semantics
• MetaQuotes: OnTradeTransaction event model
• cTrader Open API model messages
• FIX Trading Community: FIX Latest as of EP284 — order state changes (PDF)
• R: sample quantiles
• NIST: confidence intervals for proportions

Sources were checked on September 21, 2026. Platform behavior and documentation can change; preserve the version and check date used for a real study.