Two EAs in netting: whose profit is the shared position?

On a netting account, two robots and manual orders can change one shared position. Its result does not automatically identify each robot’s result. Reconstruct the executions and their relationships, then choose an explicit analytical allocation convention. The example below produces different EA outcomes under two conventions while the account’s combined result stays the same. This allocation is for analysis; it does not replace broker history or establish tax accounting treatment.

Why does a magic number not split the shared position?

MT5 netting maintains one position per symbol, whose quantity can change through subsequent fills. One order can also produce several deals, the records of execution. These distinctions are described in the platform’s basic principles. Different program names do not create separate portfolios inside a shared account.

DEAL_MAGIC identifies the execution’s magic number; DEAL_REASON describes its source or cause. They are different properties. Deal documentation also provides the order number, position identifier and timestamp. Magic zero alone is insufficient evidence of a manual decision. Preserve related records and the agreed mapping between program names and identifiers.

A manual exit can reduce exposure previously built by both A and B. The closing deal’s label does not tell you which earlier quantity you will regard as closed. That requires a declared analytical rule. Our EA guide addresses basic position selection; this article reconstructs one shared position’s history rather than creating a separate account for each program.

How do you connect a deal, order and position without guessing?

Store numbers as identifiers, not quantities for calculation. Connect DEAL_ORDER to its order and DEAL_POSITION_ID to the position cycle. POSITION_IDENTIFIER links the history; the current POSITION_TICKET can change through server service operations. Preserve the symbol, direction, quantity, fill price and timestamp for each actual execution.

HistorySelectByPosition selects order and deal history using the position identifier. Check that retrieval succeeded and the export covers the intended records. A list visible in one terminal window may not contain everything required for your analysis. Do not assign a missing entry to an EA solely from a closing comment. Preserve the original record before adding interpretations.

Include commission, fees, financing and result in account currency. Separate balance operations from buy and sell executions. For a split order, record the actual partial quantities and their prices; requested quantity cannot replace filled quantity. The MQL5 article develops execution-event handling and identifiers. Here, the input is a reconciled history rather than an order-submission instruction.

How can one account produce two different EA results?

Analytical FIFO closes the oldest quantity first. Allocate manual exit 7003 to A: 10,000 × (1.1010 − 1.1000) = 10 USD. Allocate exit 7004 to B: 10,000 × (1.1030 − 1.1020) = 10 USD. Assign each EA its entry commission and the exit commission for its quantity. A receives 8 USD and B receives 8 USD.

Analytical LIFO closes the newest quantity first. B receives −10 USD of price P/L from 7003, while A receives 30 USD from 7004. After costs, B has −12 USD and A has 28 USD, again totalling 16 USD. FIFO and LIFO are our analytical conventions here, not a statement about MT5 server accounting or a universal tax rule. Do not silently change conventions when evaluating a robot.

Why does analytical realised P/L differ after the first exit?

After 7003, assume the current Bid is 1.1010. The model’s shared net position has 0 USD realised and 0 USD unrealised price P/L. Analytical FIFO realises 10 USD for A, but B’s remaining quantity has an unrealised loss of 10 USD. Together, 10 − 10 = 0 USD. Comparing analytical realised results alone with the server’s realised field is incorrect while the position is still open.

After three fills, commission totals 3 USD. Both representations therefore have a combined result of −3 USD at this price. Once 7004 closes the cycle, unrealised P/L disappears and the total allocation is 16 USD. Our floating versus realised P/L article explains these measures. Matching totals does not select the more appropriate convention for your analytical purpose.

Real histories may contain partial fills, reversals, corrections or separately posted charges. When a record is missing, leave the affected allocation unresolved and state why. Do not invent an opening price or instruction source to force reconciliation. Use a consistent convention across cycles when comparing strategies; label any change as a change in analytical method. Account controls and each robot’s limits still apply to the actual shared exposure.

What to do before evaluating two robots?

1. Select a completed cycle for one symbol and preserve its original export. Link deals to orders and the position identifier. Reconcile actual quantities and all charges. Do not open a new live trade solely to manufacture an example for this analysis.
2. Declare the quantity and cost allocation convention before calculating robot results. Label execution sources separately from the analytical owners of quantities. Leave missing information unresolved instead of treating the closing magic number as a complete account of earlier entries.
3. Reconcile a closed cycle’s combined result with account history. For an open cycle, combine realised and unrealised P/L at the same price. Preserve both views in your trading journal. Allocation analyses behaviour; it does not establish future profitability.