This page is a mechanics deep dive. It explains the engine of copy trading—signal normalization, routing, sizing math, sync models, slippage attribution, fee ordering, and audit trails. It does not cover beginner concepts, pros/cons, or “how to start.” For those, see our beginner guide and the overview: What Is Copy Trading and How It Works.

How Copy Trading Works (Mechanics & Engine Guide)

What You’re Actually Copying (Signal vs Order vs Position)

Copy engines don’t all mirror the same thing. Some forward a signal event, some replicate the exact order, and others keep your account at a target position state. Knowing which model your platform uses explains why your fills differ by a few ticks, why partial closes look odd, and how re-syncs recover after a disconnect.

Signal-level mirroring

What it is: The platform streams a sequence of leader events—open, modify, close—with metadata (symbol, side, intended size, SL/TP, timestamp). Your account then places an order that best approximates that intent at your venue.

• Event anatomy (typical fields): { id, ts, symbol, side, size, orderType, price?, sl?, tp?, comment/hash }
• Mapping layer: Translates leader symbols/contracts to your venue (e.g., XBTUSD → BTCUSD.PERP), adjusts lot step, min notional, tick size.
• Sizing: Size is computed from your copy mode (equity-%, fixed, risk-based) and rounded to venue increments.

Strengths

• Works across venues and contract specs.
• Easy to add local protections (max deviation, price collars) and build an auditable, time-stamped trail.

Trade-offs

• Latency sensitivity: You fill at your venue and your time (T_you ≥ T_leader) → slippage vs leader is normal.
• Partial fills: Fast markets fragment execution; the engine may send amend events to reach intended size.
• Rounding drift: Tiny leader sizes may round to zero; engines use min-qty guards to skip “dust.”

Failure/edge cases

• Symbol mismatch: If mapping fails (delisted/unsupported), the event is parked and a re-sync attempts recovery on the nearest tradable symbol.
• Modify storms: Rapid SL/TP updates get throttled/coalesced to avoid reject loops.
• Idempotency: Unique event keys prevent double-opens when replaying after a disconnect.

Where it’s common: Most crypto/CFD social copy engines; heterogeneous-venue platforms.

Order-level replication

What it is: The system clones the leader’s ticket—market/limit/stop, time-in-force (TIF), price—and mirrors subsequent amend/cancel instructions, scaled by your sizing rules. Goal: preserve the leader’s intent and lifecycle.

• Ticket lifecycle mirrored: place → (partial) fill → amend → cancel
• Price handling: Limit/stop prices are converted via symbol/tick mapping; deviation guards stop chasing far-gone quotes.
• TIF nuances: IOC/FOK may differ across brokers; engines downgrade to supported equivalents with warnings.

Strengths

• High intent fidelity for complex tactics (laddered limits, brackets, OCO).
• Clear parity for partial closes and scale-ins/outs.

Trade-offs

• Venue friction: Copied limits might not fill if your book/liquidity differs—divergence without “errors.”
• Reject/requote handling: Dealer models can requote; engine policies decide to retry, convert to market, or drop.
• Complexity: More failure modes (e.g., stale amend on already-filled legs).

Edge cases & policies

• Price improvement/slippage: Track vs the leader’s reference price and vs your own order to assess execution quality.
• Cross-venue bands: Price-band checks may reject far amendments; engines re-price within bands or cancel.
• Concurrency: Rapid scalps queue tickets; sequencing/coalescing keeps order.

Where it’s common: Advanced mirror services, pro terminals, or broker-native features when both parties share similar infrastructure.

Position-level synchronization

What it is: The engine targets the leader’s net exposure. Your account periodically (or continuously) rebalances to the same direction and size-ratio, within caps and rounding. Partial closes and baskets become natural state changes.

• Target state: target_position = scale × leader_net_position (per symbol).
• Rebalance logic: If actual vs target diverges beyond a threshold, send corrective orders (single shot or stepped).
• Basket awareness: Multi-ticket or multi-leg baskets on the same symbol are handled as state changes, not a flood of events.

Strengths

• Resilience: After disconnects, a snapshot diff brings you back in line without replaying every event.
• Clean partials: Leader closes 25% → your target shrinks 25% → you rebalance.

Trade-offs

• State drift: Infrequent snapshots (e.g., 60s) can lag fast leaders.
• Netting vs hedging: Account mode matters (MT4/5 netting collapses opposite tickets; hedging holds both). Engines normalize to a single “net” target.
• Rounding gaps: Very small leader tweaks can sit below your min lot until the threshold is exceeded.

Edge cases & controls

• Rebalance thresholds: Use %-of-position or absolute-lot thresholds to avoid churn from tiny nudges.
• Caps: Per-symbol and per-leader caps prevent outsized rebalances after pyramids.
• Conflict resolution: If you hold discretionary positions, either isolate in sub-accounts or net with copy exposure per policy.

Where it’s common: Broker-native mirrors, MAM/PAM-style environments, platforms prioritizing robustness over tick-for-tick parity.

Which Strategy Does Each Model Suit?

• Fast scalping / frequent amendments: Order-level (with strong routing), or avoid copying if your venue/latency can’t keep up.
• Swing/intraday with partial closes: Signal-level or Position-level both work; position sync often yields cleaner parity over days.
• Basket/multi-leg on the same symbol: Position-level shines for state convergence.

Inline note: If you’re brand-new, start with the core concepts here and save the “getting started” steps for our beginner’s primer on copy trading.

End-to-End System Architecture

Copy trading is a distributed pipeline. A leader creates intent, the platform turns that intent into portable instructions, and follower endpoints execute them under local rules. Understanding each hop explains slippage, discrepancies, and why robust systems use re-syncs and idempotent keys.

Leader → Platform Core → Follower

High level: The leader’s terminal/API emits trade events; the platform ingests and normalizes them; follower connectors translate and execute at the destination broker/exchange.

• Leader side (producer)
  • Emits: open / modify / close with metadata (symbol, side, qty, SL/TP, order type, timestamp, event id).
  • Optional: equity and risk context (balance, leverage mode) for ratio/risk-based sizing on followers.
• Platform core (transport + logic)
  • Validates, normalizes, and enriches events (mapping, step sizes, min notional, tick size).
  • Applies copy policy (equity-%, fixed size, per-leader caps, price bands, max slippage).
  • Queues for dispatch with ordering guarantees and back-pressure controls.
• Follower endpoints (consumers)
  • Translate normalized instructions into venue-native orders.
  • Enforce local controls (per-symbol cap, DD brake, price deviation guard).
  • Report fills/amends/cancels back to the core for reconciliation and audit.

Normalization & validation

Normalization ensures a leader’s intent remains executable across different venues, symbols, and contract specs.

• Symbol & contract mapping
  • Example: XBTUSD (leader) → BTCUSD.PERP (follower); EURUSD. → EURUSD.
  • Maintain a mapping table with fallback aliases and delisting rules.
• Trading spec fit
  • Lot step/min notional: round sizes to venue increments; drop dust below min.
  • Tick size/price bands: clamp limit/stop prices to valid ticks; reject out-of-band quotes.
  • Leverage/margin mode: respect follower’s mode (cross/isolated); prevent orders that exceed margin limits.
• Policy validation
  • Sizing policy: equity-% / fixed / risk-per-trade; apply per-leader and per-symbol caps.
  • Risk gates: max slippage, max orders per second, max open tickets.
  • Idempotency: attach unique keys (e.g., {leader_event_id}-{scale_hash}) so retries don’t double-open.
