MT5 Close all — why are some positions still open?

MT5 Close all is a sequence of requests, not a guarantee that the entire account closes simultaneously. Positions may remain after rejection, an interrupted sequence or closing the application. Establish what actually filled and what quantity still exists. This procedure concerns MT5’s built-in group operations; an add-on or custom EA may follow different rules.

What does the selected command cover?

Check the full name: all positions, only profitable ones, losing ones, a particular symbol or one direction. Selecting a position can change the commands offered. Saying that you closed everything without recording the command does not establish its scope. Do not confuse closing with reversing a position; reversal can create fresh exposure rather than leave the account flat.

The MT5 group-operation documentation separates stages: on hedging accounts, Close By is attempted first, followed by ordinary closures of remaining positions. An error during sequential Close By stops the process; in the later asynchronous stage, a rejected request leaves its position open without stopping requests for the others. FIFO closing is also sequential and stops on error. Distinguish the stages.

Group commands require One Click Trading. Certain commands are unavailable on FIFO-restricted accounts. Read the account’s position mode and ACCOUNT_FIFO_CLOSE in account properties instead of inferring them from the terminal’s appearance. These describe the particular account, not a worldwide legal rule.

Our hedging article explains opposite tickets versus a combined netting position. Close By concerns two opposing positions for the same symbol on a hedging account. A different instrument with a similar name is not automatically the opposite leg. Assess a custom Close all script using its own instructions, rather than assuming it behaves like MT5’s menu command.

How do you check five positions after one operation?

After pair A–B fills, the position count falls from five to three. The terminal then sends ordinary closures for C, D and E without waiting for each preceding confirmation. In our model C and E close, but D is rejected. The final state is one position D: a 0.10-lot USD/JPY sell. Three requests sent do not establish three completed closures.

The diagram’s conclusion: count current positions and confirmed closed quantity, not message windows. Close By removed two tickets through one operation here. Ordinary closing requests had separate outcomes. The order-error guide helps identify a rejection, but the account reading establishes the operation’s final state. Keep an unresolved outcome separate from a confirmed rejection rather than assigning both the same result.

For each ticket, preserve symbol, direction, starting quantity, request or order identifier, reply, deals and remaining volume. Deal properties expose links to the order and position. One order may produce several deals; do not treat every fragment as a complete ticket closure. Include timestamps with their zone and the reason an outcome remains unresolved.

What changes when an error or interruption occurs?

Consider a separate variant of the same starting state: pair A–B receives a Close By error before execution. We assume no closing deal occurred. The sequence stops before ordinary closures of C, D and E, leaving all five positions. This differs from D being rejected after a successful pair closure. In a real incident, a missing reply needs investigation rather than an assumption that nothing filled.

Closing the application terminates the group process. It does not undo confirmed deals. If A–B already closed while requests for C–E have not yet been sent, three positions remain in that variant. Determine the server outcome for requests already sent. Restarting the terminal does not confirm a flat account and should not automatically trigger another entire batch based on remembered quantities.

Check whether an EA, another application or another person opened new positions during the operation. A new ticket need not be a position whose closure failed. Match it with history, instruction source and time. In MQL5, OrderSend returning true does not establish execution; check result fields and events. This matters for custom automation and does not justify sending a trial live trade.

Does an empty position list finish the check?

Inspect pending orders too. MT5 provides separate deletion operations for them; a position-closing command does not confirm that pending orders were cancelled. A fictional pending buy P can remain after all five tickets close. If it subsequently executes, it creates a new position. The order-types guide distinguishes a cancellation request from its actual outcome.

After synchronization, read positions without a filter concealing a symbol or direction. Reconcile closing history and review pending instructions separately. Describe an empty state with its observation time and account scope. One screenshot cannot establish that an EA will never recreate exposure. Check protection on remaining positions as well; the original batch’s failure is not a reason to ignore their present risk.

A useful Close all check ends with a list of what still exists on the account. Counting requests sent cannot replace that list.

What should you do tomorrow?

1. Reproduce the command scope on demo. Record account mode, the full command name and every ticket and volume. Preserve the starting state. Do not test rejection handling on a live account; a model and a safe demonstration environment are sufficient for this investigation.
2. Match each position with its confirmed result. Separate Close By from ordinary closure. Label rejected and unresolved requests, then inspect current quantity. Do not resend an entire batch from memory or infer a fill merely because a button disappeared from the screen.
3. Finish by checking both lists. Inspect positions and pending orders on the correct account after synchronization, without concealing filters. If anything remains, assess present exposure and the actions available. Preserve the final state and observation time in your journal before considering the task complete.