The Copy Trading Latency Budget: Where Every Millisecond Actually Goes, End to End

Ask three copier vendors how fast their product is and you will get three different numbers, each presented as though it were the complete answer. It isn't. End to end copy trading latency, the time from a master account's order filling to a follower account's matching order being confirmed, is not one measurement. It is the sum of five distinct stages, running on different pieces of infrastructure, owned by different companies, each capable of varying independently of the others. Knowing where each millisecond actually goes, and which stages a copier vendor can genuinely influence, is the difference between judging a product on marketing copy and judging it on engineering reality.

What Is the Full Copy Trading Latency Chain?

Every copied trade passes through the same five stages in the same order, whether the underlying platform is MetaTrader, cTrader, a Rithmic connected futures platform, or something proprietary. First, the copier has to detect that the master's order actually filled. Second, its own software has to process that event: parse it, run it past risk rules, and work out what the follower's order should look like. Third, it has to build that order and transmit it to the follower's broker. Fourth, the follower's broker has to accept, route, and fill that order at its own exchange or liquidity provider. Fifth, a fill confirmation has to travel back so the copier can record it.

The split that matters most is ownership. Stages one, two, and three run on infrastructure the copier vendor builds, deploys, and can measure. Stage four runs entirely inside the follower's broker, on servers the copier vendor has never touched and never will. Stage five sits somewhere between the two. That ownership split, not raw speed, is the single most useful thing to understand before trusting any advertised latency figure, and it is the organizing idea behind everything that follows.

Stage 1: How Fast Does the Copier Detect the Master's Fill?

The clock starts the instant the master's order fills at its exchange or broker. The first variable is how the copier finds out. If the master's broker or platform pushes execution reports the moment they happen, over a webhook, a WebSocket stream, or a FIX execution report, the copier can react within a few milliseconds of the message arriving. If the copier instead polls a REST endpoint on a fixed schedule asking whether anything new has happened, detection latency is capped by how often it asks, not by how quickly the fill actually occurred. We have broken down the WebSocket, FIX, and REST polling tradeoffs in detail elsewhere, so the short version here is enough: push based detection is event driven and fast, polling is simpler to build and operate, and the gap between the two is a design choice, not something fixed by physics.

To put illustrative shape on it, not a measured figure, a push based execution report might reach a well built copier in roughly 1-5 ms after the exchange confirms the fill. A REST poll running once a second effectively adds up to roughly half a second of average wait on top of the fill itself, and up to a full second in the worst case, since the copier can only learn about it on its next scheduled check. If your master account runs on a Rithmic connected platform, how that feed structures and delivers execution reports is itself part of this stage, before the copier's own software is even involved.

Why Does Physical Distance Still Matter If Software Is Fast?

Even a perfectly optimized, push based pipeline runs into a floor that no amount of code can remove: the physical distance between the servers involved. Data does not move instantly, even over dedicated fiber. It travels at roughly 200,000,000 meters per second in optical fiber, about two thirds the speed of light in a vacuum, a consequence of fiber's refractive index of about 1.5, according to the widely used networking reference High Performance Browser Networking. Engineers commonly use a rule of thumb of about 5 microseconds of one way propagation delay per kilometer of fiber, which works out to roughly 0.01 ms of round trip delay per kilometer of separation between a trading server and the relevant exchange matching engine or broker gateway, before any switching, routing, or application processing is added on top.

That sounds trivial per kilometer, until you compute it over real distances. A server sitting 500 km from the relevant matching engine carries about 500 x 0.01 ms = 5.0 ms of pure propagation delay round trip. Move that same server to 50 km away and the propagation delay drops to 50 x 0.01 ms = 0.5 ms, a 4.5 ms difference from geography alone that no software optimization closes. The same physics scales linearly to much larger distances: the same source's reference table puts New York to London, 5,585 km apart, at about 28 ms one way and roughly 56 ms round trip, purely from the length of the cable.

