How OCO Orders Work: Set It and Protect Your Position

An OCO order, or One-Cancels-Other order, links two orders so that when one executes, the other is canceled according to the OCO instructions. For an active trader, the most familiar setup is a profit target paired with a stop-loss. Instead of placing one exit and remembering to manage the other manually, both sides of the exit plan can be working at the same time. That does not guarantee an exit price or remove market risk. What OCO does is make the relationship between the two orders explicit before one of them is needed.

How does an OCO order work?

Say you're long 100 shares of a stock at $50. You want to take profit if the stock reaches $55, but you also want a stop in place if it moves down to $48. You could place:

• A limit sell for 100 shares at $55
• A stop sell for 100 shares with a $48 stop price

If those orders are entered separately and are not linked, you also have to manage them separately. If the $55 target fills and the $48 stop remains active, that leftover order can become a problem later. An OCO structure links the two exits. If the $55 limit order executes first, the paired stop is canceled. If the stop is triggered and the resulting order executes first, the profit-target order is canceled. The goal is simple: once one side of the exit plan is used, the other side should no longer remain active as though the position were still open. There is an important detail in the $48 stop example. A standard stop order uses $48 as the trigger price, not a guaranteed execution price. Once triggered, it generally becomes a market order, so the actual fill can be below $48 in a fast-moving or illiquid market. That distinction matters. OCO manages the relationship between the orders. It does not guarantee the price at which either order will fill.

Why does broker-side OCO logic matter?

The basic idea of OCO is easy to understand. Where the linked-order logic is handled is more technical, but it can matter to the execution workflow. An OCO needs something to enforce the relationship: If this order executes, cancel the other one. Some trading workflows may depend on application-side logic to monitor orders and send a separate cancellation when one side changes state. That creates another system that has to remain connected and aware of the live order state. A broker-supported OCO structure is different because the linked relationship is submitted as part of the order strategy itself. In OHLCX, OCO orders are submitted through the official Schwab API as linked broker-side orders. Both OCO legs live with the broker rather than relying on an OHLCX server to watch one order and then generate a separate cancellation request for the other. That does not eliminate execution risk, market risk, outages, partial fills, or every possible order-management problem. It does remove one application-side dependency from the basic fill-and-cancel relationship. For a trader, that is the useful distinction behind the phrase broker-native OCO.

OCO vs. a stop-loss vs. an OTOCO order

These order structures solve related problems, but they are not interchangeable.

Stop-loss order

A stop-loss is a single exit order. It is designed to trigger when price reaches a defined level. It can help a trader define the downside side of an exit plan, but by itself it does not create a linked profit target.

OCO order

An OCO links two orders so that execution of one causes the other to be canceled. For an existing long position, that might mean a limit sell above the market for the profit target and a stop below the market for downside protection. The trader defines both sides ahead of time instead of treating the target and stop as unrelated orders.

OTOCO order

OTOCO, or One-Triggers-OCO, adds an entry order before the OCO pair. The entry is submitted first. Once that entry fills, it triggers the linked target-and-stop structure. This lets the trader define the entry and the planned exits as one connected workflow rather than waiting for the entry to fill and then building the exits afterward. Terminology varies by trading platform. Schwab and thinkorswim, for example, use First Triggers OCO for this type of structure. OHLCX refers to its entry-plus-OCO exit flow as OTOCO.

What can still go wrong with an OCO order?

An OCO can make an exit plan more structured, but it should not be confused with guaranteed protection. A few things still matter.

A stop price is not a guaranteed fill price

If the market moves quickly through the stop level, a stop order may execute at a worse price than the trigger. That is especially relevant around gaps, news, thin liquidity, or fast-moving markets.

The order size still has to match the position

If the position changes because of a partial fill, another trade, or manual adjustment, the trader should make sure the working exit orders still correspond to the actual live position. Structured orders do not make stale sizing harmless.

Partial fills can complicate the order state

An order does not always move cleanly from working to completely filled. For active traders, it is worth checking how the broker handles remaining quantities when one side of a linked structure partially fills. The live order state matters more than assuming the original ticket still represents the position perfectly.

OCO does not decide whether the levels make sense

A technically perfect OCO can still be attached to a bad plan. The trader still has to choose the target, stop, size, and order type. OCO handles the relationship between those instructions. It does not determine whether those instructions are appropriate.

Where does OCO fit with trailing stops and staged exits?

OCO is one way to structure an exit, not the only one. A standard OCO commonly pairs a fixed profit target with a fixed stop. A trailing stop moves its trigger according to a defined offset as price moves favorably rather than staying at one fixed level. For traders who do not want to exit the entire position at one target, staged exits can divide the position across multiple planned levels. OHLCX supports five structured exit flows in its order workflow:

• TSP for trailing-stop logic
• OCO for linked target-and-stop exits
• OTOCO for an entry that triggers an OCO structure
• TRIM for fixed staged partial exits
• TRIMMER for customizable staged exit logic

The choice depends on what the trader has already decided about the position. A trader looking for one fixed target and one fixed stop may use OCO logic. A trade that needs the entry and bracket staged together may fit an OTOCO structure. A plan built around partial exits may need something different. The tool should reflect the exit plan, not determine it.

When is an OCO order useful?

An OCO order is most useful when two exit instructions should not remain active independently. For example, if a trader wants both a defined profit target and a downside stop working on the same position, linking them removes the need to remember to manually cancel the unused side after the other executes. That can make the order workflow more deliberate, particularly when several positions are open at the same time. But the benefit is order coordination, not guaranteed protection. OCO does not remove slippage. It does not guarantee a stop price. It does not prevent gaps. And it does not decide where a target or stop belongs. It simply makes one important rule explicit: If one of these exits is used, the other should no longer remain active.

The practical takeaway

An OCO order turns a profit target and stop from two independent instructions into one linked exit structure. For an active trader, that means the relationship between the exits can be defined before price reaches either level, rather than relying on memory to cancel the unused order afterward. The most important things to remember are straightforward:

• OCO links the two exit orders
• Execution of one cancels the other according to the linked order instructions
• A stop trigger does not guarantee the eventual fill price
• The trader still determines the target, stop, size, and overall plan
• Broker-side OCO logic can keep the fill-and-cancel relationship at the broker rather than depending on application-side monitoring

OHLCX supports OCO alongside TSP, OTOCO, TRIM, and TRIMMER, with exit logic selected as part of the order workflow before the order goes live.