MT5 rejects a close under FIFO — what should I check?

A FIFO closing rejection in MT5 means you must check the position order permitted on the actual account. FIFO, or “first in, first out”, can be a server constraint rather than your chosen journal allocation method. Do not automatically resend the same close or close an older position without checking the plan. Preserve the reply, account mode and current positions in that exact symbol first. This rule does not automatically apply to every platform user or every jurisdiction.

Which FIFO: the account rule or your analysis?

MT5 exposes ACCOUNT_FIFO_CLOSE. True indicates closing a symbol's positions in opening order, oldest first; outside hedging accounting mode this property is false. The reading describes the actual account rather than the country selected for interface language. Establish the provider and account conditions instead of assuming that MT5 imposes FIFO everywhere.

Separately, FIFO can be an analytical convention allocating a reduction to earlier entries. You can use such a convention when analysing one shared netting position, but a spreadsheet does not change which close the server accepts. The netting strategy-attribution guide covers allocation. This article concerns the technical order of closing actual positions.

What should you inspect after a rejection?

Read the complete request reply. Code 10045, TRADE_RETCODE_FIFO_CLOSE, identifies rejection associated with the account's FIFO setting. A generic closing-error label cannot distinguish order from price, volume or connection problems. Do not confuse it with a separate restriction on opposite positions or an instrument's close-only mode.

Record server, an account alias, exact symbol, position ticket, opening time and current volume. Sort only that instrument's positions by time rather than profit. A display sorted by another column does not establish precedence. If visible timestamps are identical at the displayed resolution, preserve identifiers and clarify ordering with the provider instead of inventing a ticket-number rule.

What does a three-position sequence look like?

In this model, requesting P3's closure before P1 violates the sequence. After P1 is confirmed fully closed, P2 is next rather than P3. P2 has the largest profit but was not initially the oldest. Smallest volume does not select the next position either. Read the actual state after execution to confirm which remaining position now comes first.

Total profit before closing is 80 USD. With prices fixed, closing P1 gives 30 USD realised and 50 USD floating on P2 and P3. After also closing P2, those amounts are 70 and 10 USD. The model sum remains 80 USD; its allocation changes without creating another profit. Actual fees and price changes can alter these numbers.

Why not replace the request with a close of the oldest position?

You may want to exit a specific position because it belongs to a separate plan or EA. Automatically closing a different position changes that plan even if the request satisfies the account constraint. Confirm the intended symbol, direction, quantity and effect on total exposure. If account conditions conflict with the plan, diagnosis may require reorganising the trading process rather than immediately sending a substitute transaction.

Do not try to bypass the restriction by opening an opposite position. Hedging can create new exposure, and the account may also prohibit opposite positions. After a partial close, read remaining volume and ordering again. Sending a request does not establish that the oldest position disappeared completely. The order-error guide explains reconciliation after uncertain replies.

A queue prepared before sending is only a plan. Another accepted operation can change the account before your next request, so keep the planned sequence separate from confirmed execution records. If a close fails, preserve that failure and re-read state rather than continuing with ticket assumptions from an old table.

Mark whether a person, EA or server-side mechanism initiated the operation. The symbol alone does not identify the request source. This helps compare the planned queue with actual history and avoids blaming a manual close for an unrelated server event. Preserve uncertain outcomes explicitly rather than treating every request in an old table as confirmed.

Does FIFO affect stops and bulk closing too?

MT5 Help for FIFO accounts describes linked stop-loss and take-profit levels across positions in the same instrument so exits preserve order. Do not assume each position can have wholly independent protection on that account. After changing a level, inspect the values actually accepted for every related position.

The same documentation describes sequential FIFO closing and interruption when an error occurs. A bulk command does not establish that all positions closed. Preserve replies and inspect positions still open instead of resending the entire set. Stop-out liquidation needs its own account-specific check; our example does not prescribe forced-liquidation order for every provider.

“positions can only be closed by FIFO rule” — MetaQuotes, MQL5 Reference, ACCOUNT_FIFO_CLOSE description; accessed 13 October 2026.

What to do tomorrow

1. Preserve the reply and account setting. Record the complete retcode, exact symbol and ACCOUNT_FIFO_CLOSE value on the relevant account. Keep this separate from your chosen transaction-analysis method. Do not include personal details or a password in the diagnostic record.
2. Build a queue from actual state. Make a table for that symbol with identifier, opening time, direction, volume and accepted protection levels. Mark the oldest position and uncertain replies. Reconcile history before another request instead of sorting positions by profit or assuming an old queue remains valid.
3. Check the model without live orders. Recalculate P1, P2 and P3, including the 30/50 USD split after the first closure. To reproduce platform behaviour, use a matching demo and inspect every outcome. This guide does not recommend closing any particular position.