The dangerous failure in a copier is not a rejected order. A rejection is loud, it has a reason attached, and somebody looks at it. The dangerous failure is a terminal that stopped being logged in on Tuesday and produced nothing at all for eleven days, during which the trader assumed a slow fortnight in the channel.
Why this shape of failure exists at all
Each connected trading account gets its own MT4 or MT5 terminal running on SINGUARD infrastructure, logged in with the credentials the trader supplied. A terminal that is running and logged in places orders. A terminal that has lost its session does nothing, and doing nothing throws no error, because nothing was attempted.
That is a real cost of the architecture, and it is one we accepted on purpose when choosing to run terminals rather than rent an execution API. Owning the path means owning the operational work, and the terminals need supervision continuously, not only when the last order failed. The wider argument for the choice is in running our own terminals.
The four things that break a working connection
In rough order of frequency. You change the account password in the broker's client portal and forget the copier is holding the old one. The broker migrates the account to a new server, which is routine and always announced in an email nobody reads. The account is archived for inactivity, which some brokers do to demo accounts after a few weeks. Or the broker restricts the account for a compliance reason of its own, in which case no software fix exists on this side.
Each surfaces the same way: the connection reads as failed. The first two are fixed by re entering credentials or the new server name, and the server name is the field people get wrong, because it is a string like BrokerName-Live07 that appears in the platform's list and not in the welcome email. That detail and the rest of the connection process is in connecting a trading account.
A connection has a state you can look at: logged in, rejected, or disconnected. That is a direct consequence of the terminal being ours. A copier that hides execution behind a vendor API can generally tell you only that a trade did not happen.
What happens to signals that arrive while an account is down
They are recorded as not placed, against that account. That record is the entire point of the design. A gap in a statement with nothing explaining it becomes a theory about the channel, and the theory is usually wrong. A gap with eleven entries reading connection failed is a fact you can act on in five minutes.
The recording is per account, which matters when several accounts are connected. A trader running a live account and a demo on the same channels will see the demo continue while the live one is down, and that asymmetry in the month's statements is explained by the record rather than by the channels. Comparing two accounts honestly is most of the value of running the second one, as set out in scaling lots between accounts.
Positions that were already open
This is the part worth being precise about. A stop or a take profit attached to an open position sits on your broker's server as an order and is executed by the broker at the price it touches. It does not depend on the terminal being connected at that moment. So a position with a stop is still protected by the broker while the connection is down.
What is suspended is the discretionary management: a partial close as a target is reached, a stop moved to entry after a target, a trailing adjustment, and any follow up amendment the provider posted in a reply. Those run on a sweep every thirty seconds through the terminal, and a terminal that is not there does not sweep. This is the strongest practical reason to set the stop rules so they mean something on their own rather than assuming management will always arrive, which is the argument in keeping stops in sync.
What recovery looks like, and what it deliberately does not do
When a connection comes back, the terminal reports the account and its open positions as they actually are rather than as they were assumed to be. Reading the state back from the account rather than from a memory of what was sent is a design rule throughout the bridge, and this is the case that justifies it: after a gap, what was sent is no longer evidence of anything.
Trades that were missed during the gap stay missed. Firing a backlog of entries into the market on reconnection would place trades at prices that have nothing to do with the signals that produced them, which is worse than the gap it was trying to repair. A signal recorded as not placed is closed as an event.
What a trader can do about it
Three habits. Update the copier when you change an account password, in the same five minutes, since that is the most common break by a wide margin. Read the broker email about a server migration, or at least keep the connection state where you will notice it. And treat an unusually quiet week as a question rather than a conclusion, because a quiet channel and a dropped terminal look identical from a distance and only one of them is fixable.
Leveraged trading carries a high risk of loss. A copier that is running places orders on your account under rules you set, and a copier that is not running places none, which is a different risk and not a smaller one.
"Absence of activity is the failure that costs people the most, and it is the one nobody thinks to build a monitor for until the first time it happens to a client."
— Alex Onta, Executive Director, SINGUARD
Key Takeaways
- A logged out terminal produces no errors and no orders, so it looks exactly like a quiet week in the channel unless the connection state is monitored.
- The four common breaks are a changed password, a broker server migration, an archived demo account, and a broker restriction.
- Signals that arrive while an account is down are recorded as not placed, per account, rather than passing silently.
- Stops and targets already on the broker's server continue to execute; what stops is discretionary management and follow up amendments.
Frequently Asked Questions
If the terminal drops, are my open positions unprotected?
Stops and take profits already attached to an open position sit on your broker's server and are executed there at the price they touch, so they do not depend on the connection. What pauses is discretionary management: partial closes at targets, break even, trailing, and any follow up amendment the provider posts.
Will missed signals be placed when the connection comes back?
No. Entering a backlog of trades at prices unrelated to the signals that produced them is worse than the gap. Signals that arrived while the account was down are recorded as not placed and left there, so the month's record shows exactly what happened.
What breaks a connection most often?
Changing the account password in the broker's client portal and forgetting the copier holds the old one. After that, a broker migrating the account to a new server, a demo account archived for inactivity, and a restriction the broker applied for its own compliance reasons.
About the Author
Alex Onta is an Executive Director at SINGUARD. He built eTrader, the terminal, the mobile apps, eTrader Broker, Copytrading, Business and Community, along with the worldwide clustered-server infrastructure it all runs on, with his brother Roman Onta helping on the design, and he leads that division today. Together with Roman he builds the Prop Firm CRM, the Broker CRM, Scalegram and CopySignals, and the two of them carry worldwide compliance, payment processing and international business structuring side by side. He lives and works in Dubai for most of the year. Meet the executive duo leading Singuard's five divisions.