• Health flags
  • “Executable”, “Executable with adjustments” (rounded size/price), or “Non-executable” (parked for review).

Latency points

Every hop adds time and potential divergence. Track them explicitly.

• T₀ → T₁ (Leader fill → Platform ingest)
  • Network hop from leader to core; clock skew and message queue delay matter during fast moves.
• T₁ → T₂ (Normalize → Dispatch)
  • Mapping, sizing, risk checks, and queueing. Coalescing frequent modifies can reduce storm lag.
• T₂ → T₃ (Follower route → Venue fill)
  • Connector → broker API → exchange matching engine. Venue load, rate limits, and your route (geo/VPS) dominate here.

What to measure

• Δ₁ = T₁ − T₀ (ingest delay), Δ₂ = T₂ − T₁ (processing delay), Δ₃ = T₃ − T₂ (execution/venue delay).
• Execution divergence: (leader_fill_price − follower_fill_price) in ticks/pips; track mean/median and 95th/99th percentiles.
• Fill completeness: % partial fills, average number of amendments per intended order.

Failure modes

Distributed systems fail in small ways; resilient copy engines plan for it.

• Dropouts & jitter
  • Packet loss, clock drift, or brief disconnects cause missed/late events.
  • Mitigation: periodic position snapshots and state diffs (for position-sync models), plus replay buffers (for signal/order models).
• Throttling & rate limits
  • Broker/exchange APIs impose per-second caps.
  • Mitigation: token buckets, adaptive backoff, batch/coalesce frequent modifies, degrade to market-at-band when appropriate.
• Validation rejects
  • Requotes, price bands breached, min-notional failures.
  • Mitigation: pre-flight checks, price-band re-pricing, and clear “non-execution” logs when policy forbids forced fills.
• Out-of-sync state
  • Example: follower filled while the platform still thinks it’s pending.
  • Mitigation: idempotent order keys, periodic reconciliation jobs (pull fills from venue, reconcile against ledger, repair with amend/close).

Reconciliation toolkit (recommended)

• Idempotency keys: order_key = hash(leader_event_id, symbol, side, target_qty, policy_version).
• Deterministic retries: N attempts with exponential backoff; switch to alternative action (e.g., cancel or convert to market) under policy.
• Re-sync jobs: hourly (or on reconnect) snapshot: positions, open orders, last HWM; repair drift above thresholds.
• Audit trail: append-only logs: {ts, actor, action, req, resp, venue_txid, error?, retry?} for every hop.

Linear timeline (use for your diagram)

A simple one-line flow with timestamps you can hand to design:

• T₀ Leader fill → event {symbol, side, qty, price, ts=T₀} emitted
• T₁ Core normalize → map symbol, round qty/price, apply caps, assign order_key
• T₂ Dispatch → follower connector submits venue-native order; record request/response
• T₃ Follower fill → capture fill/partial, slippage vs leader, fees; ack back to core → audit ledger

Diagram note (for designer)