This is why server placement is not a cosmetic detail. If the master platform's servers, the copier's own server, and the follower broker's gateway are not reasonably close to each other and to the exchange that ultimately matches the order, every single trade pays a physical tax that no amount of efficient code removes. It is also why institutional and prop trading desks pay to colocate, renting rack space physically inside or immediately next to an exchange's own data center. Market reporting on CME's Globex matching engine, which runs out of a CyrusOne data center facility west of Chicago, describes colocation rack pricing running into five figures per month, spent specifically to shrink propagation delay toward zero (verify current colocation pricing and rack availability directly with the exchange or data center operator, this article isn't quoting a fixed figure). Most retail and prop traders are not renting a data center rack, but the same lesson applies at a smaller scale: choosing and configuring a VPS that keeps you close to your broker's own servers is exactly the practical setup question covered in our VPS setup guide for futures copy trading.

Stage 2: What Happens Inside the Copier Before an Order Is Built?

Once the copier's software knows the master filled, there is still real work to do before it can act. It parses the raw event into a usable trade record: symbol, side, size, price, timestamp. It checks that trade against the follower account's own risk rules. Is this symbol on the whitelist for this account? Would copying this size push the follower over its position limit? Is the follower's connection to its own broker still alive, or did it silently drop earlier without anyone noticing? Only once those checks pass does the copier compute what the follower's order should actually look like, converting the master's size into the follower's size under whatever sizing method the account uses (fixed ratio, balance proportional, fixed lot, or something custom), and mapping the master's symbol to the follower's equivalent if the two run on different brokers or platforms.

None of that is expensive computation, a handful of comparisons and one multiplication, but it runs on a real server and sits squarely inside the copier vendor's own engineering. This is the stage where inefficient code, an overloaded server, or a risk engine doing unnecessary database round trips quietly adds milliseconds that have nothing to do with network transport. Illustratively, this stage might run 1-10 ms on a well built copier under normal load, more if the server is oversubscribed.

Stage 3: Building and Sending the Follower's Order

With the follower's order fully computed, the copier still has to turn it into a message the follower's broker API will actually accept, then get that message onto the wire. That means formatting the specific fields a given platform expects, MetaTrader's trade request structure is not cTrader's FIX message is not a REST JSON payload, and pushing it out over whatever connection the copier maintains to that broker. cTrader, for instance, offers a FIX API built specifically for this kind of machine to machine order traffic; Spotware, the platform's developer, describes its FIX API as available to any broker or trader without a minimum trading volume or minimum deposit size. Other platforms rely on proprietary APIs or REST endpoints with more overhead per message.

This stage sits entirely inside the copier's own engineering control. How efficiently it serializes the order message, whether it keeps a persistent authenticated session with the follower's broker versus reconnecting for every order, and how close its server physically sits to that broker's API endpoint all shape how long this takes. Illustratively, order construction and transmission might run 2-15 ms, driven mostly by connection type and, again, physical distance to the broker's own gateway.

Stage 4: Why Broker-Side Matching Is the Stage No Copier Controls

This is where the chain leaves the copier's hands entirely. Once the follower's order arrives at the follower's broker, everything that happens next, accepting the order, routing it internally or out to an exchange or liquidity provider, and matching it against available liquidity, happens inside that broker's own infrastructure, subject to that broker's own current load and the market's current liquidity and volatility. A copier vendor has no code running at this stage. It cannot speed it up, and it cannot honestly promise what it will do, because it does not own it.

This stage is also, by a wide margin, the most variable of the five. In a calm, liquid market with a broker running healthy infrastructure, order acceptance and fill might come back in a few tens of milliseconds. In a fast moving market, or with a broker whose systems are under strain, the same order can take an order of magnitude longer, or come back at a different price entirely. MetaTrader's own execution model makes this explicit: the platform defines several distinct execution modes at the symbol level, Instant, Request, Market, and, in MT5, Exchange execution, and under Instant execution the broker is permitted to return a requote, a different price than the one requested, instead of filling at all. Request execution carries its own version of the same delay: the platform first asks the broker for a price, and the broker then separately confirms or rejects filling at that price, an extra round trip before the order is even accepted. Neither behavior is network delay in the ordinary sense, it is the broker's dealing desk or liquidity provider declining or re-pricing the request, and it stacks its own variable delay on top of whatever the connection latency already was (confirm which execution mode your own account actually runs under with your broker, since it is broker configured and can change without notice).

A copier can only ever engineer the half of the chain it actually owns.

Stage 5: The Confirmation Round Trip

