What Happens to Brackets, OCO and Trailing Stops When a Copier Crosses Platforms

A copier crossing platforms cannot transmit a bracket, because there is no portable bracket object to transmit. What looks like one thing on the master's screen is three orders plus two relationships between them, and platforms store those relationships in different places. The copier reads the master's relationship, works out what the follower's venue can express natively, and rebuilds the closest equivalent from local primitives. Reconstruct is the accurate verb. Mirror is the marketing one.

Why is a bracket not a single order?

A bracket is two edges laid over three orders: a one-triggers-the-other (OTO) edge from the entry to the protective pair, and a one-cancels-the-other (OCO) edge between the stop and the target. Remove either edge and you do not have a damaged bracket. You have loose orders sitting near each other.

FIX states this structurally instead of leaving it implied. ContingencyType (tag 1385) is carried on list level messages, NewOrderList, ListStatus and ExecutionReport, rather than being a property a lone order can hold, and it enumerates 1 = One Cancels the Other, 2 = One Triggers the Other, 3 = One Updates the Other (OUO) with absolute quantity reduction, 4 = OUO with proportional quantity reduction, 5 = Bid and Offer, and 6 = Bid and Offer OCO. The relationship belongs to the list. Brokers and venues implement subsets of those six, and the subset your follower's venue implements is exactly what a copier has to work with. For what each order type does on its own, we covered that in futures order types explained. Everything below is about what happens to them in translation.

MetaTrader 5 sits at the opposite extreme: it does not model protective legs as orders at all. The MQL5 ENUM_ORDER_TYPE enumeration lists BUY, SELL, BUY_LIMIT, SELL_LIMIT, BUY_STOP, SELL_STOP, BUY_STOP_LIMIT, SELL_STOP_LIMIT and CLOSE_BY. Stop loss and take profit are absent from it. They appear instead as ORDER_SL and ORDER_TP inside the ENUM_ORDER_PROPERTY_DOUBLE table, which makes them numbers attached to something rather than orders in their own right. There is no trailing stop type in the enumeration at all. That describes the platform's order model, not whatever an individual MT4 or MT5 broker layers on top of it.

That is the cleanest proof of the translation problem available. On MT5 there is no order object to mirror and no OCO edge to copy, because the mutual exclusivity is implicit: only one of two price levels can be touched first. Copy that into a venue where stop and target are separate working orders and the copier builds both the pair and the cancel edge from nothing. Copy the other direction and it collapses two orders into two numbers. Neither direction is a mirror. For that specific pair, the mechanics are in our walkthrough on copy trading between MT5 and cTrader.

Which layer actually holds the cancel link?

Everything downstream is decided by this one question. If the relationship is registered at the broker or the matching engine, the platform can crash and the stop still rests in the book. If it exists only as logic inside a platform process or a copier process, it dies with that process, and the follower holds a naked position whose protection was an instruction in software that is no longer running.

NinjaTrader documents this distinction inside its own product surface, which makes it citable rather than theoretical. Its Simulated Stop orders are, in the documentation's exact wording, "held and simulated locally on your PC and are therefore subject to issues such as loss of internet connection and computer crashes", and it adds that "if market data stops flowing the SS order stops simulating". A simulated stop is not an order at the broker until it triggers. It is a price watcher on a desktop that needs the machine and the feed alive to work.

The same platform ships the other layer too. NinjaTrader's help guide on server side versus local ATM strategies describes server side ATMs as "exclusive to the NinjaTrader connection", states they are disabled if multi-provider mode is enabled, and gives the visible tell: the stop and target sit as suspended orders, identified by a plus symbol next to the order quantity, before the entry has filled. That page also describes the feature as currently in beta, so treat availability as a snapshot. The structural lesson does not move. The same bracket on screen can live at two different layers inside one platform, and which layer you get can change purely as a function of which broker connection you are on.

MetaQuotes splits a single position across two layers and says so plainly. Its platform documentation states that the Trailing Stop is executed in the trading platform rather than on the server, unlike Stop Loss and Take Profit, and therefore will not work if the platform is off. The same page notes that for one position a Trailing Stop cannot occur more than once every 10 seconds. So on one MT5 position, the SL and TP levels are server state that outlives your desktop and the trail is desktop state that does not. A copier reading that position sees three numbers of equal apparent authority, and only two of them are backed by the trade server.

Do not infer the layer from the interface. A stop drawn on a chart looks identical whether it rests at an FCM, sits in a broker-hosted strategy service, or runs as a watcher on your desk. Whether bracket relationships live in the matching engine or only above it varies by venue and account type, so ask your FCM directly.

