There are two ways a stop-loss can live. Either it sits at the broker, on the broker's matching engine, attached to your order ticket as a resting order that the broker is contractually obligated to honour. Or it sits on a piece of software somewhere — your laptop, your VPS, a copy-trading service, a third-party EA — that monitors price and submits a close order when it thinks the stop should fire.
Only the first is a stop-loss. The second is a wish that the rest of the stack stays online long enough to convert the wish into an order at a price you'll accept. On a quiet day the two are indistinguishable. On the day a central bank surprises, a geopolitical headline crosses, or a flash event drains liquidity from the order book, they are not the same thing at all — and the gap between them is where the difference between a managed loss and an account-killing loss tends to live.
This article walks through the mechanics of how a stop actually executes in a fast market, why laptop-side monitoring fails the test, how the major broker platforms differ in their server-side stop semantics, what happened to PipSync's internal architecture to enforce broker-side stops as a non-negotiable, and the operational rules every active trader should be running today regardless of which platform they use.
How a broker-side stop actually executes
When you place a market order with an attached SL and TP at a broker, the SL and TP become resting orders on the broker's matching engine. They are not held in the broker's client app, not in a database somewhere — they are in the order book itself, alongside every other resting order from every other client. The matching engine processes incoming ticks against the resting order book continuously, and when an incoming tick crosses your SL price, the matching engine generates a market order to close your position immediately.
The latency between the price tick crossing your SL and the close order firing is sub-millisecond. The latency between the close order firing and the close fill being recorded is a few microseconds beyond that. Even during the worst news-minute liquidity gaps, the broker's matching engine fires the close. The variable is the fill price — slippage between your SL level and the actual fill is real and can be substantial — but the broker-side stop has actually fired, has actually generated a close order, and has actually flatten your position.
Now contrast with laptop-side monitoring. A monitoring script — whether it's an EA running in MetaTrader on your home PC, a Python script on a VPS, or a copy-trading platform's price-watch daemon — has a sequence of dependencies that must all succeed in the narrow window between the price tick and the desired close: the price feed has to arrive at the monitor; the monitor has to compute that the SL is breached; the close order has to be generated; the close order has to be transmitted to the broker over the network; the broker has to acknowledge the close order; the broker has to fill it.
Each step in that chain is a potential failure point. The price feed can lag a few hundred milliseconds during high-volume events. The monitoring script can be paused by an OS context switch, a garbage collector, or a UI redraw. The network can drop packets. The broker can throttle order ingestion during congestion. None of these is a routine failure — but they all happen — and when they happen together during a news event, the laptop-side stop fires seconds to minutes later than the broker-side stop would have, at a meaningfully worse price.
What "meaningfully worse" looks like in numbers
On EUR/USD during an ECB rate decision, the typical spread widens from 0.4 pips to 8-15 pips in the 30 seconds around the announcement. Liquidity in that window is roughly 10-20% of normal. A broker-side stop at 1.0900 would typically fill between 1.0895 and 1.0908 depending on direction and exact tick timing — a 5-8 pip slippage which is unpleasant but bounded.
A laptop-side stop monitoring the same level would, in the modal case, fire 200-500 ms after the broker-side stop would have. In that window the price often moves another 5-10 pips. The realized fill is 10-18 pips from the requested level — roughly double the broker-side equivalent.
In tail cases — internet drops at the wrong moment, OS pause during the event window, broker rejecting the order because the user account hit rate-limit — the laptop-side stop fires minutes later or doesn't fire at all. The realized fill in those cases can be 30-100 pips from the requested level. On a 1:30 leveraged position that's a 3-10% account loss for a stop that the user thought was protecting them.
These numbers are not theoretical. They are the pattern that appears in every broker's slippage analytics for every major news minute, every year.
How the major broker platforms differ on SL/TP semantics
MetaTrader 4 and 5
Both MT4 and MT5 support broker-side SL/TP as standard. When you submit an order via the platform with an attached SL/TP, the levels are placed in the broker's order book directly. Both platforms also support trailing stops, but the implementation of trailing stops varies: some brokers honour them server-side, others process them in the client and submit modifications. Trailing stops that depend on the client running are functionally laptop-side stops with extra steps. Read your broker's trailing-stop documentation carefully — "trailing stop" can mean either thing.
cTrader
cTrader's broker-side stops are first-class. Attached SL/TP land in the order book at order entry. cTrader also supports protected/guaranteed stops on some accounts (for an extra fee), which the broker guarantees against any slippage including over-weekend gaps. Guaranteed stops are the most defensive form of stop available to retail traders and are worth understanding even if you choose not to use them by default.
Interactive Brokers
IB's stop semantics are configurable. You can attach a stop that lives at IB's smart-routing system (server-side) or at the venue itself (also server-side, but with venue-specific behaviour). IB also offers algorithmic stop variants — adaptive stops, IB BookTrader stops — that have different latency and slippage profiles. The IB documentation is thorough; read it before assuming any particular default behaviour.
Crypto exchanges (Binance, Bybit, etc.)
Exchange-side stops on the major centralised crypto exchanges are server-side but have a notable quirk: many exchanges use the mark price (an index of multiple sources) rather than the last-traded price as the trigger for stops. This is intentionally protective — it stops a single thin-book wick from triggering stops everywhere — but it means that during fast-moving conditions, stops can fail to trigger when last-trade prices have moved well past them, or trigger when the last-trade price hasn't reached them. Read your exchange's stop-trigger documentation carefully and decide which trigger basis is right for your strategy.
What changed inside PipSync to enforce broker-side stops
Until early 2026, PipSync would accept orders without SL/TP fields and would either ask the user for confirmation or apply a default risk rule. The default rules were configurable per workspace and varied per source. The behaviour was technically correct — the user had configured the defaults — but the failure mode was that users frequently misconfigured their defaults or didn't realise that a particular source generated orders that fell through the default-rules logic.
The change: every routed order must carry an SL and TP that the broker actually accepts as part of the same ticket. If the broker rejects the SL or TP for any reason (stop distance below the broker's minimum, attached order out of valid range, account doesn't support the stop type), the entire order is closed and a structured failure event is written to the audit log with the broker's reason code. Silent fallback — "keep the order open without protection" — is no longer on the menu.
This breaks some setups. Specifically, a class of strategies that worked under the old behaviour — orders without explicit stops, relying on a server-side closure rule that watched for a time-based exit — no longer work without modification. The user-facing migration path is to encode the time-based exit as a TP at an explicit price level rather than as a separate close-after-N-minutes rule. The trade-off was deliberate: removing a class of risky silent-failure modes at the cost of breaking the legitimate-but-unusual setups that depended on them.
The trailing-stop trap
Trailing stops deserve their own section because they are the single most common place where retail traders unknowingly rely on laptop-side stops. The user sets a trailing stop in their MT4 client. The client shows the trailing stop is active. The user closes their laptop. The trailing stop stops working.
Broker-side trailing-stop support varies. Some brokers (notably most ECN MT4 brokers) do not support broker-side trailing stops at all — they show the feature in the client but the trail computation happens in the client. Other brokers support server-side trailing stops but with limitations (specific increments, specific trail distances). The PipSync solution: when a strategy wants trailing-stop behaviour, the platform implements it as a series of broker-side SL modifications at server-side intervals, with a clearly-documented latency floor. This is not as tight as a true server-side trail on the venues that support it, but it's tighter than client-side and doesn't depend on the user's machine being online.
Operational rules every active trader should run
- Verify, on every broker you use, where its stops actually live. Don't assume. Test by placing a small position, attaching an SL, closing your client, and confirming the SL still fires.
- Never use a trailing stop you haven't confirmed is server-side at your specific broker. If you can't confirm, treat it as a client-side stop and don't depend on it.
- On news events you're not trading, flatten or hedge positions before the event window starts. The broker-side stop will fire — but the slippage during a high-impact news minute can be substantial, and the cleaner strategy is often to not be exposed at all.
- Set hard daily-loss caps that are smaller than your worst expected single-event slippage. The daily cap stops you from compounding a slippage-driven loss with discretionary 'make it back' trades.
- For positions held overnight or over weekends, prefer guaranteed stops where available. The premium cost is meaningful but bounded; the gap-risk cost of an un-protected position is unbounded.
- Audit your stop-fill quality monthly. Most brokers provide slippage data. If you're seeing consistent worse-than-expected slippage on stops, your broker may be running suboptimal smart-routing, or your account type may not be eligible for the priority routing tiers.