Proving What Your Copier Did: Audit Trails and Reconciliation That Survive a Dispute

Most copier logs answer a question nobody is asking. They record that follower account B ended the session holding 3 contracts, the one fact in the dispute everyone already agrees on. What a firm review or a divergence investigation needs is the chain that produced the 3: what the master filled, what the copier read, computed, rounded and submitted, and what the broker said back. An outcome-only log cannot reproduce that chain, and you find that out on the day you needed it.

Why do outcome-only logs fail exactly when they matter?

Because an outcome is equally consistent with a correct system and a broken one. "Follower B holds 3 contracts" proves nothing on its own. "The master filled 5, the configured ratio was 0.6, the computed size was 3.0, rounding was a no-op, and the broker acknowledged 3 at a stated price" makes every hop checkable by someone who does not trust you. Record decisions and inputs, because outcomes are the only part of the chain that cannot verify themselves.

Two situations need that record: a firm dispute, where you must prove what your system did and precisely when, and self-diagnosis, where a follower's equity curve pulls away from the master's over weeks and you need the node where divergence entered. Your trading journal tells you the result diverged. Only an event log tells you where.

Two failure modes are structurally invisible to outcome fields. A risk check that blocked an order and a signal the copier never received look identical, because both produce zero fills, and only a logged risk check with its compared value and pass or block verdict separates "the copier correctly refused" from "the copier never saw the trade." A symbol mapping error is worse. It produces a valid-looking fill on the wrong instrument or contract month, so the outcome field reads as clean execution. Only the applied transformation, logged as source symbol -> resolved target symbol -> contract month, exposes it.

The eleven fields every copy event should capture

A complete per-event record has eleven parts. Each one exists because a specific failure is invisible without it.

Two of these get skipped most often. Record sizing inputs as read, not as configured: if the copier sized off an equity of $52,180 at 09:31:04, the log must say $52,180, because reconstructing the decision from a later balance produces a different answer and makes a correct system look broken. And log the broker's order ID, not only your client order ID. Your client ID exists in exactly one place, your own records. The broker's ID appears in the broker's records and on the firm's statement, which is what lets two independent sets of evidence be joined.

Why pre-rounding and post-rounding size are two separate fields

Storing computed size before and after rounding is the highest-value line in the schema. Rounding is the most common source of silent divergence across a fleet, and it is invisible if you keep only the final integer, which always looks plausible: a whole number in a field that only ever holds whole numbers.

Clean case first. Master fills 5 ES long, ratio 0.6, computed size = 5 x 0.6 = 3.0. Rounding is a no-op, submitted size is 3, broker reports a fill of 3. Every hop verifies and nothing is inferred.

Now change one input. Master fills 3 ES, same 0.6 ratio, computed size = 3 x 0.6 = 1.8. Floor rounding submits 1. The realized ratio is 1 / 3 = 0.3333, so the follower carried 33.33% of the master's size against a configured 60%, and the shortfall on this single trade is 1.8 - 1 = 0.8 contracts. The chain forks at exactly one node. The master fill arrives, the receipt clock stamps it, equity and ratio are read, the multiply yields 1.8, and then the rounding node branches: one path floors to 1 and submits 1, the other rounds to nearest and submits 2. Everything downstream is identical in shape on both branches, same order submit, same broker acknowledgment, same fill message. Only the integer differs, and if the log stores only that integer, the fork is unrecoverable after the fact.

Repeat that trade ten times. Intended total = 3 x 0.6 x 10 = 18 contracts. Floor rounding delivers 1 x 10 = 10 contracts, a shortfall of 18 - 10 = 8 contracts, which is 8 / 18 = 0.4444, or 44.44% of intended exposure that never got copied. Switch to round-half-up and 1.8 becomes 2, so actual = 2 x 10 = 20 contracts, an over-copy of 20 - 18 = 2 contracts, which is 2 / 18 = 0.1111, or 11.11% over. Same configuration, same trades, opposite sign of error, decided entirely by a rounding mode that most tools never write down.

Put dollars on it. If each of those ten trades captured 4 index points on the E-mini S&P 500 (ES), whose multiplier is $50 per index point, intended P&L = 18 x 4 x $50 = $3,600 while the floor-rounded actual = 10 x 4 x $50 = $2,000. The difference is $3,600 - $2,000 = $1,600 the follower never earned, with no error, no rejection, and no log line indicating anything went wrong.

Rounding mode is a systematic bias, not noise, so it compounds in one direction across hundreds of trades instead of averaging out.

Futures copying is structurally worse for this than CFD copying, because futures contracts are integer-only and a computed 1.8 must collapse to 1 or 2. MT4, MT5 and most CFD platforms accept fractional lots, with the minimum volume step set per symbol by the broker rather than by the platform, so a 0.6 ratio usually lands close to exact. Check the step on your own symbol before assuming it. That is why a ratio behaving fine on a CFD account drifts the moment it points at futures, and why divergence across a fleet of followers so often traces back to a sizing decision nobody logged.

