How Trade Copying Works: Under the Hood

Trade copying looks simple from the outside: the leader buys, the followers buy. But under the surface, MimikTrader orchestrates a multi-step process that must be fast, reliable, and safe. This article explains how that process works in plain language, without requiring any technical background.

Step 1: Detecting the Leader's Trade

MimikTrader maintains a persistent WebSocket connection to your broker (Tradovate). A WebSocket is like an open phone line between MimikTrader and the broker — data flows in real time without needing to repeatedly ask for updates. Every time something happens on the leader's account — a fill, a new order, a position change — the broker pushes that information to MimikTrader instantly.

When the leader places a trade and it fills (executes), the broker sends a fill notification through the WebSocket. MimikTrader captures this fill event and extracts the key details: what contract was traded, which direction (buy or sell), how many contracts, and at what price.

This detection method is fundamentally different from polling (where the system would repeatedly ask "did anything happen?" every few seconds). WebSocket detection means there is essentially zero delay between the leader's fill and MimikTrader becoming aware of it — typically under 100 milliseconds.

Step 2: Fill Deduplication

Before processing a fill, MimikTrader must ensure it has not already seen this exact fill. Duplicate fills can occur in several situations: WebSocket reconnections may replay recent events, broker systems may send the same fill notification multiple times, or network interruptions can cause retransmissions.

MimikTrader uses a three-layer deduplication system to prevent duplicate trades on followers:

• Layer 1 — In-memory fill cache: Every fill is stored in a fast in-memory cache indexed by its unique broker fill ID. If the same fill ID arrives again within the cache window, it is immediately discarded.
• Layer 2 — Fill ledger: Fills are recorded in a persistent database ledger. Before processing, MimikTrader checks whether a fill with this broker ID has already been recorded for this copy group.
• Layer 3 — Leader event deduplication: At the replication layer, MimikTrader checks whether a leader event with the same broker fill ID has already been dispatched for this group. If it has, the entire replication is skipped.

Step 3: The Three-Phase Replication

Once a fill is confirmed as unique, MimikTrader processes it through three sequential phases. This structure ensures that risk is checked first, orders are placed in parallel for speed, and all results are recorded atomically.

Phase A: Risk Evaluation

For each follower in the copy group, MimikTrader runs the full risk evaluation. This is a sequential check through every condition: is the group active? Is the follower enabled? Is the connection online? Is the account locked? Are daily and weekly limits within bounds? Does the symbol pass the whitelist? Is the trade within the session window? Does it pass the hedging check?

Each follower gets an independent pass/fail decision with a calculated quantity. A follower that fails risk evaluation is immediately recorded as rejected — no broker communication happens for rejected followers.

Phase B: Broker Order Placement

All followers that passed risk evaluation have their orders placed in parallel. MimikTrader sends all follower orders simultaneously rather than one at a time. This parallel execution minimizes the total latency — if you have five followers, all five orders go out within milliseconds of each other, rather than sequentially waiting for each to confirm.

During this phase, cross-contract conversion happens if configured (NQ to MNQ, for example). The order is submitted to the broker as a market order by default, ensuring immediate execution. Each order includes a group tag for identification in your broker platform.

Phase C: Database Recording

After all broker orders complete (or fail), MimikTrader records everything in a single atomic database transaction. This means either all records are saved or none are — there is no partial state. The records include:

• The leader event (the original fill from the leader).
• A follower order attempt for each follower — whether it was accepted or rejected, the quantity, price, and any rejection reason.
• Updated position and P&L data for each follower account.
• Activity log entries for auditing and the dashboard feed.
• Fill ledger entries for the deduplication system.

Rate Limiting

Tradovate imposes rate limits on API requests. Sending too many orders in a short window can result in temporary throttling or blocked requests. MimikTrader includes a built-in rate limiter that queues outgoing requests and spaces them appropriately to stay within broker limits.

The rate limiter operates transparently — you do not need to configure anything. If a burst of leader activity would exceed the rate limit, follower orders are queued and dispatched as fast as the rate limit allows. Under normal conditions (a few trades per minute), the rate limiter adds no perceptible delay.

Position Reconciliation

Over time, small discrepancies can develop between the leader's position and a follower's position. This can happen due to partial fills, rejected orders, or momentary connection issues. MimikTrader tracks positions in its database and updates them after every trade. If a follower's position drifts from what is expected:

• Close signals use the follower's actual position to calculate the close quantity, not the leader's. This prevents over-closing or under-closing.
• When the leader goes completely flat, MimikTrader sends a close-all signal to every follower with an open position in that instrument, regardless of how many contracts they hold.
• The Cockpit page shows real-time position data for every follower, making it easy to spot discrepancies at a glance.

Real-Time Risk Monitoring

Separately from the trade copying pipeline, MimikTrader runs a continuous risk monitoring loop that evaluates every open position on every price tick. This monitor operates independently of trade events — it does not wait for the leader to trade. Instead, it watches market prices and compares each follower's equity against its configured risk limits in real time.

If a limit is breached between trades (for example, the market moves sharply against an open position), the risk monitor can trigger an auto-flatten and lock the account without any leader activity. This provides protection even during fast-moving markets where the leader has not yet reacted.

End-to-End Latency

From the moment the leader's fill arrives via WebSocket to the moment follower orders are submitted to the broker, the typical end-to-end latency is measured in milliseconds — not seconds. The primary sources of latency are:

• WebSocket propagation from broker to MimikTrader (typically under 50ms).
• Risk evaluation per follower (under 1ms per follower — this is pure math with no I/O).
• Broker API round-trip for order placement (varies by broker, typically 100-500ms for Tradovate).

MimikTrader tracks and records fill latency metrics. You can view average and 95th percentile latency on the admin dashboard to verify performance.