What a one cancels the other order is

The pairing, and what links it 

One cancels the other describes a relationship between two resting orders rather than a new kind of order. Each half of the pair is an ordinary instruction of a type already covered in this module, a limit, a stop or a stop limit, and each behaves exactly as it would alone: it rests, it is monitored against one side of the quote, and it deals when its condition is met. What the pairing adds is a single consequence attached to that moment. The execution of either order is the event that cancels the other, automatically, with no further instruction from anybody.

The trigger is the fill, not the touch, and the distinction carries everything the limit order lesson established about levels that are reached and still do not deal. An order touched on the other side of the quote has not executed. An order touched by a single update that reverses immediately has not executed. In both cases nothing is cancelled, and the partner order continues to work exactly as before, because the pairing watches for an execution rather than for a price.

The pair most positions carry 

Nearly every one cancels the other relationship a retail trader meets is the same one: a stop order and a take profit order attached to a single open position, one on each side of it. The arrangement is conventionally called a bracket, because the two levels sit around the position. Both are closing instructions, both point in the same direction, and both are for the size of the position. The link between them is not a convenience feature. It is a structural requirement, and the reason repays stating exactly.

A position can be closed once. If those two closing orders were independent, the one that dealt would close the position and the other would still be resting, still valid, still pointing the same way. When price later reached it there would be no position left to close, so the surviving instruction would instead open a new one, in the opposite direction to the original, at a moment nobody chose. The pairing exists to make that impossible. It is also why closing orders are attached to a position rather than left loose in the pending list, and why both are removed together when a position is closed by hand.

When only part of one order deals 

A partial fill on one half of a pairing is where the conventions genuinely diverge, and the two answers produce different states from identical keystrokes. Under one convention the surviving order is reduced in proportion, so a position half closed leaves a partner order for the remaining half. Under the other, execution of any part of one order cancels the partner outright, which leaves the remaining part of the position with no resting instruction on that side at all. Which convention applies is a property of the platform and the firm, published in their documentation, and it is not inferable from the order ticket.

Both levels inside one movement 

Price does not always arrive in steps small enough to pass one level at a time. A gap at a weekly reopening, a scheduled release or a single violent update can carry the market beyond both levels of a pairing before either order has been processed. Nothing about the pairing breaks in that case, and the outcome follows from one rule: the orders are processed against the sequence of quotes, so whichever condition is met first executes, and the other is cancelled at that instant even though it too was passed. Distance from the position has nothing to do with it. The sequence of prices does.

A gap makes the second half of that rule visible. Where the market reopens beyond a level rather than trading down to it, the order that executes deals at the price available on reopening, not at the level written on the ticket, exactly as the stop order lesson described. The cancellation of the partner is unaffected by the gap. What the cancellation removes is an order, and it is not an assurance about the price at which the other one dealt.

Pairings that open rather than close 

The same relationship is sometimes written between two orders where no position exists yet. A buy stop resting above the current price and a sell stop resting below it, linked so that the one that deals removes the other, is the arrangement usually meant when a platform names an order type one cancels the other outright. Its structure is identical to the bracket: the fill of either half is the cancellation trigger, and the surviving half is removed unexecuted.

What differs is what the pairing prevents. On a bracket, the link stops a closing order from reopening a position in the opposite direction. On an entry pairing, the link stops a market that moves through both levels from opening two opposing positions on the same instrument, which on a platform that permits hedging would leave both open at once and on a platform that nets would leave a size nobody entered. Entry pairings are less widely supported than brackets, and where they are absent the two orders can only be entered separately, with no link between them.

How platforms present the pairing 

The platforms YAL runs are MetaTrader 5, and on neither of them is one cancels the other an entry in the list of order types alongside the limits and the stops. The relationship appears instead as a pair of fields, a stop level and a take profit level, on the ticket for a position or on the ticket for a pending order. Completing both fields is what creates the pairing, so the mechanism is present without ever being named as a type. Whether a level is entered as a price or as a distance from the entry, where the fields sit on the ticket, and what the platform calls them all differ between the two, and both publish their own documentation for it.

One difference matters more than the wording, and it is the question of where the link is held. Where the pairing lives on the firm's server, the cancellation happens whether or not any terminal is running, because the orders and the relationship between them exist independently of the machine that wrote them. Where a pairing is instead maintained by software on a local computer, as a script or an add on, the link only exists while that machine is running and connected, and a disconnection leaves two independent orders behind with nothing to cancel either of them. The same arrangement on the screen can be either of those things, and which one it is comes from the documentation rather than from the ticket.

A second difference shows up when a pairing is attached to a pending order rather than to a position. Some platforms allow the two closing levels to be written on the entry ticket, so the bracket comes into existence at the instant the entry deals and never has to be added afterwards. Others accept closing levels only once a position exists, which leaves a window between the entry dealing and the levels being written. Neither behaviour is a fault, and the difference is one of the things that makes an identical description of an order sequence produce different results on two platforms.

Where practitioners disagree 

The unsettled argument is not about the mechanism, which is arithmetic, but about what a resting pairing communicates to the venue. One tradition holds that a pairing held on the server is the whole point of the arrangement, because the instruction survives a lost connection, a closed laptop and a weekend. Another holds that resting orders are visible to the firm holding them in a way that a decision kept off the ticket is not, and that this visibility is itself a consideration. Both descriptions are accurate about different things, and no arrangement satisfies both at once, which is why the argument persists rather than resolving.

The narrower dispute concerns the partial fill conventions above. One position treats proportional reduction as the only coherent reading, since a pairing describes a position and a position that shrank is still a position. The other treats outright cancellation as the more honest behaviour, on the reasoning that an order silently resized is an order nobody wrote. The practical consequence is the same either way and is worth carrying into any platform's documentation: after a partial fill, what remains resting is a question with two possible answers, and only the documentation says which one applies.