The last stage is easy to overlook because by the time it happens, the trade itself is already done, the follower's fill already exists at the broker. What is left is the confirmation message traveling back so the copier can update its own records, mark the position as active, and make that state visible in whatever dashboard or journal the trader is actually looking at. This leg depends partly on how quickly the follower's broker generates and sends the confirmation, which sits partly back inside stage four's uncontrolled territory, and partly on how efficiently the copier's own software receives and writes that confirmation, which is back inside the copier's control. Illustratively, this round trip might add another 2-20 ms, small next to stage four but not free.

A Worked Example: Adding Up a Full Latency Budget

Put illustrative numbers on all five stages and the shape of the whole chain becomes obvious: no single stage, and no single vendor decision, determines the total. Everything in the table below is an illustrative, order of magnitude example meant to show how the chain is structured, not a measured benchmark for Thor or any named vendor. Actual figures vary by broker, platform, account, network path, and real time market conditions, verify expected behavior with your own broker rather than assuming any of these numbers.

Summing the push based case: 3 + 5 + 8 + 50 + 10 = 76 ms total. Swap only stage one for the polling case, and the same chain becomes 500 + 5 + 8 + 50 + 10 = 573 ms total.

A few things fall out of that arithmetic that a single headline number would hide. Stages one through three, the entire footprint of the copier's own engineering and transport choice, add up to 3 + 5 + 8 = 16 ms in the push based case, out of a 76 ms total. Stage four alone, 50 ms in this calm market illustration and entirely outside the copier's control, is roughly two thirds of that same total by itself. And the single largest swing in the whole table does not come from stages two, three, four, or five at all, it comes from stage one's transport method: switching from push to poll adds 497 ms (500 ms minus 3 ms) to the total, more than three times the entire illustrative range of stage four (a spread of 140 ms, from 10 ms to 150 ms), itself the most variable of the remaining stages. The real lesson is not the specific numbers, it is that the biggest lever a copier vendor actually controls is detection method, not raw code speed, while the single largest number in the chain, stage four, is not a lever the vendor controls at all.

Why Is a Single Advertised Latency Number Almost Never the Full Story?

Given that, a vendor's headline claim of filling in some fixed number of milliseconds answers a narrower question than it sounds like. In practice, that number almost always measures only the piece the vendor controls, typically some slice of stages one through three, because that is the only part they can test and reproduce on their own infrastructure. It essentially never includes stage four, because no vendor can guarantee, or even consistently measure, how fast someone else's broker will accept and fill an order under someone else's market conditions. A number that reads "5 ms" and a number that reads "500 ms" can both be true statements from the same vendor about the same system, depending entirely on which stages got counted.

The useful question to ask a copier vendor is not how fast they are, it is which stages that number covers and where the measurement starts and stops. Does the clock start at exchange fill or at the moment the software receives the event? Does it stop at message sent, or at fill confirmed back at the follower? A vendor willing to answer that specifically is telling you something real about their engineering. A vendor whose marketing simply states one figure with no stage boundaries attached is asking for trust in a number that was true under one particular test, one particular network path, one particular quiet market minute, and probably will not hold up in the conditions that actually matter: a fast news release, a thin overnight session, or a follower broker having a bad day.

Three questions cut through most of this marketing. Was the figure measured on the vendor's own production infrastructure under live trading conditions, or on a bench test with a synthetic follower and no real market behind it, since the two can differ by an order of magnitude? Is it an average, a median, or a best case pulled from a quiet session, given that latency in a trading system is rarely symmetric and a handful of slow outliers during a volatile minute can matter more to an account than the typical case ever does? And what happens to it around high volume moments, a data release, a session open or close, a fast market, since that is exactly when a slow stage four gets expensive and an averaged marketing figure says the least?

This is also a reason to question whether a copier is even the right layer to fix a latency problem. If a follower account sits with a broker whose order acceptance and fill process is consistently slow, no copier changes that outcome, however well engineered its own three controllable stages are. The fix in that situation is a broker or account change on the follower side, not a faster copier. A copier's real, honest job is narrower than the marketing usually suggests: detect fills quickly, check risk cheaply, get the order out the door fast, and sit close enough to the relevant infrastructure that physical distance is not adding avoidable milliseconds. What happens after the order leaves the copier's hands belongs to a different piece of infrastructure entirely.

Frequently asked questions