Every trade copier has to answer one unglamorous question before it does anything clever: how does it find out that the master account just got filled? That answer comes down to a transport, the plumbing that moves quote updates, order acknowledgments, and fill events between a trading platform's server and whatever software is watching it. There are three transports you'll run into again and again: WebSocket, FIX, and REST. Each one has a genuinely different latency shape, not just a different acronym, and that shape determines whether a copier's speed is bounded by design or bounded by a clock.
This isn't abstract plumbing trivia. If you're evaluating a copier, or building your own bridge against a platform's API, the transport it uses to detect a master's fill is one of the first things worth checking, because it tells you upfront what the theoretical floor on latency looks like before you've tested a single trade.
WebSocket: push-based streaming
WebSocket is a protocol standardized in RFC 6455. It starts as a normal HTTP request, then the server responds with a status code 101 ("Switching Protocols") and the connection upgrades into a persistent, full-duplex TCP socket. Once that handshake completes, either side can send data whenever it wants, without re-establishing a connection and without the request/response ceremony that HTTP normally requires.
That persistence is the entire point. Because the pipe stays open, a server can push a new quote tick or a fill notification to the client the instant it happens. The client isn't asking "did anything happen yet?" on a loop, it's just sitting there listening, and the server talks when it has something to say. That's why WebSocket (and webhook-style push designs that behave similarly) is the backbone of most real-time market data feeds and order-update streams. It's also the shape of transport a copier needs if it wants same-tick reaction to a master's fill, a topic covered in more depth in the breakdown of level 1 vs level 2 market data, since the way you receive quote updates and the way you receive fill updates are often built on the same underlying streaming connection.
The catch is that a persistent connection cuts both ways. A connection that stays open for hours also has to survive network hiccups, load balancer timeouts, and the occasional dropped packet. That means the client side has to handle reconnect logic, heartbeats or keepalive pings to detect a stalled link before it goes fully dark, and gap detection so that if the connection drops for three seconds, you know you missed something and can resynchronize rather than silently trading on stale state. None of that is optional. A WebSocket client that doesn't handle reconnection and gap detection is a copier that quietly stops copying the moment the connection blips, and you might not notice until you compare account balances after the session closes.
FIX: the institutional standard
FIX (Financial Information eXchange) predates all of this by decades. It was originally put together in 1992 by Robert Lamoureux and Chris Morstatt so that Fidelity Investments and Salomon Brothers could exchange equity trading data electronically instead of over the phone. It has since grown well past equities to cover futures, options, fixed income, and FX, and it's the protocol that sits underneath a huge amount of order routing between institutional order management systems, FCMs, and exchanges.
FIX is session-oriented rather than stateless. When two parties connect, each side maintains its own outgoing and incoming sequence number series, starting at 1, and every message increments that count. If a gap shows up in the sequence, either side knows immediately that a message was missed and can request a resend, a far more rigorous integrity guarantee than assuming nothing happened. FIX sessions also exchange a Heartbeat message at an interval both sides agree on during logon (the HeartBtInt field), so a connection that's gone quiet for longer than expected gets flagged as dead rather than assumed idle.
FIX doesn't just move messages, it counts them, which is exactly why it's trusted with order flow that has to survive being audited.
On the broker or FCM side, a FIX gateway typically authenticates each incoming session, checks orders against risk limits, routes them into the matching engine, and returns ExecutionReport messages as fills occur. That's a lot of infrastructure, and it shows in how FIX feels to work with: heavy, verbose, and unforgiving of implementation mistakes, but battle-tested across an enormous volume of institutional order flow for a very long time. If you're reading about how a data feed like Rithmic gets order flow to a futures FCM, FIX or a FIX-adjacent gateway is very often part of that path somewhere upstream (Rithmic itself publishes a dedicated FIX API alongside its own protocol buffer API), even when the retail-facing API you actually touch looks nothing like raw FIX.
For most individual funded traders, direct FIX access isn't practical or even available. It's built for firms running order management systems against multiple counterparties, not for a single trader with one or two funded accounts. Where FIX matters to you as a retail trader is usually one layer removed: it's part of why your broker's order routing is reliable, not something you're plugging into directly.
REST: simple but stateless
REST APIs are the most familiar transport to anyone who's touched web development, and for good reason: a request goes out over HTTP, a response comes back, and that's the whole transaction. Each call is stateless and stands alone. That simplicity is exactly why REST is fine, even good, for account balance checks, historical queries, or placing a single order on demand.
The problem shows up when you need to know about something the instant it happens rather than the instant you ask. A stateless request/response model has no built-in way for the server to tell the client something changed unprompted. There's no push. So if a copier is watching a master account through a plain REST endpoint, the only option is to poll it: call the endpoint on a fixed interval, compare the response to what you saw last time, and see if anything's new.
That polling loop is where a structural latency floor gets baked in, no matter how fast your code runs afterward.
Here's the shape of it, using an illustrative example rather than a benchmark of any real product. Say a copier polls a master account's REST endpoint every 250 milliseconds to check for new fills. Now imagine the master's order fills just 1 millisecond after a poll has already come back empty. The copier has no way to know that. It's committed to waiting for the next scheduled poll, which fires 250ms minus that 1ms, or 249ms, later. That's the worst case: a fill that lands right after a poll sits undetected for close to the entire polling interval, and that's before any processing time or order transmission time gets added on top.
The average case is better but still structural. If a fill can land at any random point inside that 250ms window with equal probability, the expected detection delay is half the interval: 250ms divided by 2 is 125ms. That's not a bug or a bad implementation, it's just what a uniform polling gap does to detection time on average. Tightening the interval helps (polling every 50ms instead of 250ms cuts the worst case to roughly 49ms), but it doesn't remove the gap, it only shrinks it, and tighter polling means more API calls, which platforms rate-limit for exactly this reason.
Now compare that to a push-based design, whether that's a native WebSocket stream or a webhook that fires on the fill event. There's no interval to wait out at all. The only delay left is network transit plus whatever local processing the copier does, and on a stable connection those are commonly single-digit to low double-digit milliseconds combined. Put the two side by side, illustratively: a 249ms worst case under polling versus a single-digit-millisecond figure under push is roughly a 25x to 50x reduction in the detection-latency floor alone, not counting whatever order-transmission time both designs share equally downstream. That gap exists purely because of how the two transports learn about new events, before either one has sent a single order.
| Transport | How it detects a fill | Latency shape | Engineering cost |
|---|---|---|---|
| WebSocket / webhook push | Server notifies client the instant the event fires | Bounded by network and processing (illustrative: single-digit to low double-digit ms) | High: reconnect logic, heartbeats, gap detection required |
| REST polling | Client asks on a fixed interval and compares to last response | Bounded by poll interval (illustrative: up to about 249ms worst case on a 250ms interval, about 125ms average) | Low: simple request/response, easy to implement and debug |
| FIX | Session-based ExecutionReport messages with sequence numbers | Fast and reliable, built for institutional order flow | Very high: session management, sequence recovery, mostly inaccessible to individual retail setups |
Push designs are latency-bounded by network and processing time. Polling designs are latency-bounded by the interval you chose, structurally, no matter how well the rest of the code is written.
Why most platforms hide their own protocol
Here's a wrinkle worth knowing before you assume any given platform maps cleanly onto one of these three categories: most retail trading platforms don't actually expose raw REST or standard FIX to you. MetaTrader's Expert Advisor framework, cTrader's Open API, and Interactive Brokers' TWS API are all proprietary interfaces, built by that vendor, for that platform, following its own conventions. Some of these platforms also offer a REST, WebSocket, or FIX gateway alongside their proprietary interface for specific use cases (cTrader, for instance, publishes a separate FIX API and REST endpoints in addition to its Open API), but the primary way most retail software talks to the platform is through that platform's own SDK.
That matters for anyone building or evaluating a copier, because whether it uses WebSocket or REST isn't always a clean either/or question. A platform's proprietary protocol might behave like a WebSocket stream under the hood (persistent connection, server-initiated push) or it might behave like polling dressed up in a nicer SDK. The only way to know for certain is to check that platform's own API documentation rather than assume based on what the vendor's marketing page implies. If you're speccing out infrastructure to run a copier reliably against whatever transport a platform actually uses, the considerations in setting up a VPS for futures copy trading apply regardless of which transport is underneath, since a push connection that drops because your VPS lost network for four seconds needs the same reconnect and gap-detection discipline either way.
The honest tradeoff
None of these three transports is simply the best one. Each trades something real for something else.
Push-based designs (WebSocket streams, webhooks) are fast by construction, but they're genuinely harder to build correctly. A polling loop that misses a beat just tries again 250ms later and mostly self-corrects. A WebSocket client that mishandles a dropped connection can sit there silently disconnected, convinced it's still listening, while the master account keeps trading without it. Getting push architectures right means investing in reconnect logic, heartbeat monitoring, and sequence or gap detection on reconnect, none of which is optional if you actually want the latency benefit to hold up during a bad network day rather than just during a clean demo.
REST polling is the opposite trade. It's simple to implement, easy to debug, and forgiving when things go wrong, since every call is independent and a missed one doesn't cascade. But it has a latency floor baked into its shape: tightening the poll interval buys you speed at the cost of more API calls and more exposure to rate limits, and you can never fully close the gap between the event happening and the interval firing again. For account balance checks or placing an occasional manual order, that's a complete non-issue. For copying a fast scalping strategy across funded accounts, it's the difference between a copy that lands on the same bar and one that lands noticeably behind.
FIX is the institutional gold standard for order routing precisely because of its sequence numbers, heartbeats, and formalized session recovery, but it's overkill, and usually inaccessible, for an individual trader running a funded account or two. You're not going to stand up a FIX session with your prop firm's FCM as a retail user, and you generally shouldn't need to. That level of rigor is doing its job one or two layers upstream of where you interact with the platform.
It's also worth being honest about where transport latency actually matters versus where it doesn't. On a slower-moving swing position, the difference between a 5ms push notification and a 125ms average polling delay is not going to change your outcome. On a fast scalp, it can. Take a simple, stable reference point: CME's E-mini S&P 500 (ES) contract has a multiplier of $50 per index point, a specification that's been stable for a long time (always confirm current contract specs on cmegroup.com, since exchanges do occasionally revise terms). A 3-point adverse move on 2 contracts is 3 x $50 x 2 = $300 of P&L impact, and that number has nothing to do with transport, it's just what a 3-point move costs on that size. The point isn't that polling delay directly causes a specific dollar loss, it's that on instruments where price can move several points in a couple hundred milliseconds during active periods, the gap between a copier that reacts in single-digit milliseconds and one that reacts up to a quarter-second later is exactly the kind of thing that shows up as slippage between the master's fill price and the follower's fill price, especially during fast tape.
What to actually ask a copier vendor
All of this collapses into one practical question when you're evaluating a copier, whether that's Thor or anything else: what transport does it use to detect that the master account got filled? If the answer is that it calls the platform's API on an interval, ask what that interval is, and understand that your worst-case detection delay sits somewhere close to that full interval, before any order transmission time gets added. If the answer involves a persistent stream or webhook, the follow-up question is what happens when that connection drops, because a push architecture that silently fails open is worse than a slow polling loop that never stops.
Neither answer makes a copier bad. A polling-based design can be entirely appropriate for slower strategies or for platforms that simply don't expose a push interface at all. But the answer tells you upfront whether the copier's speed is bounded by engineering (network and processing time, which can be optimized and monitored) or bounded by a clock (a polling interval, which has a hard floor no matter how good the rest of the code is). That's a fundamentally different guarantee, and it's one you can ask about in a single sentence before you ever fund an account behind it.
Frequently asked questions
What's the difference between WebSocket, FIX, and REST for a trade copier?
WebSocket keeps a persistent connection open so the server can push fill and quote updates the instant they happen. FIX is the decades-old, session-based institutional standard for order routing, built around sequence numbers and heartbeats for reliability. REST is simple stateless request and response over HTTP that works fine for one-off queries but requires polling on an interval to detect new events like fills, which adds a structural latency floor. Which one a platform uses under the hood determines whether a copier built against it reacts instantly or waits on a clock.
Why does polling add latency to a trade copier?
Polling adds latency because a REST endpoint only answers when asked, so a copier has to check on a fixed interval and wait for the next scheduled check to notice anything new. In the worst case, a fill that lands right after a poll returns sits undetected for close to the full interval before the next poll fires. On average, with events landing randomly inside the window, the expected delay is about half the polling interval. That gap exists before any order processing or transmission time is even added.
Is WebSocket always faster than REST for trading data?
For detecting new events like fills, yes. A push-based WebSocket or webhook design reacts as soon as the event occurs rather than waiting for a poll to fire, so its latency floor is set by network and processing time instead of a fixed interval. For one-off actions like checking an account balance or placing a single order, REST works fine and the speed difference doesn't matter. The gap only becomes meaningful when you need to detect and react to an event you didn't initiate yourself.
Do retail trading platforms actually use FIX or REST?
Most retail platforms use their own proprietary protocol or SDK rather than raw REST or standard FIX, even though some also offer a REST, WebSocket, or FIX gateway for specific purposes alongside it. MetaTrader's Expert Advisor framework, cTrader's Open API, and Interactive Brokers' TWS API are all examples of proprietary interfaces built specifically for that platform. Always check the platform's own developer documentation to confirm what it actually exposes rather than assuming based on category.
Can an individual trader get direct FIX access to a broker?
Generally no. Direct FIX sessions are built for institutional order management systems connecting to multiple counterparties, not for a single trader with one or two funded accounts. FIX still matters to retail traders indirectly, since it's often part of the order routing infrastructure between an FCM and the exchange even when the retail-facing API looks nothing like raw FIX. For most individual setups, FIX access simply isn't offered or practical to implement.
How much difference does transport latency actually make when copying trades?
It depends heavily on the strategy and instrument. On slower-moving swing positions, the difference between single-digit-millisecond push latency and a polling delay of 100 to 250 milliseconds usually doesn't change the outcome. On fast scalping strategies in liquid futures like the ES, where price can move multiple points in a couple hundred milliseconds during active periods, that same gap can show up as measurable slippage between the master's fill price and the follower's fill price.
What should I ask a copier vendor about its architecture?
Ask what transport it uses to detect that the master account has been filled, whether that's a push-based stream or webhook, or a polling loop against a REST endpoint. If it's polling, ask what the interval is, since your worst-case detection delay sits close to that full interval before any transmission time. If it's push-based, ask what happens when the connection drops, since a push design that fails silently after a disconnect is a real risk that reconnect and gap-detection logic is meant to catch.
Is a faster transport always the right choice for a copier?
Not necessarily. Push-based architectures are faster but meaningfully harder to build correctly, since they require reconnect logic, heartbeats, and gap detection to handle dropped connections safely. Polling is simpler, more forgiving to implement, and can be entirely adequate for slower strategies or platforms that don't expose a push interface at all. The right choice depends on matching the transport's tradeoffs to how fast your specific strategy actually needs to react.