The mechanism is a stack. Three order boxes (entry, stop, target) sit above four layers: matching engine, broker, platform process, copier process. The OTO arrow and the OCO cancel edge are held by exactly one of those layers, and from above the bracket looks identical in all four cases. Kill any layer below the one holding the edge and nothing changes. Kill the layer holding the edge and the stop, the target and the link between them vanish together, while the position stays exactly where it was.

What is the double-fill risk in synthetic OCO?

When the follower's venue has no native OCO, the copier implements cancel-on-fill itself, and that cancel cannot be simultaneous with the fill that triggers it. A window opens when the first leg fills and closes when the broker acknowledges the cancel of the second. Inside that window both protective orders are live working orders in the book. In a fast market, both can fill.

A double fill does not leave you flat. Take a follower long 3 contracts on an ES-like instrument with a synthetic stop and target pair. The target fills. The copier receives the fill event, sends the cancel for the stop, and waits for the acknowledgement. Inside that gap the stop fills too. The arithmetic is 3 - 3 - 3 = -3. The follower is now short 3 contracts, opposite the master, with no protective orders on the position, on a trade nobody opened. At $50 per index point that is 3 x $50 = $150 of unintended exposure for every point of adverse movement.

Native OCO held in the matching engine closes that window, because the sibling is cancelled as part of processing the fill rather than as a later action. OCO maintained one layer up, at a broker or a hosted strategy service, narrows the window rather than removing it, since the cancel is still a separate step. Copier logic widens it further, because the fill event has to cross the network first. Push protective orders as far down that stack as the follower's venue allows. And do not accept a vendor's latency figure for the window. Measure the interval on your own stack, from fill event received to cancel acknowledged, because that interval is the entire size of the risk.

Why are trailing stops the hardest order type to copy?

Because a trailing stop is a rule, not a price. The rule is "maintain the stop N points from the best price reached", and a rule only travels between platforms if the destination can express the same rule. Mirroring the rule sends one instruction and requires the follower's venue to support an equivalent native trailing rule with the same trigger increment. Mirroring the resulting price works anywhere and turns one master order into a continuous stream of modify messages, one per advance of the trail.

The message counts decide it. A master trails by 8 points on a venue whose trail advances in 0.25 point increments, price moves 10 points in the master's favour, so the stop advances 10 points. Price mirroring costs 10 / 0.25 = 40 modify messages for one trailing stop on one trade. Across 5 follower accounts that is 40 x 5 = 200 modify messages for a single favourable move on a single master order. Change only the trigger increment to 1.00 point and it becomes 10 / 1.00 = 10 modifies per account, or 10 x 5 = 50 across the book, a reduction of 40 / 10 = 4x from a setting nobody thinks of as a risk parameter. Rule mirroring costs one message per account, 5 in total, no matter how far price travels.

Two hundred modify messages to hold one stop in place is two hundred messages you no longer have when you need to flatten in a hurry.

That is the tradeoff: 5 messages plus a venue dependency, against 200 messages with no venue dependency and a continuous draw on a finite API rate allowance. Check your own venue's published limits, because the allowance you burn holding a trail is the allowance you need free during a liquidation. The degradation path matters too. A trailing rule mirrored into a venue with no native trailing rule quietly degrades into price mirroring whether or not the trader is told, and whatever recomputes it becomes one more piece of software the follower's protection depends on. That is the MT5 case above: no trailing type in the order enumeration, and a platform-side trail that stops advancing when the platform stops running. Trigger increments compound it, because two venues both running "trail by 8 points" with different increments produce different stop prices over the same price path.

The two paths split at the copier. On the rule path, a single arrow leaves the copier for the follower's broker, and the broker's own trailing engine holds the stop and advances it locally from then on. On the price path nothing ever reaches a trailing engine: the copier recomputes the level on every increment and fans a modify message out to each follower account, and every one of those arrows passes through the same API rate allowance bucket that a flatten command has to pass through.

How does quantity translation break protective legs?

It breaks by rounding each protective leg independently instead of rounding the total once. Take a master long 7 contracts with a scaled exit of 3, 2 and 2 (summing to 7), and a follower at a 0.35 size ratio. The entry is 7 x 0.35 = 2.45, which rounds to 2 contracts. Scale each target leg separately and you get 3 x 0.35 = 1.05 rounding to 1, 2 x 0.35 = 0.70 rounding to 1, and 2 x 0.35 = 0.70 rounding to 1. The legs sum to 1 + 1 + 1 = 3 contracts of sell orders against a position of 2. If all three targets fill, the follower does not go flat. It ends up short 1 contract with nothing protecting it.

The fix is arithmetic, not configuration. Round the total once, then distribute whole contracts across the legs: (3 + 2 + 2) x 0.35 = 2.45 rounds to 2, and those 2 contracts are allocated across the three legs as 1, 1 and 0, summing to exactly the position. Same inputs, same ratio, and the only difference is where the rounding happens. Rounding policy (nearest, floor, ceiling, or round-total-then-distribute) varies by product, so check which one yours applies rather than assuming.