Micro contracts are the cheapest fix. The Micro E-mini S&P 500 (MES) is $5 per index point against the ES at $50, so 1 ES equals 10 MES. The computed 1.8 ES expressed in micros is 1.8 x 10 = 18 MES, already an integer, so the rounding error is exactly zero. The 44.44% shortfall above becomes 0% by changing the target instrument alone. Verify current CME contract specifications and whether your firm permits and scales micros before switching.

Timestamp discipline: two clocks, both in UTC

Record two timestamps per event: your own clock and the venue-reported clock, both UTC, both ISO 8601 with an explicit offset or trailing Z. A dispute about whether a fill fell before or after a reset boundary is decided by timestamps, and a log of local, ambiguous times is not evidence.

The two clocks are distinct in the protocols that carry orders. FIX defines TransactTime, tag 60, as a UTCTimestamp giving the "Time of execution/order creation" expressed in UTC, and keeps it separate from SendingTime, tag 52, the time of message transmission. Tag 60 is business time: when the transaction occurred, stamped by the party reporting it, so on an execution report it reflects the venue side rather than your machine. Tag 52 is session time: when a message left a machine. Conflating them is what makes a copier log useless, because the second drifts with your infrastructure and the first does not. Store both.

Local time carries ambiguity you cannot remove later. A 5:00 PM America/New_York reset is 21:00 UTC during EDT and 22:00 UTC during EST, so a log line reading "17:00:03" with no zone cannot establish which trading day a fill belongs to, and its meaning changes twice a year with no code change.

Now the drift case. A venue-reported fill at 2026-08-17T20:59:58.400Z against a reset boundary of 21:00:00.000Z precedes it by 21:00:00.000 - 20:59:58.400 = 1.600 seconds, so the fill belongs to the prior trading day. Suppose the copier's clock runs 2.5 seconds fast and the log stores only that clock. It records 20:59:58.400 + 2.500 = 21:00:00.900Z, 0.900 seconds after the boundary, so the identical fill now lands on the next trading day. Storing both clocks makes the offset provable. Storing one makes it silent.

Two more mechanics. Use the wall clock in UTC for absolute event times you will compare against a broker statement, and a monotonic clock for durations, because NTP can step the wall clock backwards and produce negative intervals. Store latency as its own field, derived from the two timestamps you already have: venue fill at 20:59:58.400Z, copier receipt at 20:59:58.610Z, latency = 610 - 400 = 210 ms. In a dispute that field separates "the copier was slow" from "the market moved."

That 2.5 seconds is not academic. If the prior day already used $2,300 of a $3,000 daily loss allowance, remaining room is $3,000 - $2,300 = $700. A $1,200 loss attributed to the prior day exceeds that room by $1,200 - $700 = $500, a breach. Attributed to the next day against a fresh allowance, it is not. Loss limits and reset times differ by firm and change, so verify yours against the firm's current rules document. The mechanism is universal.

What reconciliation is, and what it is not

Reconciliation is not logging. Logging records what you did; reconciliation periodically compares the copier's internal belief about each account's open positions against the broker's authoritative reported state, and resolves any difference explicitly instead of assuming the internal record is right.

It exists because event streams can drop or reorder messages, and at least one major platform documents that in its own reference. MetaQuotes states for MT5's OnTradeTransaction handler that "Priority of these transactions' arrival at the terminal is not guaranteed", that the transaction queue length comprises 1024 elements, and that if the handler takes too long on one transaction, previous ones can be superseded by new transactions in the queue. A copier trusting an event stream alone will eventually hold a wrong position count.

Run reconciliation at four moments: on startup, because internal state begins empty or stale; on reconnect, because events that occurred while you were away are gone; on a routine interval during the session; and after any order submit that timed out or errored ambiguously, because then you do not know whether the order landed. The primitive is built into the protocols, so skipping it is a choice. cTrader's Open API defines ProtoOAReconcileReq and ProtoOAReconcileRes, whose response returns the account's open positions and pending orders. FIX 4.4 offers Request for Positions and Order Mass Status Request for the same job.

The resolution rule is one sentence: the broker is the source of truth, and internal state is corrected to match it, never the reverse. A copier that "fixes" a discrepancy by firing corrective orders can double a position when the gap came from stale data during a disconnect. So split the two corrections. Overwriting the internal ledger should be automatic and should raise a human alert; auto-trading to close a detected gap belongs off by default or behind an explicit gate. Correcting your record is bookkeeping. Correcting the market position is a trade placed from data you just admitted was wrong.

A one-contract discrepancy, worked end to end

