A subscriber can receive the correct signal and still end up with the wrong position. The reason often lies not in the leader's logic, but between sending the order and its final state: timeout, partial fill, cancellation, retry, or a manual trade on the account.

To prevent such discrepancies from accumulating, the copytrading system needs a separate reconciliation. It compares the target position, known active orders, and the actual state of the exchange account. None of these sources alone can be considered a complete picture.

Three states of a single trade

After a signal, there are at least three different states.

System intention. What position the subscriber should have after applying copy coefficients, risk limits, minimum lot, and rounding.

Sent but not completed orders. These can already affect the position, even though the current volume on the account hasn't changed yet.

Exchange fact. Orders, fills, and position that the exchange returns via private streams and control REST requests.

If you compare the target only with the current position, the system may not notice an order in transit and send excess volume. If you rely only on the local log, it won't see a manual trade or a change that occurred after losing connection. Reconciliation must consider both sources.

Why the order creation response does not complete the operation

Exchange APIs work asynchronously. A successful response to a request usually indicates that the exchange has accepted the request for processing. The order status may change afterwards.

In Bybit’s documentation, to obtain open and closed orders, unfilled, partially filled, and recently completed states are specified separately. For real-time updates, the exchange recommends the private WebSocket order stream. Binance sends status changes and accumulated filled volume in the order update event. OKX's documentation also describes subscription to the order channel and transitions between live, filled, and cancellation states.

The practical rule follows: HTTP response, order events, and account positions are different evidences. For a final conclusion, they need to be linked by a stable identifier.

Timeout and dangerous retries

Timeout only means the client didn't receive a response in time. It doesn't show whether the request reached the trading system.

Two scenarios are possible:

  • the exchange did not receive the order;
  • the exchange received and even executed the order, but the response was lost on the way.

If you immediately retry without verification, in the second scenario a second order will appear. Therefore, trade integration usually uses a unique client ID and idempotent processing on its side. After an uncertain result, the system first looks for the order by ID or reconstructs it via history and event streams. A new order is needed only after classifying the previous attempt.

This is a general principle of reliable integration, not a statement about a specific internal implementation of CopyTrader.

Partial fills change delta calculation

Assume the subscriber's target position is 1.0 BTC, current actual position is 0.6 BTC, and an open buy order of 0.4 BTC is half filled.

If the exchange already included the filled 0.2 BTC in the current position, 0.2 BTC remains open. The considered state equals:

actual position unfilled remainder of active orders.

In the example, this is 0.8 0.2 = 1.0 BTC. An additional order is not needed.

If the system looks only at the position 0.8 BTC, it may send another 0.2 BTC and after the first order completes, get 1.2 BTC. Conversely, if it counts the entire original order volume on top of the updated position, the filled part will be counted twice, causing error for a different reason.

The exact formula depends on the position model, direction, hedge/one-way mode, and exchange contract. But the principle is the same: filled volume and open remainder cannot be mixed.

Order and position reconciliation loop

A practical reconciliation loop consists of several steps.

  1. Get target. Fix the target position after copy rules and subscriber limits.
  2. Take exchange fact. Get current position, active orders, and recent final statuses.
  3. Link identifiers. Match internal decision, client ID, and exchange order ID.
  4. Normalize state. Consider direction, filled volume, open remainder, quantity step, and position mode.
  5. Calculate discrepancy. Compare target with actual position and volume still executable.
  6. Classify cause. Timeout, reject, partial fill, cancel, manual trade, lost event, or settings change.
  7. Select action. Observe, cancel remainder, send corrective order, block auto-correction, or escalate case to operator.
  8. Check final state. After action, re-request exchange fact.

Automatic correction is not always appropriate. If the cause is unknown or external activity is detected on the account, it is safer to stop and show the discrepancy than to endlessly "chase" the target with new market orders.

Typical scenarios

Observation Possible cause What to check before retrying order
No response after sending timeout or lost connection client order ID, order history, and private stream
Status remains partially filled insufficient liquidity or limit price filled volume, remainder, validity, and current target
Order canceled manual cancel, IOC/FOK, exchange rule final status and cancel reason
Position differs without open orders manual trade, lost event, different position mode fill history and account settings
After retry volume exceeds target first attempt was accepted both order IDs and resend rule

The table helps start an investigation but does not replace the contract of a specific exchange. Status names and event orders differ.

What the user should see

A status of "trade copied" is insufficient. It combines several different states and creates false confidence.

It is more useful to show separately:

  • signal received;
  • order prepared;
  • order accepted by exchange;
  • partially or fully filled;
  • rejected or canceled;
  • position reconciled;
  • discrepancy detected and action required.

For disputed cases, a minimal log without secrets is needed: time, instrument, direction, requested and filled volume, average price, final status, and link to internal ID. API keys and other credentials should not appear in such logs.

How this material relates to other checks

Settings synchronization answers whether it's safe to send a copy of a trade with current account parameters. Slippage research shows why the same signal does not guarantee the same average price. Post-trade reconciliation solves the third task: whether the actual state matched what the system intended to create.

These checks do not eliminate market risk. They distinguish causes of discrepancies and provide the operator with evidence for correct action.

This material is educational and describes general principles of trading integrations. It is not a guarantee of specific execution, a characteristic of all connected exchanges, or investment advice.