Partial fills are the same failure in different clothes, which is why FIX defines OUO separately from OCO. A master is long 10 with a 10 lot stop and a 10 lot target linked as OUO with absolute quantity reduction (ContingencyType value 3). The target partially fills 4. Under OUO the stop is reduced by the same absolute amount to 10 - 4 = 6, matching the remaining position exactly. Translate that into a venue supporting only plain OCO, which carries no quantity linkage: the target fills 4, the position falls to 6, and the stop stays at 10. If that stop triggers it sells 10 against a position of 6, leaving the account short 10 - 6 = 4 contracts. The copier has to detect the partial fill and issue the reduction itself, and every millisecond before that modify is acknowledged is time spent over-protected by 4 contracts.

How does tick rounding silently change your risk?

A stop price legal on one venue is frequently not a legal price increment on another, so it gets rounded to the nearest permitted tick, and the rounded price is perfectly valid. Nothing reports an error. The trader chose a risk distance and the rounding chose a different one.

Work it exactly. A master runs a stop 7.30 points from entry on an index instrument quoted in 0.01 increments, the kind of contract-for-difference tracker an MT5 account holds. The follower is on E-mini S&P 500 futures, where the outright minimum tick is 0.25 index points, so 7.30 is not a legal distance there. 7.30 / 0.25 = 29.2, so the bracketing legal multiples are 29 x 0.25 = 7.25 and 30 x 0.25 = 7.50. That is 7.30 - 7.25 = 0.05 points below and 7.50 - 7.30 = 0.20 points above, and the gap between the two legal choices is 7.50 - 7.25 = 0.25 points. The E-mini carries a $50 per index point multiplier, so that gap is 0.25 x $50 = $12.50 per contract, exactly one tick. Which side of it the follower lands on is decided by a rounding rule rather than by the trader. Contract specifications do get revised, so confirm the current multiplier and minimum tick with the exchange for anything you actually trade.

In dollars per contract: intended risk is 7.30 x $50 = $365.00, rounding down gives 7.25 x $50 = $362.50, rounding up gives 7.50 x $50 = $375.00. Rounding down takes $365.00 - $362.50 = $2.50 less risk, 2.50 / 365.00 = 0.68% tighter than intended and therefore slightly more likely to stop out early. Rounding up takes $375.00 - $365.00 = $10.00 more, 10.00 / 365.00 = 2.74% above what the trader chose. On 10 contracts, intended risk is 10 x $365.00 = $3,650.00 against a rounded-up 10 x $375.00 = $3,750.00, a $100.00 difference on one trade. Across 20 follower accounts holding 1 contract each it is 20 x $10.00 = $200.00 of unchosen risk per trade.

The size is not the point. The direction is. A given rounding rule errs the same way on every trade and every account, so it never averages out, and it is invisible in every fill report you will ever read.

How do you verify a copied bracket actually exists?

Query the follower's account and read the broker's working orders, because every failure mode above is silent. A copier that reports a bracket it believes it created is reporting its own intention, not the broker's state, and those two diverge exactly when it matters. The check that counts is whether working orders exist at the broker, in the right direction, at a legal price, summing to the position quantity.

Three habits make cross-platform copying survivable. Where the venue supports native OCO or native brackets, use them even when the copier's synthetic version is more convenient. Run the verification on every copied entry rather than sampling, because failures cluster in fast markets where sampling is least likely to catch them. And treat trailing stops as the highest-risk order type to copy across dissimilar platforms, up to and including not copying them. If you are bridging futures venues specifically, the platform differences are laid out in our guide to copying trades across Tradovate, NinjaTrader, Rithmic and ProjectX.

When is copying only the entry the better design?

When the follower accounts sit on a dissimilar platform, copying only the entry and letting each account manage its own protective orders under locally defined rules is usually the more robust architecture. It gives up exact mirroring of the master's exit management, a real loss if the master's edge lives in discretionary exits. In exchange it removes the entire class of translation failure described here: no synthetic OCO window, no trailing rule degradation, no cross-venue tick rounding of stop prices, no leg quantity drift. The protective orders are native, server-resident and correctly ticked by construction, because the venue built them.

There is also a case where a cross-platform copier is the wrong tool outright. If the master's edge is primarily exit management, meaning discretionary trailing, manual scaling and targets relocated on the fly, and the followers sit on a platform with no equivalent native order semantics, the copier will reconstruct that exit logic imperfectly on every single trade. The reconstruction error is not a bug waiting to be fixed. It is the gap between two order models. Same-platform copying, or copying entries only, is the honest answer there.

Frequently asked questions