• Style: dark theme, solid background (#0B0F14), brand green accents (#22C55E).
• Lanes: three swimlanes (Leader / Platform Core / Follower).
• Markers: T₀/T₁/T₂/T₃ time tags above arrows; micro-labels under arrows: normalize, dispatch, execute.
• Footnote: small text: “Track Δ₁/Δ₂/Δ₃ and slippage to manage income on BestCopyTrading.com”.

Sizing & Allocation Algorithms (How Size Gets Decided)

Copy systems turn a leader’s intent into follower size using a few predictable recipes. Knowing which one you’re on—and its caveats—prevents surprise risk.

Equity-percent mirroring (proportional)

Formula:
Follower Size = (Follower Equity / Leader Equity) × Leader Size × Multiplier

What it does well

• Auto-adapts to deposits/withdrawals and PnL on both sides.
• Keeps relative risk aligned across different account sizes.

Implementation notes

• Use a reference equity (e.g., end-of-bar or last confirmed balance) to avoid oscillation during fast PnL moves.
• Clamp extreme ratios: e.g., 0.1x ≤ ratio × multiplier ≤ 3x.
• Equity spikes (affiliate rebates credited, month-end interest, coupon airdrops) can bloat the ratio → briefly reduce size. Mitigate with a 24–72h moving average equity or a max day-over-day equity change threshold (e.g., ±10%) before recalculating size.
• If the leader uses pyramids or partial adds, mirror ticket-by-ticket so your average price and partial-close math remain proportional.

Quick example
Leader equity 20,000; follower equity 5,000; leader opens 2.0 lots; multiplier 1.2 →
(5,000/20,000) × 2.0 × 1.2 = 0.6 lots (round to broker min step, e.g., 0.60 on 0.01-step symbols).

Fixed amount / fixed lot

What it is

• You predefine a constant quantity per trade (e.g., always 0.10 lot or always $500 notional).

Pros

• Predictable costs and easy planning for commissions, margin, and exposure.

Watch-outs

• Volatility skew: the same fixed lot on XAUUSD vs EURUSD implies very different dollar risk.
• SL distance variance: tight stops on one trade vs wide stops on another means risk (as % equity) jumps around.
• Mitigate by maintaining a symbol risk table (tick value, typical SL in pips) and use per-symbol fixed sizes rather than one global number.

When to use

• Small accounts seeking consistent position sizing while you trial a leader.
• Instruments with relatively uniform volatility (e.g., major FX pairs vs exotics/commodities).

Risk-based (volatility-normalized)

Goal

• Target a constant account risk % per trade, regardless of instrument or SL width.

Inputs

• Volatility proxy: ATR(n) or rolling standard deviation σ.
• Stop distance: in pips/points or price units.
• Per-trade risk cap: ~0.5% of account equity.

Core formula (FX/CFD, pip-based)
Position Size (lots) = (Risk $) / (Pip Value × Stop (pips))
Where Risk $ = Equity × Risk %.

ATR-based stop
Stop (pips) = k × ATR(n) (k e.g., 1.5–2.5). This stabilizes risk under changing volatility.

Implementation notes

• Recompute size on entry only; don’t rescale mid-trade unless your rules explicitly support dynamic risk.
• For crypto perps, use notional sizing:
  Contracts = (Risk $) / (SL $/contract).
• Enforce min/max size per symbol to avoid dust orders or oversized fills when ATR collapses/expands.

Pros

• Smooths risk across symbols and market regimes.

Cons

• Requires reliable ATR/σ and symbol metadata (pip value, contract size).
• Slightly more compute and data plumbing.

Per-leader and per-instrument caps

Why caps

• Prevent crowding and over-concentration (e.g., three leaders all long XAUUSD).

Typical guardrails

• Per-leader equity cap: 15–25% of follower equity (including open PnL).
  Example policy: Hard stop following if leader’s open exposure would push beyond 20%.
• Per-instrument cap: e.g., ≤ 0.5–1.0% account risk per symbol, ≤ 2–3% total open risk.
• Category caps: group correlated symbols (USD-majors, metals, AI equities) to cap cluster risk.

Enforcement

• Check caps pre-dispatch of each order; if an incoming trade breaches, either:
  1. down-scale proportionally,
  2. queue until exposure frees up, or
  3. skip with a logged reason (preferred for auditability).

Partial closes & scaling

Partial close logic (proportional)

• If leader reduces a ticket by x%, reduce the follower’s mapped ticket by the same percentage.
• Maintain ticket-level mapping to preserve average price and realized PnL symmetry.

Rounding rules

• Round to broker min lot and step size (e.g., 0.01).
• If a partial results in a size < min lot, choose one:
  • Close remainder (aggressive, keeps sync tight), or
  • Hold remainder until a future partial pushes it above the step (can cause slight drift).

Scaling in/out

• Respect per-trade and per-symbol risk caps on every add.
• If the leader scales with tighter/wider stops per leg, recompute follower size leg-wise (risk-based mode) or percentage-wise (equity-percent mode) to stay consistent with your chosen algorithm.

Edge cases

• Broker rejects partial due to precision/step: retry with a rounded size and log the delta.
• Netting accounts (vs hedged): translate partial closes to reduce-only orders to avoid flip-flops.

Practical selection guide

• Start simple: equity-percent mirroring with conservative caps.
• Add stability: migrate high-volatility symbols to risk-based sizing.
• Control drift: implement strict per-leader/per-instrument caps and audited rounding behavior.
• Document it: persist the chosen algorithm, parameters, and cap values in your copy-engine config and export them with your weekly logs.

For control patterns and guardrails that pair with these sizing modes, see risk controls in the copy trading risk management guide.

Execution: Orders, Routing & Slippage

Order types & life-cycle

Supported types (common across FX/CFD & crypto):

• Market: execute instantly at best quote. Use reduce-only when closing to avoid flip/overfill on netted books.
• Limit: set a price or better. Combine with post-only (crypto/ECN) to ensure maker fees and avoid taker slippage.
• Stop / Stop-Market: trigger once price crosses the stop; good for momentum/exit. On some brokers this becomes a market order at trigger.
• Stop-Limit: trigger → place a limit; prevents runaway fills but risks no-fill in fast moves.

Time-in-force nuances:

• GTC (Good-Till-Cancel): persists until filled/cancelled; default on many CFD brokers.
• GTD (Good-Till-Date/Time): expires at a set timestamp—useful around roll/close.
• IOC (Immediate-Or-Cancel): fill what you can now; cancel the rest. Reduces queue risk, produces partials.
• FOK (Fill-Or-Kill): all or nothing; avoids partial fills but increases no-fill risk.

Life-cycle you must handle:

1. New → Working: accepted by venue; order ID assigned.
2. Partially Filled: track remaining qty and VWAP of fills.
3. Filled / Cancelled / Rejected: terminal states; log reason (price band breach, throttle, symbol halt).
4. Amend / Replace: price/qty/flags change generates a new child order ID on many venues; keep an idempotent client order key to map them.

Implementation tips

• Always tag orders with: leader_order_id, follower_order_id, client_order_key, reduce_only, post_only, tif.
• For partial closes, prefer reduce-only market to guarantee position shrink on netted venues (e.g., many crypto futures).
• Normalize rejections into categories: throttled, outside price band, insufficient margin, step/lot precision, trading halt.

Routing differences

Different playbooks, different results.

• Leader @ Broker A vs Follower @ Broker B / Exchange C means distinct liquidity pools, spreads, last-look policies, and fee tiers.
• STP/ECN FX: pass-through to LPs; variable spread + commission; potential last look (reject or re-quote).
• CFD dealing desks: internalized flow; max deviation setting acts like a personal price collar.
• Crypto centralized exchanges: maker/taker tiers, queue priority by price → time; post-only to farm maker rebates when appropriate.

Routing policy knobs

• Smart-route by cost: prefer venues where (expected slippage + fees) is lowest for that symbol and size.
• Smart-route by fill rate: prefer venues with higher partial/full fill likelihood for your time-in-force.
• Venue stickiness: avoid route-flapping; apply hysteresis (e.g., switch only if 5-trade rolling cost delta > X bps).

What to log per venue

• Effective spread at arrival, queue position proxy (if exposed), fee tier, reject codes, latency (dispatch→ack, ack→fill).

Price bands & protections

Controls that keep fills sane

• Max deviation / slippage cap (CFD/FX): e.g., reject market orders if execution drifts > X pips from reference.
• Exchange price collars (crypto/futures): engine-enforced; orders outside collar are rejected or capped.
• Risk checks: step size, min lot, notional min/max, leverage limits, maintenance margin.
• Halt / circuit breakers: symbol pauses; your engine should auto-cancel working orders if venue cancels, then queue a re-sync.

Partial-fill policies

• Marketables may fill across multiple price levels; your engine must compute VWAP and carry the remaining qty correctly.
• With IOC, expect partials; with FOK, expect frequent rejections in thin books.

Recommended defaults

• Set symbol-level price protection:
  • FX majors: 0.5–1.5 pip
  • Gold (XAUUSD): 5–15 cents
  • Crypto perps: 2–8 bps of reference price
• Fall back to cancel & alert instead of force-filling beyond caps.

Slippage math

Define your references clearly

• Leader reference price: usually the leader fill price (or mid at leader fill time if you track signal-only). Be consistent.
• Follower fill price: VWAP across all partials of the mirrored action.

Per-trade slippage (signed):
slip_price = follower_vwap – leader_reference (signed by trade direction; positive = worse for buys, better for sells).
Convert to pips/bps:

• Pips (FX): slip_pips = slip_price / pip_value.
• Bps (percent of price): slip_bps = (slip_price / leader_reference) × 10,000.

Aggregate the right way

• Report median, 95th percentile, max per leader, symbol, time-of-day.
• Weight by notional when rolling up: large tickets should influence stats more than dust fills.
• Separate arrival slippage (signal-to-send time), venue slippage (book impact vs arrival mid), fee drag (commissions, taker).

Attribution example

• Total cost (bps) ≈ arrival lag bps + spread/impact bps + fees bps.
  Track each component so you can tune: network/dispatch (arrival), routing/post-only (impact), and fee tiering (fees).

Health thresholds (typical)

• Scalpers: median ≤ 2–5 bps, p95 ≤ 8–15 bps (else strategy edge likely evaporates).
• Swing/intraday: tolerate higher p95 if hold > several hours.

Holding time sensitivity

Why time matters

• Short hold (scalpers, news-snipes): PnL per trade is small → latency, spread, and fees dominate. Even tiny extra bps flip the sign.
• Longer hold (intraday/swing): Entry precision matters less; position management and overnight costs matter more.

Rules of thumb

• Cost-to-edge ratio:
  expected_edge_per_trade (bps) ≥ 3 × end-to-end_cost (bps) for high-turnover leaders to be viable.
• Min hold vs spread: aim for average hold PnL ≥ 5–10× median spread on the instrument.
• Fee break-even (crypto): if taker fee = 5 bps and median slippage = 6 bps, your entry cost is already 11 bps before exit—scalpers will struggle unless exits are maker or you net rebates.

Operational mitigations for short holds

• Co-locate (VPS/API) near venue; pre-warm sessions; keep persistent connections.
• Use IOC to avoid deep queueing on marketables; prefer post-only for exits where feasible to earn maker.
• Enforce a min expected hold time (or min ATR fraction) filter to skip trades that can’t overcome costs.

Quick execution checklist (drop-in)

• Tag every order with idempotent keys; reconcile partials to VWAP.
• Enforce symbol price bands and step/lot precision pre-dispatch.
• Track latency buckets: signal→send, send→ack, ack→fill.
• Publish median/p95 slippage per leader/symbol and a weekly “top drags” list.
• Route with hysteresis and keep a cost ledger (arrival, impact, fees) to guide tuning.

Sync Models (Keeping Follower State Aligned)

Real-time sync

What it is
Event-driven replication: the platform streams leader events (open/modify/close; SL/TP; partials) and immediately translates them into follower actions.

When to use

• Active intraday leaders, scalpers, basket strategies with frequent partial adds/closes.
• When you can guarantee stable connectivity and low end-to-end latency.

Design notes

• Sequencing: stamp each event with a monotonic sequence (per leader, per symbol) plus a logical clock (Lamport/watermark) to detect gaps/out-of-order messages.
• Idempotency: every outbound follower action must carry a client_order_key derived from (leader_order_id, seq, action_type). Replays won’t duplicate fills.
• Backpressure: if follower acks lag behind stream rate, buffer then degrade (pause noncritical amendments before new opens).
• Heartbeat & liveness: leader→core and core→follower heartbeats (e.g., 1–5s). Miss ≥ N beats → raise DEGRADED and switch to snapshot mode.
• Clock hygiene: NTP sync both sides; store leader_fill_time, ingest_time, dispatch_time, follower_ack_time for latency attribution.
• Precision guards: pre-dispatch validation (min lot/step, price bands) to fail fast with explicit reject codes.

Typical targets

• Dispatch delay (core→follower ack): p50 ≤ 100–250 ms; p95 ≤ 500–800 ms (same region/VPS).
• Order reject rate: < 0.5% excluding venue halts.

Interval re-sync

What it is
State snapshots every N seconds (e.g., 15s/30s/60s). The follower compares local state to leader’s target state and issues minimal actions to converge.

When to use

• Unstable networks, mobile endpoints, or venues with noisy APIs/websockets.
• Leaders with slower turnover (intraday/swing) where a trailing window is acceptable.

Design notes

• Snapshot schema: positions (symbol, side, net qty/notional, avg price), pending orders (type, price, qty, tif), risk (used/free margin), and per-ticket map if you mirror tickets.
• Diff engine: compute Δ = Target − Local at two levels:
  1. Position-level (netting venues): issue reduce-only orders to match net exposure.
  2. Ticket-level (hedged venues): add/close specific tickets to align lot-by-lot proportions.
• Tolerance bands: avoid churn with deadband rules (e.g., ignore diffs < 0.01 lot or < 0.2% notional).
• Priority queue: process closes → reduces → cancels → new opens to minimize transient risk spikes.
• Rate limits: respect venue throttles; batch non-urgent amendments (price/TP micro-nudges) into the next cycle.
• Rolling checksums: include a lightweight hash of (symbol, net qty, avg price, open orders) to detect silent drift.

Tuning

• Snapshot cadence: 15–30s for intraday; 60–120s for swing.
• Max reconciliation actions per cycle (e.g., ≤ 10) to avoid API bans.

Recovery after disconnect

Goal
Come back in-sync without double-entry or orphaned exposure after any outage, restart, or venue hiccup.

Inputs you need

• Last applied seq/watermark per leader/symbol.
• Local follower ledger (positions, open orders, pending client_order_keys).
• A fresh leader snapshot at reconnect.

Recovery algorithm (safe default)

1. Freeze new actions. Mark follower state as RECOVERING.
2. Fetch leader snapshot S_t and last N events since your watermark. If the gap is large or events unavailable, trust S_t only.
3. Rebuild target: If events are available, replay missing events against your local state (idempotent) to advance to t.
4. Diff & reconcile:
   • Positions: compute Δpos; submit reduce-only orders first to cut excess, then opens to fill shortage.
   • Orders: cancel/replace locals not present in S_t; place missing stops/limits.
5. Precision & caps: apply min-lot rounding; re-check per-symbol and per-leader caps before each action.
6. Unfreeze. Switch status to LIVE and resume real-time or interval mode.
7. Audit trail: write a recovery report (duration, actions taken, remaining drift, rejects).

Edge cases to handle

• Ghost orders: venue shows a working order with no local record → cancel and re-emit if needed.
• Partial fills during blackout: detect via position delta vs expected; adjust average price and realized PnL.
• Corporate/symbol events: rolls, splits, contract renames—normalize symbol mapping before diffing.
• Netting vs hedging: on netted books, translate multiple leader partials into a single reduce-only close without flipping side.

Quick sync checklist (drop-in)

• Use monotonic seq + idempotent keys for all actions.
• Keep two paths: real-time stream and N-second snapshots; auto-failover when heartbeats drop.
• Diff with deadbands and max ops per cycle; process closes before opens.
• Persist last watermark, local ledger, and a rolling checksum per symbol.
• Produce a weekly drift report: median/95p residuals by leader/symbol and count of recovery events.

Risk Propagation (What Really Transfers to Followers)

Correlation & crowding

What happens

• When several leaders are long the same instrument/timeframe (e.g., XAUUSD M15 momentum), your follower account inherits a clustered bet, even if each leader looks “diversified” in isolation.
• Crowding isn’t only “same symbol”: factor overlap (USD strength, rates beta, gold/oil/tech risk-on) and time overlap (entries within the same hour) also pile up risk.
• In stress, tail correlation rises (ρ → 1). That’s why baskets that looked benign in calm regimes break together in shocks.

How to measure it (practical)

• Build a rolling exposure matrix: rows = leaders, cols = symbols (or factors); cells = signed notional (or % equity at risk).
• Compute:
  • Symbol correlation (30–90d): corr(leader_i PnL, leader_j PnL) and corr(symbol_returns).
  • HHI of exposure per asset class/sector: HHI = Σ w_k^2 (w_k = share of portfolio risk in cluster k).
  • Time overlap: % of trades initiated within Δt (e.g., 60 min) on the same symbol/direction.
• Convert to risk units: volatility-weight notionals, so 1 lot XAUUSD counts more than 1 lot EURUSD.

Guardrails that work

• Per-symbol cap: ≤ 0.5–1.0% account risk per instrument.
• Per-cluster cap (e.g., “USD majors”, “metals”, “AI equities”): ≤ 2–3% total open risk.
• Leader overlap brake: pause new entries from a leader if ≥2 other leaders already hold the same symbol/direction within the last N minutes.
• Diversity floor: require ≥ K distinct uncorrelated symbols (or factors) before allowing new size in an existing cluster.

Monitoring

• Weekly cluster heatmap (risk share by symbol/factor).
• Tail test: 1–2 day historical shock (e.g., −2σ on the largest cluster) → check margin survivability ex-ante.

Leverage and margin cascade

Why the follower’s leverage matters

• A leader may run low leverage with ample buffer; your follower could be copying under higher leverage/cross margin, turning the same idea into liquidation risk on ordinary drawdowns.
• Different venues ⇒ different initial/maintenance margin, auto-deleveraging rules, overnight financing. The cascade can trigger on the follower while the leader remains safely in the trade.

Map size to margin first (not after)

• Compute max allowable size by margin, then take the min of (sizing algorithm output, margin-safe size).

For notional-margin products (crypto perps/futures):

max_notional_by_margin = (free_margin – safety_buffer) / initial_margin_rate max_size = min(algorithm_size, max_notional_by_margin)

For FX/CFD (lot-based):

required_margin = notional / leverage keep: free_margin / equity ≥ margin_ratio_floor (e.g., 60–70%)

Buffers & tripwires

• Liquidation buffer: target maintenance margin × 1.5–2.0 free headroom.
• Auto-de-risk rule: if margin ratio falls below X% or open risk > cap, reduce-only the largest contributors first.
• Pyramid brakes: don’t add legs if margin ratio < threshold or if ATR has expanded > Y% since the first entry.
• Venue heterogeneity: store per-symbol margin tables (step size, IM/MM, leverage caps) by broker/exchange; never assume leader’s conditions.

Weekly sanity

• Report max drawdown to liquidation distance (in ATRs or % move) for top holdings.
• Simulate −Zσ shocks on crowded symbols to confirm buffer adequacy.

Corporate actions & symbol events

What propagates

• Crypto perps funding (8h or hourly): positive/negative cash flows accrue on follower even if the leader’s venue has a different rate/time stamp.
• FX/CFD swaps/overnight: long/short carry credited/debited at broker-specific cutoffs.
• Futures rolls: front contract expires → leader rolls; follower must map symbols (e.g., ESZ5 → ESH6) and migrate orders/SL/TP.
• Dividends/splits (equity/CFD): cash adjustments or quantity/price transforms alter average price, PnL, and stops.
• Symbol renames/lot precision changes: contract specs update; stale orders can reject or mis-size.

Operational playbook

• Maintain an event calendar per venue: funding times, roll dates, dividend ex-dates, early closes, halts.
• Pre-event checklist:
  • Freeze new entries N minutes before known halts/rolls if you can’t guarantee mapping.
  • For rolls: either close & reopen on the new contract (simple) or spread-roll (sell old, buy new) if available.
  • Rebase SL/TP after split/roll so distance (ATR or %) is preserved.
• Funding/overnight costs: attribute to each position; include in weekly net performance so leaders with high carry drag aren’t over-allocated by mistake.
• Cross-venue differences: store venue-specific coefficients (funding index, swap calendars). If the leader trades “XBTUSD” and follower “BTCUSDT-PERP”, normalize symbol and apply the follower venue’s economics.

Edge cases to catch

• Weekend gaps (FX/CFD): ensure max deviation and gap-open rules avoid market orders at illiquid reopen.
• Contract precision changes: re-round open orders to the new tick/lot step before the venue enforces it.
• Dividend on short CFD: expect a debit; don’t misclassify as trading loss.

Copy-Engine Capabilities & Observability (What to Compare)

Data transparency

What to demand

• Verified trade history: immutable IDs per order (open/modify/close), timestamps, prices, size, and side; downloadable CSV.
• Time-stamped equity curves: show gross vs net (after spreads/commissions/funding/fees) with the timezone and valuation currency stated.
• Max drawdown methodology: disclose window (peak-to-trough on net equity), whether it’s end-of-day or intraday, and if open PnL is included.
• Benchmarking period: clear start/end dates; avoid cherry-picked windows.
• Slippage & fill stats: median/p95 by symbol and session; explain reference price (leader fill vs mid).
• Fee model disclosure: who charges what, when, and on which base (per trade, per month, high-water mark).
• Tamper-evidence: hashes for logs, third-party mirrors, or signed exports to deter backfills.

Red flags

• Equity curves without time axes, only closed-trade performance while running large open risk, or unexplained resets.
• “Verified” labels with no downloadable raw events.

Copy engine features

Core sizing modes

• Equity-percent (proportional): ratio × multiplier; auto-adjusts to deposits/withdrawals.
• Fixed amount/lot: stable cost; risky across volatile symbols.
• Risk-based: ATR/σ sizing to hit a target % risk with given SL distance.

Risk & allocation controls

• Per-leader caps: hard ceiling (e.g., 15–25% equity), stop-follow on breach.
• Per-instrument/cluster caps: limit symbol and factor crowding (e.g., ≤0.5–1.0% risk per symbol; ≤2–3% per cluster).
• Max concurrent trades / total open risk: portfolio-level brake.

Sync & safety

• Real-time events + interval re-sync, idempotent order keys, recovery after disconnect.
• Stop-follow on DD: auto-pause a leader at X% real-time drawdown or Y consecutive losses.
• Partial-close parity: proportional partials with broker rounding rules.
• Reduce-only semantics for netted venues to avoid accidental flips.

Analytics & governance

• Leader health metrics: reject rate, dispatch latency, median/p95 slippage, strategy change flags.
• Shadow mode: paper-follow for burn-in; backtest-style replay on historical tape.
• Change control: versioned leader mappings (symbols, sizing, caps) with audit logs.

Connectivity & tooling

Connectivity

• API/VPS support: REST/WebSocket stability, session keep-alive, and co-location options.
• Venue adapters: symbol mapping, contract specs (tick, lot step, IM/MM), precision, price bands.
• Failover: heartbeat, auto-switch to snapshot mode, and queued replays on recovery.

Operational tooling

• Latency metrics: signal→send, send→ack, ack→fill; display p50/p95 by venue.
• Alerts: cap breaches, DD thresholds, disconnects, roll/split calendars, funding spikes.
• Logs & exports: event logs (signal/order/position), fee ledgers, FX conversions; CSV/JSON exports with stable schemas.
• Role-based access: read-only dashboards for investors; write scopes for operators.
• Observability hooks: webhooks, Slack/Telegram alerts, and queryable metrics endpoints.

Developer quality-of-life

• Sandbox environment, rate-limit docs, clear error codes, and reproducible examples.

Fees & billing

Know every layer

• Trading costs: spread, commission, funding/swap, market impact (slippage).
• Copy/performance fees: % of net new profits under a high-water mark; disclose crystallization schedule (weekly/monthly).
• Platform fees: subscription or volume-tiered.
• Conversion costs: FX on deposits/withdrawals and internal conversions (e.g., USDT↔USD).
• Ancillary: withdrawal fees, inactivity, custody.

How to evaluate

• Compute all-in cost per $1k notional and bps per trade by symbol and session.
• Reconcile fee ledgers against trade logs monthly; confirm HWM resets and clawbacks are correct.
• Prefer platforms that show after-fee equity curves and per-leader net attribution (edge vs costs).

Next step: compare concrete platforms and engines using this checklist in our shortlist: best copy trading platforms.

Fee Ordering & HWM Calculation (Mechanics Only)

Typical order of deductions

Fee waterfall (most common):

1. Trading costs incurred at the follower’s venue
     • Spread (implicit)
     • Commission (one-way / round-turn) Funding/Swap (perps 8h/hourly; FX/CFD overnight)
     • Exchange/Broker add-ons (market impact not a “fee” but an execution cost you should still track)
2. Performance/Copy fee charged by the platform/leader on net new profits at crystallization (weekly/monthly), often under a High-Water Mark (HWM)

Why this order?
Performance/copy fees are usually applied to after-trading PnL so the leader/platform is paid on what the follower actually keeps after spread/commission/funding. Platform subscription fees (if any) are typically outside this waterfall.

Sanity example

Follower keeps = $76 (before any non-performance platform subscription charges).

Gross trade PnL: +$120

Commissions: −$8; slippage/spread drag (measured): −$12; funding: −$5 → Net trading PnL = +$95

Performance fee 20% on net new profits under HWM → Fee = $19

High-water marks & resets

What HWM does
The High-Water Mark is the highest historical net equity (or net cumulative PnL) used to determine whether new fees are chargeable. You pay performance fees only on profits above the HWM.

Mechanics

• At each crystallization (e.g., month-end), compute net PnL after trading costs.
• If Net PnL ≤ 0: no performance fee; HWM stays unchanged (or may step down if the contract allows loss carry-forward to protect the follower—less common on retail platforms).
• If Net PnL > 0: fee applies to the portion above HWM; then raise HWM to the new post-fee equity/PnL.

Reset variants (read the fine print)

• Calendar reset: HWM persists across months; no “new year reset.”
• Annual reset: some products reset HWM annually (rare in retail copy trading, more common in some funds).
• Account actions: deposits/withdrawals can adjust HWM proportionally (equity-share method) to keep comparisons fair.

Worked micro-example

• Start HWM = $10,000. Month 1 net after trading = +$600 → 20% fee = $120. New equity = $10,480. New HWM = $10,480.
• Month 2 net after trading = −$300 → no fee; HWM stays $10,480.
• Month 3 net after trading = +$500 → chargeable = $500 − $0 (still below HWM? No—first bring equity back to $10,480, then fee only on the excess above HWM). If month-end equity after Month 3 is $10,680 → fee applies to $200.

Clawbacks?
If a platform calculates performance fees before funding/swaps or ignores slippage, you can get fee-overstated vs actual take-home. Prefer engines that compute on after-cost PnL and roll negative months forward correctly.

Measuring “net” properly

Define “net” once and stick to it

• Net trading PnL = realized + unrealized PnL minus spread/commission/funding at the follower’s venue.
• Net allocatable PnL = Net trading PnL minus performance/copy fee (and any revenue-share that touches follower equity).

Aggregation level

• Per-trade view (good for diagnostics): attach costs (commission, measured slippage vs reference, funding accruals during hold) to each ticket; compute trade-level net.
• Period view (billing): roll up realized/unrealized plus all costs within the crystallization window; be explicit about cut-off time and timezone.

Currency unification

• If trades or fees hit in multiple currencies (e.g., USDT fees, EUR commissions, USD PnL):
  • Choose a reference currency (e.g., USD).
  • Revalue all line items using a reference FX rate at a specific timestamp (e.g., New York close D−1 or end-of-period mid).
  • Store both the native and converted amounts with the rate used (auditability).

Common pitfalls

• Counting open PnL at different marks for leader vs follower (mismatched reference prices).
• Ignoring funding/overnight in “performance” but charging the fee on pre-funding PnL.
• Mixed netting: some venues are netted (VWAP matters), others hedged (ticket-level). Your cost attribution must match the venue’s accounting model.

What to export (minimum)

• Per ticket: open/close timestamps, sizes, prices, side, symbol → realized PnL, fees (side-specific), measured slippage, funding during hold.
• Per period: starting equity, deposits/withdrawals (separate from PnL), net trading PnL, performance fee, ending equity, HWM before/after.

Fee awareness complements the mechanics here—see the broader legitimacy factors and legal frameworks in the copy trading legal guide.

Verification & Integrity (So You Know It’s Real)

Track record verification

What “verified” should actually mean

• Public leader IDs: a resolvable identifier on the trading venue or a cryptographically linked account handle. Publish venue, account type (demo/live), netting/hedging mode, base currency.
• Third-party attestation: an independent mirror or audit that:
  • Pulls raw order/fill data directly from the venue API (read-only keys)
  • Recomputes equity curves from first principles (fills → PnL → fees → equity)
  • Matches platform-reported stats within tight tolerances (see below)
• Tamper-evident logs: each day’s export includes a hash chain:
  • hash_t = H(hash_{t-1} || day_t_csv_bytes || metadata)
  • Publish hash_t (and optionally a Merkle root) so any later edits become detectable.
• Clock & price integrity:
  • NTP-synced servers; store both ingest_time and exchange_time when available.
  • Reference prices pinned to venue stream (mid/last) with source ID; never “best guess” after the fact.

Tolerance gates (practical)

• PnL drift (auditor vs platform) ≤ 3 bps of notional over a month.
• Timestamp skew (leader vs follower) median ≤ 250 ms, p95 ≤ 800 ms (same region/VPS).
• Fill count parity ≥ 99.5% (expected vs observed; differences explained as venue rejections/partials).

Red flags

• “Verified” badges without downloadable raw logs; equity curves that reset with no audit note; demo accounts marketed as live; curves computed on closed trades only while carrying large open risk.

Event log exports

Minimum viable export (CSV/JSON)

• Leader side: leader_order_id, symbol, side, order_type, qty, price, tif, exchange_time, leader_fill_time (if filled), cancel/reject_code
• Follower side: follower_order_id, client_order_key, mapped_leader_id, qty_sent, qty_filled, vwap, dispatch_time, follower_ack_time, follower_fill_time
• Linkage: ticket_mapping_id (stable across partial fills/partials closes), position_id (netted venues), seq (monotonic event seq), replay_flag
• Costs & quality: commission, spread_estimate, funding/swap, slip_price, slip_bps, venue_id, route_policy
• State: pre_trade_equity, free_margin_before/after, cap_check (pass/deny & reason)

Schema sketch (JSON Lines)

{
“seq”: 1245321,
“leader”: {
“venue”: “BROKER_A”,
“account_id”: “LDR-9F2C”,
“order_id”: “A-77821”,
“symbol”: “XAUUSD”,
“side”: “BUY”,
“type”: “MARKET”,
“qty”: 2.00,
“exchange_time”: “2025-11-07T07:14:32.184Z”,
“fill_price”: 2384.52
},
“follower”: {
“venue”: “BROKER_B”,
“order_id”: “B-99102”,
“client_order_key”: “LDR-9F2C|A-77821|open|1245321”,
“qty_sent”: 0.60,
“qty_filled”: 0.60,
“vwap”: 2384.67,
“dispatch_time”: “2025-11-07T07:14:32.292Z”,
“fill_time”: “2025-11-07T07:14:32.621Z”
},
“quality”: {
“slip_price”: 0.15,
“slip_bps”: 6.3,
“commission”: 3.60,
“funding”: 0.00,
“spread_estimate”: 0.08
},
“checks”: {
“price_band”: “pass”,
“lot_step”: “pass”,
“caps”: “pass”
},
“hash”: “3f4c…e1”,
“prev_hash”: “a91b…2c”
}

Export hygiene

• One row per event (new/replace/fill/partial/cancel). Partial fills accumulate into a VWAP with remaining qty tracked.
• Include a data dictionary with units (lots/notional), timezones, and conversion rates used.
• Release both the platform export and the venue-native export (raw fills) so third parties can reconcile.

Reproducibility test (must pass)

• Given the event log + starting equity, an auditor should recreate equity, drawdown, fees, and slippage within stated tolerances. Any mismatch → provide a discrepancy report (which events, why).

Shadow mode

Purpose

• De-risk go-live by proving sizing, routing, and sync rules on your own venue before real money.

Two complementary modes

1. Paper-follow (real-time): consume live leader events, but issue no live orders. Record hypothetical fills using your venue’s live book (mid/last/quote) with the same price-band logic you would have used.
2. Historical replay: stream past leader events through the engine at original timestamps (T0 leader fill → T1 normalize → T2 route), then price them on your venue’s historical tape. Great for testing disconnect/recovery and idempotent keys.

Shadow acceptance criteria

• Sizing parity: follower hypothetical size within step/lot rounding vs intended algorithm across 100% of test events.
• Slippage profile: median/p95 within 10–20% of observed live for that venue/symbol/time.
• Sync correctness: zero double-entry, correct partial-close proportions, correct reduce-only behavior on netted venues.
• Caps behavior: no logged cap breaches; skipped trades carry explicit reasons.

Go-live checklist

• Lock engine version and parameter set used in shadow.
• Export a shadow summary (PnL net of hypothetical costs, slippage stats, reject/skip reasons).
• Keep shadow-on for the first live week in parallel (live + paper) to detect drift.

Venue-Specific Frictions (Crypto Perps vs FX/CFD)

Crypto specifics

Market microstructure

• Perpetual funding: 8h/hourly cashflows credited/debited based on your follower venue’s rate/timestamp (can differ from leader’s). Track funding APR and bake into net attribution.
• Maker/taker tiers: fees vary by tier and maker/post-only flags; queue priority is price → time. Post-only helps earn rebates but risks no-fill.
• Lot precision & min notional: contracts can be integer (contracts) or decimal (USDT-margined perps). Enforce qty_step, price_tick, and min notional pre-dispatch.
• Symbol fragmentation: BTC can be XBTUSD, BTCUSD-PERP, BTCUSDT-PERP, etc. Map tick size, contract size, margin currency per venue; normalize PnL to a reference currency.
• Auto-deleveraging (ADL) & insurance: liquidation behavior is venue-specific; keep a liquidation distance metric (in bps or ATRs) per open position.
• Funding windows & maintenance margin jumps: some venues widen requirements during high volatility—throttle new entries and reduce-only if margin ratio falls below tripwires.

Operational tips

• Co-locate (VPS/API) for active leaders; keep persistent websockets; pre-warm sessions.
• Use reduce-only for partial closes to avoid accidental flips on netted books.
• Maintain symbol-equivalence tables with venue-specific economics (fees, funding index, precision).

FX/CFD specifics

Venue rules

• Minimum lot & step size: e.g., 0.01 lot for majors; metals/indices differ. Round carefully on partials to avoid rejects.
• Swaps/rollovers: overnight credits/debits at broker cutoffs; weekend triple-swap days; show swap cost attribution per position.
• Weekend gaps: Friday close → Sunday open; apply max deviation (price protection) and gap-open rules to avoid poor fills.
• Dealer protections: max deviation and last look can reject or requote marketables; handle with retry/backoff and explicit logging.
• Contract variants: cash index CFDs vs futures CFDs have different tick values and roll behaviors; store contract specs and roll calendars.

Operational tips

• Prefer GTC for stops/limits but refresh around roll/holiday events.
• Keep per-symbol pip value tables and slippage caps (e.g., 0.5–1.5 pip majors; 5–15¢ XAUUSD).
• Separate open PnL and swap in attribution; evaluate leaders after these costs, not before.

Hedging & netting

Account models

• MT4/hedged: multiple tickets per symbol can coexist long/short; partial closes act on specific tickets; realized PnL tracked per ticket.
• Netted books (most crypto/futures & many CFD venues): a single net position per symbol; adds/partials change net; closes are reduce-only; realized PnL computed off the running VWAP.

Why it matters for copying

• Partial closes & scaling:
  • Hedged: mirror ticket-level proportions (keep mapping: leader_ticket_id ↔ follower_ticket_id).
  • Netted: compute percentage reduction of net; send reduce-only quantity that respects step/min-notional.
• Risk accounting:
  • Hedged: risk is per-ticket; caps applied on sum of tickets.
  • Netted: risk is on net notional; easier to monitor cluster caps.
• Stops/TPs:
  • Hedged: per-ticket SL/TP.
  • Netted: venue may support position SL/TP or require synthetic orders; ensure one set of reduces doesn’t cancel the other.

Migration rules

• If leader is hedged and follower is netted, translate ticket partials into net-percentage actions; keep a reconciliation layer to avoid flip-flops.
• Persist average price math correctly: VWAP for netted; per-ticket weighted averages for hedged.

Monitoring the Engine (What to Track Each Week)

Technical health

Core KPIs

• Uptime (platform core, adapters, follower endpoints): weekly target ≥ 99.9%; count distinct outage windows and longest continuous downtime.
• Dispatch delay (core → venue): track p50/p95/max of dispatch_time − ingest_time; same-region VPS targets p50 ≤ 150–250 ms, p95 ≤ 600–800 ms.
• Order reject rate: rejects ÷ submissions (exclude cancels). Keep < 0.5%; classify: price band, precision/lot step, insufficient margin, halt/venue.
• Re-sync count: how many automatic snapshot reconciliations fired; p95 0–2/day per follower. Spikes suggest link instability or adapter regressions.

Operational alerts

• Heartbeat misses ≥ N (e.g., 3–5) → switch to snapshot mode and raise DEGRADED.
• Reject rate > 1% for a leader/symbol over last 50 orders → quarantine new entries until cause is logged.
• Re-sync bursts (> 5 in 15 min) → freeze amendments; keep reduce-only closes.

Artifacts

• Weekly Health Report: uptime table, latency histogram, reject-cause Pareto, re-sync timeline with root-cause notes.

Execution quality

Measure correctly

• Slippage = follower_VWAP − leader_reference (signed by direction). Publish p50/p95/max in pips/bps per leader × symbol × session (e.g., London/NY/Asia).
• Fill rates: partial vs full; IOC/FOK outcomes; average number of book levels crossed for marketables.
• Partial-fill frequency: % of orders with multiple fills; carry VWAP and remaining qty correctly.

Targets & tripwires (rules of thumb)

• Scalper leaders: p50 ≤ 2–5 bps, p95 ≤ 8–15 bps; if exceeded for two consecutive weeks, either re-route, tighten price bands, or disable that leader for short holds.
• Swing/intraday: tolerate higher p95 but watch max events; repeated tail slippage usually means routing or protection misfit.
• Venue cost ledger: attribute arrival lag, spread/impact, fees separately; optimize the worst contributor first.

Tuning levers

• Post-only where feasible on exits; IOC for marketables to avoid deep queues.
• Venue hysteresis (don’t flip routes unless 5-trade rolling cost delta > X bps).
• Pre-trade price collars by symbol; widen only if reject storm > threshold.

Artifacts

• Weekly Exec Scorecard: top 10 slippage drags, venue comparison chart, before/after tuning diffs.

Risk drift

What to compare

• Actual vs target allocation: per leader and per symbol (notional or % equity at risk). Compute drift = |actual − target| / target.
• Cluster exposure: symbol/factor groups (e.g., USD majors, metals). Report HHI and share of total open risk by cluster.
• Per-leader drawdown (real-time): live DD vs cap; count DD breach events and stop-follow triggers.

Tripwires

• Allocation drift > 10% for 2+ snapshots in a week → force re-sync and investigate rounding/min-lot effects.
• Single-symbol open risk > cap (e.g., 0.5–1.0% equity) → block new adds; reduce-only largest legs.
• Cluster risk > portfolio cap (e.g., 2–3%) → queue entries; require diversity floor before new size.
• Margin ratio < threshold (e.g., 65%) or liquidation distance < Z ATRs → auto de-risk.

Artifacts

• Weekly Risk Map: heatmap of allocations, cluster bars, list of breaches (who/when/what action taken).

Change control

What to track

• Leader strategy flags: declared changes (timeframe, instruments, risk per trade), sharp behavioral shifts (turnover, hold time, ATR-normalized SL).
• Symbol coverage updates: new/retired tickers; contract spec changes (tick size, lot step, IM/MM).
• Contract roll calendar: futures expiries/rolls, ex-dividend dates, funding schedule changes.

Governance rules

• Any leader change → shadow mode for N trades or 1 week before restoring normal allocation.
• New symbol onboarding requires: mapping, precision table, price bands, risk caps, and a paper-follow smoke test.
• Version every routing/sizing parameter; logs must show who changed what, when, and why.

Artifacts

• Weekly Change Log: leader flags, symbol/contract diffs, upcoming rolls/dividends/funding windows with recommended actions.

Logs, Taxes & Compliance (Mechanics Only)

What logs to keep

Core ledgers (machine-readable, exportable CSV/JSON + human PDF):

• Signal log (leader side): ts_leader, seq, leader_order_id, symbol, side, type, qty, price, sl, tp, note.
• Order log (follower side): dispatch_ts, venue, follower_order_id, client_order_key, mapped_leader_id, side, type, tif, qty_sent, qty_filled, vwap, reject_code.
• Position log: point-in-time snapshots: ts, symbol, net_qty/notional, avg_price, uPnL, margin_used, leverage, liquidation_distance.
• Execution quality: arrival_price, fill_price, slip_price, slip_bps, spread_est, fees_bps, latency_ms(signal→send, send→ack, ack→fill).
• Fee ledger (by ticket & by day): commission, spread_est, funding/swap, borrow, conversion_fee, performance_fee, platform_subs.
• FX conversion ledger (if multi-currency): ts, from_ccy, to_ccy, amount_native, rate_src, rate_value, amount_usd_ref.
• Cap/risk checks: pre_trade_equity, free_margin_before/after, per_symbol_cap_result, cluster_cap_result, margin_tripwire(hit/clear).
• Change control: versioned config diffs (routing/sizing/caps), who changed what/when/why.
• Event integrity: rolling hash chain per day: prev_hash, day_hash, file_checksum.

Formats & retention

• CSV for bulk (+ JSON Lines for APIs). Time in ISO 8601 UTC; include follower timezone used for billing.
• Minimum retention 7 years (tax/audit). Immutable “finals” (WORM storage) for monthly closes; append-only daily deltas.

Exports (one-click)

• Per-trade CSV, daily PnL CSV, monthly statement PDF (human-readable with totals, HWM calc, fees), raw venue fills for reconciliation.

Mapping trades vs cash movements

Keep the books clean by separating:

• Trading PnL (realized + unrealized at cut-off) minus trading costs (commission, spread/slippage estimate if booked, funding/swap, borrow).
• Non-trading cash flows: deposits, withdrawals, internal transfers, rebates, interest, performance/copy fees, platform subscriptions, tax withholdings.

Ledger structure (suggested):

• Trades table (events): one row per open/partial/close; realized PnL computed from venue fills.
• Costs table: per-ticket and per-day accruals (funding/swap) linked by follower_order_id or position_id.
• Cash table: ts, type(deposit/withdrawal/fee/rebate/interest), currency, amount_native, amount_ref, fx_rate.
• Balances table (EOD): date, start_equity, net_trading_pnl, total_costs, performance_fee, cash_net_flow, end_equity, hwm_before, hwm_after.

Daily reconciliation flow (mechanical):

1. Import raw fills from venue → compute realized PnL by symbol/ticket.
2. Accrue funding/swap to positions by day; attach to the fee ledger (not to “trades”).
3. Convert all lines to a reference currency (e.g., USD) using a declared reference FX rate (e.g., NY close D-1 mid); store native + converted.
4. Roll to statement:
   End Equity = Start Equity + Net Trading PnL − Trading Costs − Performance Fee ± Cash Net Flow
   Verify against venue statement; any mismatch → discrepancy report with line IDs.
5. Lock the period: generate PDF statement + signed checksums of CSVs.

Classification rules (consistency > perfection):

• Performance/copy fees: applied at crystallization after trading costs; log base, rate, HWM delta.
• Rebates/affiliate credits: classify as cash income (non-trading), not as PnL.
• Conversion slippage (if you convert USDT↔USD, etc.): log as conversion fee, not trading cost.
• Corporate actions (dividends/splits/rolls): adjust quantities/prices; record separate adjustment entries with source docs.

Minimal statement fields (monthly PDF):

• Account IDs (leader/follower), valuation currency, timezone, cut-off.
• Starting/ending equity; deposits/withdrawals; net trading PnL; total trading costs (by category); performance fee (rate & HWM); final HWM; signatures/hashes.

For jurisdiction-specific tax mechanics and examples of cost-basis choices (FIFO/LIFO/average) and funding/swap treatment, see the detailed guide: copy trading taxes.

Quick Glossary (Mechanics Terms Only)

• Signal latency — The end-to-end delay from the leader’s fill (or event time) to the follower’s execution acknowledgement; decompose into leader→platform ingest, platform→follower dispatch, and venue ack→fill.
• Normalization — Converting leader events into a venue-agnostic schema (symbol mapping, tick/lot precision, contract size, margin currency, timezones) before routing to the follower’s venue.
• High-Water Mark (HWM) — The highest historical net equity (or cumulative net PnL) used to determine performance/copy fees; fees apply only to profits above this mark at crystallization.
• Equity-percent copy — Sizing method where follower size = (Follower Equity / Leader Equity) × Leader Size × Multiplier; auto-adapts to deposits/withdrawals.
• Partial close — Reducing an open position by a fraction of its size; implementations should preserve proportionality (ticket-level on hedged books; reduce-only on netted books) and respect min/step sizes.
• Re-sync — Periodic or event-triggered reconciliation that diffs follower state vs leader target and submits minimal actions (closes/reduces/cancels/opens) to realign after drift or disconnect.
• Slippage (bps/pips) — Price difference between follower VWAP and leader reference:
  • bps (basis points): (price_diff / reference_price) × 10,000
  • pips (FX): price_diff / pip_value (instrument-specific)
• Netting vs hedging —
  • Netting: one net position per symbol; adds/partials adjust net; closes are reduce-only; realized PnL off running VWAP.
  • Hedging: multiple tickets per symbol can coexist (long/short); partials act on specific tickets; realized PnL per ticket.
• Liquidation buffer — The margin headroom above maintenance requirement (often targeted at 1.5–2.0× MM) designed to absorb adverse moves/volatility spikes before margin calls or forced liquidation.

Related Reading (One-click, No Overlap)

• Beginner framing: Copy Trading for Beginners — Plain-English fundamentals: what’s being copied, basic sizing, and the core risks to watch first.
• Process steps: How to Start Copy Trading — A step-by-step setup flow: picking a platform/leader, wiring risk caps, and running a safe first week.
• Income framing: Copy Trading for Passive Income — Cash-flow mechanics (not promises): payout ladders, buffers, fee ordering, and maintenance rituals.

Join our Telegram channel for bite-size breakdowns of copy-trading mechanics—sizing recipes, routing/latency tips, risk-cap templates, and weekly exec scorecards. No signals, no hype. Just the plumbing.
👉 Join on Telegram: https://t.me/bestcopytradingcom