The copier believes follower account B holds 4 ES contracts long. The broker's position report says 3. The difference is 4 - 3 = 1 contract. The copier's belief came from two of its own records: order 1 submitted 2, order 2 submitted 2, internal total = 2 + 2 = 4. The broker's execution records show a fill of 2 on order 1 and a fill of 1 on order 2, with LastQty 1 and LeavesQty 1, the remainder later cancelled, so the broker total = 2 + 1 = 3. The copier logged its intent for order 2 and never the broker's fill quantity, the field that decides the case.

Four histories produce the identical outcome of "broker says 3", reaching the account along four different paths. One is a partial fill recorded as complete, arriving as an execution report with LastQty below the submitted quantity and a non-zero LeavesQty. Two is a fill missed while disconnected, identified by a broker execution whose timestamp falls inside the copier's recorded disconnect window. Three is a position the firm's or broker's risk engine closed, arriving as a broker-originated execution or cancel with no matching client order ID. Four is a manual trade placed directly on the account, with a different order origin and no copier record. Only a log holding the broker acknowledgment and fill separates them.

Leaving that gap unresolved has a price. The one unreconciled ES contract is unhedged exposure. At $50 per index point, a 10-point adverse move costs 1 x 10 x $50 = $500 on a position the copier does not believe exists and will therefore never manage, never close, and never include in a risk check. The discrepancy is not the loss. The invisibility is.

Retention, off-box storage, and the export you have never tested

Keep logs at least as long as the longer of your firm's dispute window and its payout-review window, and treat that as your floor. Both windows are firm-specific and change, so read the current rules document rather than assuming.

For a design analogue rather than an obligation, 17 CFR 1.31 requires a records entity to keep each regulatory record "for a period of not less than five years from the date on which the record was created" and to keep electronic regulatory records "readily accessible for the duration of the required record keeping period." A records entity is a person required by the Commodity Exchange Act or Commission regulations to keep regulatory records, which an individual funded trader running a copier is not. None of this is legal advice, and whether a recordkeeping rule reaches you is a question for a lawyer or compliance professional. Borrow the standard anyway: "readily accessible for the whole period" is a sharper target than "archived somewhere in a tarball."

Store logs outside the copier's own server. If that server fails, a log kept only on it destroys the evidence of what it did at precisely the moment you needed that evidence. Append-only, write-once storage is worth more than a bigger log, because a record that can be silently edited afterwards is weak evidence and a firm reviewing a dispute has no reason to weight it heavily. Ship records off-box on write, to object storage or a separate host.

Then verify the export path before you need it. Confirm you can produce a human-legible file, CSV or JSON lines, headers present, UTC timestamps, one row per event, over an arbitrary date range, and re-test quarterly. A log you cannot export is not a log. It is a database you hope someone will help you query in the middle of an argument. This belongs with the rest of your pre-live verification work: cheap to check on a quiet Tuesday, impossible to check under pressure.

What this costs, and when it is not worth building

Storage is not a real objection. Take a per-event record of roughly 400 bytes as a JSON line, six recorded events per copied order (master fill, sizing computation, risk check, order submitted, broker ack, broker fill), and a desk whose master produces 40 fills a day across 12 follower accounts. Events per day = 40 x 12 x 6 = 2,880, so bytes per day = 2,880 x 400 = 1,152,000, about 1.15 MB. Over 260 trading days that is 748,800 events and 748,800 x 400 = 299,520,000 bytes, roughly 300 MB per year uncompressed, and JSON lines compress well. Measure your own record size, because 400 bytes is illustrative. Tools ship thin logs not because of byte cost but because logging decisions requires the code to be structured around explicit decision points.

Latency is the honest tradeoff. Write all six records synchronously at an illustrative 2 ms per durable write and you add 6 x 2 = 12 ms to every copied order. Across a day that totals 40 x 12 x 12 ms = 5,760 ms, meaningless in aggregate, but the 12 ms sits on the critical path of every order, where it converts into slippage. The compromise is neither blocking the trade path nor skipping the record: append to an in-memory ring buffer or write-ahead log on the hot path, and flush asynchronously to off-box storage. You accept a small window in which a hard crash loses the last few records, in exchange for keeping fsync latency off every order. Measure the real per-write cost yourself, because it varies by orders of magnitude between a local NVMe fsync and a network volume.

There is a case where none of this is the answer. If you run two accounts and place three trades a week, broker statements plus a spreadsheet give you everything a copier log would, with no extra failure surface and nothing new to maintain. Audit infrastructure is justified by fleet size and dispute exposure, not by principle. Building it for two accounts is a hobby, not risk management.

And a limit that holds even at scale: your copier's log is your evidence, not the authoritative record. In a dispute, the firm's platform records and the broker's records are what the firm treats as canonical. A copier log wins arguments by being consistent with those records and by explaining causation, showing that a specific input produced a specific decision at a specific millisecond. It does not override them when they disagree. Build it to corroborate, not to contradict.

Frequently asked questions