Trade Copier Desynchronization:
Detect, Reconcile and Recover

Trade copier desynchronization means the source and follower no longer show the intended corresponding trading state. The difference may involve a missing submission, rejection, partial fill, quantity or symbol mismatch, unmatched close, protection-order difference or an outcome that is still unknown.

Do not repair a mismatch by blindly repeating the last instruction. First identify what the source intended, what the copier recorded, what the destination accepted or executed, and what exposure exists now.

Define the mismatch at the record level

An order, a deal and a position are not interchangeable. MetaTrader’s basic trading principles distinguish an instruction, an execution and resulting exposure. cTrader’s positions and deals documentation provides another platform-specific example of separate position and execution records.

“The trade is missing” is therefore incomplete. State which record is missing and on which account:

• The source event exists, but no eligible copier event is visible.
• The copier event exists, but no destination submission is recorded.
• A destination order exists, but it was rejected, canceled, expired or remains working.
• One or more deals exist, but cumulative filled quantity differs from the intended amount.
• Deals appear consistent, but the resulting position differs because of account mode, another order or a later manual action.
• Quantity matches, but symbol, direction, protection settings or price evidence differs.

Recognize the common desynchronization patterns

A raw event-count difference is not automatically an exposure mismatch: one order can generate multiple partial-fill records. Equal counts also do not prove equality when quantities, directions or symbols differ.

Follow a source-to-follower incident sequence

1. Pause the diagnosis at a known time. Record the current source and follower exposure before making a manual change.
2. Name the intended action. Capture source account alias, exact instrument, side, action, requested quantity, order type and protection instructions.
3. Collect copier evidence. Preserve the source event, configuration version, mapping, sizing result, filters, destination submission and any error or response.
4. Collect destination evidence. Preserve native orders, every linked deal or fill and position snapshots.
5. Match stable identifiers. Use request, order, deal, position and correlation IDs without assuming they are the same.
6. Reconcile quantities and states. Sum valid linked fills, flag duplicates and leave an unsupported remainder unresolved.
7. Classify the difference. Record the factual exception and which evidence is missing.
8. Use the supported recovery route. Follow current provider documentation or contact support with redacted evidence. The generic process here does not issue orders.

Use explicit timestamps with a UTC relationship. RFC 3339 describes the date-time format used by the worksheet. Do not invent subsecond precision that the source did not provide.

Why a timeout must remain unknown

MetaQuotes states that a successful request return is not itself proof of execution, and the inverse is also important: a missing response does not establish that no execution occurred. OnTradeTransaction documentation describes asynchronous events that can follow one request.

Retrying an uncertain action can create a duplicate when the first action actually succeeded. AWS discusses the general distributed-systems reason for designing safe, idempotent retry behavior. That source does not verify a specific copier implementation. For a trading incident, the destination’s actual order, deal and position evidence controls the diagnosis.

Work through a hypothetical partial-fill mismatch

Suppose a source instruction requests a 1.00-lot buy. The follower shows deal A for 0.40 lot at 1.1001. The copier then records a timeout, and no later response is present in the local view. At this point the evidence supports 0.40 lot executed and 0.60 lot unresolved. It does not support “rejected,” “fully filled” or “safe to resend.”

If a later destination deal shows 0.60 lot at 1.1003 and both deals link to the same order, total executed quantity is 1.00 lot. The weighted price is ((0.40 × 1.1001) + (0.60 × 1.1003)) ÷ 1.00 = 1.10022. Reconcile the resulting position and account mode before marking the group complete.

If the destination position instead shows 1.50 lots, inspect other orders, manual actions and duplicate submissions. Do not force the ledger to balance by editing quantities without evidence.

Use a redacted incident ledger

The orders, deals and positions reference includes a visible field dictionary, blank generic CSV ledger and sanitized worked example. The files keep source, router and follower records on separate rows.

The worksheet is not a TradeCopier import/export schema and does not send, cancel or repeat orders. Use account aliases. Remove credentials, access tokens, private keys and unnecessary personal data. Review cells beginning with spreadsheet formula characters before opening untrusted data in spreadsheet software.

Reduce repeat incidents with controlled tests

• Verify exact source and follower symbols, contract size, quantity unit, minimum, maximum and step.
• Test open, modify, partial close, full close, protection changes and pending-order cancellation in a permitted demo environment where available.
• Test netting and hedging account behavior separately.
• Record configuration and connector versions with each test.
• Define who can pause copying, who reviews an alert and how open exposure is checked.
• Keep product logs and broker records long enough to investigate a delayed or asynchronous outcome.
• Retest after a platform, broker, connector, mapping or sizing-rule change.

TradeCopier activity logs describe current product context for reviewing operational events. Confirm the exact record fields and retention available for your plan and connection. Product access does not establish permission under a broker or prop-firm agreement.

Escalate with a complete, safe incident record

Provide a support team with the affected route, approximate UTC window, account aliases, platform and connector versions, exact symbols, intended action, redacted request/order/deal/position IDs, native codes, current exposure and the steps already taken. State whether any manual action occurred after the mismatch.

Do not send passwords, private keys or full account credentials. If live exposure remains uncertain, use the broker’s and product provider’s current supported procedures. This article explains evidence collection and reconciliation; it cannot decide or execute a position change for a specific account.

Primary references

• MetaTrader 5: orders, deals and positions
• MetaQuotes: OrderSend result semantics
• MetaQuotes: OnTradeTransaction
• cTrader: positions and deals
• AWS Builders’ Library: making retries safe with idempotent APIs
• IETF RFC 3339: Date and Time on the Internet

Sources were checked on September 21, 2026. Platform states and product behavior can change; use current documentation for a real incident.