What is an OCO Order?

Introduction

OCO order means one-cancels-the-other: a linked set of orders where execution of one leg causes the remaining leg or legs to be canceled, and in some systems possibly held instead of canceled. That sounds straightforward, but the useful idea is deeper than the name. An OCO exists because traders often want to express alternatives, not independent wishes. They may want to sell at a profit target or exit if price falls, or they may want to buy on a breakout or on a pullback, but not both. Without linkage, the trading system sees separate instructions and may execute them separately, even though the trader meant them as mutually exclusive.

That is the problem OCO solves. It turns multiple orders into a single conditional intention: if this happens, do not let the alternative happen as well. In practice, that reduces manual monitoring, helps with risk management, and makes simple strategy automation possible. But it also introduces an important caveat: the idea of “cancel the other order” is easy to understand at the user level, while the actual mechanics depend heavily on the broker, exchange, or protocol carrying the instruction.

That difference matters. In some systems, OCO is a native exchange-supported order relationship. In others, it is a broker-side or client-side instruction layered on top of ordinary orders. Some venues treat a full fill as the trigger for cancellation. Some platforms cancel on partial fill. Some can reduce the remaining quantity of other legs as one leg fills. And some explicitly warn that cancellations may not reach the market before another leg executes. So to understand OCO well, you need both the clean concept and the messy implementation reality.

How does an OCO express mutually exclusive trading alternatives?

The cleanest way to think about an OCO order is this: it encodes a set of orders that are economically substitutes. You are not saying “please execute all of these if possible.” You are saying “these are different paths to the same outcome, and once one path starts to happen, the others no longer make sense.”

That is why OCO sits close to stop orders and take-profit orders in practical trading. Suppose you already hold an asset. You want to exit if price rises to a target, because that locks in gains. But you also want protection if price drops to a loss threshold. Those are two valid exit plans, but executing both would usually be wrong. If the profit-taking order sells your position, the protective stop should not remain live, because it could later sell a position you no longer own or create an unintended short exposure depending on the market and account rules. OCO gives the platform a way to understand that these orders are alternatives tied to the same position-management intent.

The same logic works for entry. If an asset is trading in a range, a trader may want to buy if it breaks above resistance or buy if it dips to support, but not both. Those are two mutually exclusive hypotheses about market direction. OCO packages them so the first one to become relevant prevents the other from lingering as a stale instruction.

This is the compression point: an OCO order is not primarily about two order types; it is about preserving an invariant; at most one path should survive. The exact legs can vary, but the invariant is the reason the order type exists.

How does an OCO order work in practice?

At the user level, an OCO is usually shown as a pair of linked orders. A common retail pattern combines a limit order with a stop-limit order. Binance. US describes its OCO this way: a pair of orders created concurrently, where only one can be executed, with the other canceled automatically when one is filled; it also characterizes OCO as combining a limit order with a stop-limit order. That combination makes sense because the two legs often represent opposite market contingencies. The limit leg is usually the desired favorable-price outcome, while the stop-based leg is the protective fallback.

But the mechanism is more general than that retail template. CME Direct defines OCO as two or more separate though linked orders, and says a full fill of one order in the group results in all other linked orders being canceled or held. That broader definition is closer to the first-principles idea. The essential ingredient is not “one limit plus one stop-limit.” The essential ingredient is the link and the contingency rule attached to that link.

In FIX, the industry messaging standard used widely in electronic trading, this linkage is represented through ContingencyType, field 1385. The canonical code set defines value 1 as One Cancels the Other (OCO). The field is used in messages including ExecutionReport, ListStatus, and NewOrderList. This matters because it shows OCO is not just a user-interface trick. It is a standardized way to describe a contingency relationship between orders in interoperable trading messages.

Still, a FIX code does not by itself guarantee identical runtime behavior. The FIX reference tells you how the relationship is labeled, not exactly how each venue enforces it under stress, partial fills, or races between events. That gap between representation and enforcement is where most practical misunderstandings arise.

Example: using OCO to place a take-profit and a stop-loss

Imagine you bought 100 shares of a stock at 50. You now want to manage the position without staring at the screen. You would be happy to sell at 56 and realize a gain. But if price falls to 47, you want to limit the loss. If you place those as two independent sell orders, the system simply sees two live instructions. If the 56 limit order executes first and you walk away, the 47 protective order may still be live later. In the wrong circumstances, that order can become dangerous because it no longer matches the position you intended it to protect.

With an OCO, you instead send a linked instruction: a sell limit at 56 and a sell stop-based order around 47 are both active, but they are marked as alternatives. If the market rises and trades through 56, the take-profit leg executes. The OCO rule then tells the system that the stop leg has lost its purpose and must be canceled or otherwise removed from live execution. If the market falls instead and triggers the stop leg, the limit leg is canceled because your exit intention has already been consumed by the protective path.

Notice what happened conceptually. The OCO did not predict the market. It did not improve the pricing of either leg. It simply kept the trading system aligned with the trader’s intended state transition: from holding a position with two possible exits to having executed one exit and therefore no longer needing the other. That alignment is why OCO is useful.

What events trigger cancellation in an OCO group?

This is where platform behavior diverges.

Many traders casually say “when one order fills, the other is canceled,” but the exact event can be a full fill, a partial fill, or something more specialized. CME Direct is explicit that a partial fill will not cancel linked orders by default. Its OCO behavior is organized around a full fill of one order in the group, after which the remaining linked orders are canceled or held according to preferences. That design reflects a conservative interpretation: the system waits until one path is fully realized before it suppresses the others.

Binance. US describes a stricter behavior in its help article, saying that as soon as one of the orders is fully or partially filled, the other is canceled automatically. That is a different policy. It treats any execution on one leg as sufficient evidence that the alternative leg should disappear. Neither approach is universally “correct.” Each reflects a design choice about what risk matters more: unwanted simultaneous execution, or prematurely canceling an alternative while the first leg is only partially complete.

Some systems go further and allow reduction logic instead of an all-or-nothing cancellation. CME Direct has an OCO Reduce as Filled feature under which a partial fill in one member reduces the remaining quantity of other group members by the same filled amount. Interactive Brokers describes similar choices in its OCA workflow, including reducing other orders, reducing them with overfill protection, or canceling other orders. These features try to preserve the deeper invariant not at the binary level of “one survives,” but at the quantity level of “the group as a whole should not execute more than intended.”

That is a more nuanced mechanism, and it exists because the simple two-leg story is only the smallest case. Once groups contain more than two orders, or when partial fills are common, quantity management becomes as important as yes-or-no cancellation.

What are the timing and race-condition risks with OCO orders?

The hardest part of OCO is timing. Traders often imagine the linkage as instantaneous and atomic, as if the market itself knows only one leg may fill. Sometimes that is close enough. Sometimes it is not.

Interactive Brokers states this plainly in its OCA documentation: because the procedure is automated, there is no guarantee that requested cancellations and modifications will reach the exchange before an order has been executed. That sentence captures the core implementation risk. An OCO relationship may be enforced at the broker, router, trading terminal, or exchange. If enforcement is not fully native at the matching venue, then cancellation is a message that travels through systems. During that time, another leg may still execute.

This is not a flaw unique to one broker. It is a general consequence of distributed systems and fast markets. A fill can occur at nearly the same time a cancel request is generated. If both legs become marketable during a rapid move, or if the venue processes messages in an unfavorable sequence, the trader may receive more execution than intended. Interactive Brokers specifically warns that some partial-fill handling modes can route multiple orders and lead to overfill or rejection unless overfill protection is used.

So the slogan “one cancels the other” should be read as an intended control rule, not as a universal promise of perfect atomicity.

Does OCO run on the exchange or at the broker, and why it matters

A useful question to ask about any OCO feature is: **where does the linkage live? ** The answer determines much of the behavior.

In some exchange environments, OCO is documented as a native order relationship inside the venue’s own order handling. Eurex’s T7 functional reference includes dedicated OCO sections and notes that triggering an OCO order updates the order’s priority timestamp. That is a distinctly exchange-level consequence. It means OCO is not merely a cosmetic front-end grouping; it interacts with the matching engine’s rules about order priority. The same reference also shows that changing the limit of an OCO order is a matching-relevant modification in certain contexts. These details matter because they show OCO can alter more than just cancellation behavior; it can affect queue position and execution priority.

In other settings, the exchange may not accept OCO as a native order type at all. Cboe stated in a regulatory circular that the exchange does not accept OCO orders. In that context, an OCO is treated as an off-exchange instruction that at most may route one order to the exchange. That is a very different model. The linkage exists outside the exchange, likely at the broker or order management layer, and the exchange only sees ordinary child orders that happen to originate from a contingent parent instruction.

This distinction is fundamental. If the venue natively supports OCO, enforcement can in principle happen closer to the matching process. If OCO is broker-side, enforcement depends on routing, message timing, and the broker’s orchestration logic. The concept is the same, but the failure modes are not.

Why pair OCO with stop-loss and take-profit orders?

Retail explanations often reduce OCO to “a stop-loss plus a take-profit.” That is not wrong, but it is narrower than the underlying idea.

The reason that pairing is so common is that most traders feel the problem most acutely after entering a position. Once you hold an asset, there are usually two meaningful boundaries: a favorable boundary where you are satisfied to exit, and an unfavorable boundary where you no longer want to remain exposed. Without OCO, these have to be monitored and managed as separate instructions. With OCO, they become a single exit framework.

This is also why OCO belongs conceptually next to stop orders and take-profit orders rather than replacing them. The stop order defines the protective mechanism. The take-profit order defines the target-exit mechanism. OCO defines the relationship between them. It is not a third pricing rule layered on top of the market; it is a coordination rule that keeps neighboring order types from colliding.

That coordination role is easy to miss. Traders sometimes think OCO is an “advanced order” because it uses more fields in the interface. In reality, its sophistication lies in expressing intention across multiple orders, not in inventing a new execution formula.

How do partial fills affect OCO behavior?

If you want to understand a specific platform’s OCO behavior, look at what it does under partial fill. That is where semantics become concrete.

A platform that cancels the other leg as soon as any quantity fills is saying the mutual exclusivity is about starting execution. A platform that waits for a full fill is saying the mutual exclusivity is about completing one path. A platform that reduces the other legs proportionally is saying the real invariant is aggregate exposure control across the group.

CME Direct exposes all of this directly. By default, a partial fill does not cancel linked orders. It also offers a group max fill threshold, so the total filled quantity across the group can trigger cancellation or holding once a specified aggregate level is reached. That is a sophisticated way of saying the trader may care not just about which order fills first, but about the total amount executed across all linked alternatives.

Interactive Brokers exposes a similar design choice from another angle. Its OCA settings let the user decide whether partial fills should cause reduction in other orders or outright cancellation, and whether overfill protection should limit simultaneous routing. These options reveal an important truth: OCO is less a single universal behavior than a family of contingent-order controls organized around the same basic principle.

What does the FIX standard say about OCO orders?

The FIX standard is useful here because it separates naming from implementation.

Field 1385, ContingencyType, exists to define the type of contingency attached to an order or order list. The FIXimate reference gives value 1 as One Cancels the Other (OCO), alongside related standardized contingencies such as One Triggers the Other (OTO) and One Updates the Other (OUO). This is valuable for interoperability because systems need a common vocabulary to describe linked order behavior.

But FIX does not magically erase venue differences. A message can say that a group is OCO, yet the exact trigger event, cancellation timing, partial-fill policy, and race-condition handling still depend on the systems implementing that instruction. In other words, FIX tells systems what relationship is intended, not always how every edge case must unfold.

That is why production trading systems need both the standard message-level definition and the venue’s own rulebook or platform documentation. The former gives you portable semantics; the latter tells you where the approximation ends.

Which edge cases can make OCO fail or behave unexpectedly?

The clean user-facing story says: place two alternatives, one executes, the other disappears. Three things complicate that story.

The first is non-atomic cancellation. If cancellation is processed after another leg becomes executable, both may fill. This is the classic race condition and the main operational caveat in broker-managed OCO systems.

The second is partial-fill ambiguity. If one leg fills only partly, should the other remain live, disappear, or shrink? Different systems make different choices because traders face different risks. There is no single natural answer outside a specific use case.

The third is state changes that affect queue priority or venue handling. Eurex notes that triggering an OCO order updates the priority timestamp. That means the OCO mechanism can interact with price-time priority, not merely with cancellation. A trader who thinks only in terms of “if-then” logic may miss these microstructure consequences.

A related subtlety is that some systems define the aftermath of a trigger as cancel or hold, not always immediate cancel. CME Direct includes both possibilities through configurable remove actions. Holding an order after another group member fills is not the textbook OCO picture, but it reflects a practical need in some professional workflows to preserve linkage and trader control without immediate deletion.

Is OCO used across markets and asset classes?

The idea is not tied to one asset class. You see it in crypto spot interfaces, futures tooling, options workflows, and exchange protocols because the underlying problem is universal: market participants often need mutually exclusive alternatives.

Binance.US presents OCO as a web-based spot trading tool for combining a limit and stop-limit order. CME Direct applies OCO to groups of linked orders with fill thresholds and reduction logic. Interactive Brokers uses the closely related label OCA, one-cancels-another, for option order groups with configurable on-fill behavior. Eurex documents OCO as part of the exchange’s functional order handling. The different surfaces look different because each market and platform has its own constraints, but the need they address is the same.

That breadth is useful for intuition. It shows OCO is not a quirky feature invented for one venue. It is a general answer to a recurring coordination problem in electronic trading.

How should I assess risk before using an OCO order?

The safest practical mindset is to treat an OCO as a strong instruction about intent, not an absolute guarantee about market outcome. It greatly improves alignment between what you mean and what your order management system attempts to do. It does not repeal latency, exchange rules, queue priority, or the possibility of near-simultaneous executions.

So when evaluating an OCO feature, the key questions are mechanical. Does the venue support it natively, or is it broker-managed? Is the trigger a full fill or any fill? On partial fills, does the platform cancel, hold, or reduce the remaining legs? Is there overfill protection? Can the relationship involve more than two orders? Does a trigger reset timestamps or otherwise alter priority? These are not implementation footnotes; they are the real behavior.

If you know those answers, the conceptual simplicity of OCO becomes genuinely useful. If you do not, the simplicity can be misleading.

Conclusion

An OCO order is best understood as a way to express mutually exclusive trading paths. Its purpose is not to create a new price condition, but to keep several orders aligned with one intention so that once one path is taken, the others stop being live alternatives.

That is the part worth remembering tomorrow: **OCO turns multiple orders into a single decision rule; one outcome should survive, not all of them. ** Everything else, from stop-loss and take-profit combinations to partial-fill handling and race-condition risk, follows from how a particular platform chooses to enforce that rule.

How do you place an OCO order?

Place an OCO on Cube by submitting two linked exit orders (a take-profit limit and a stop (stop-limit or stop-market)) so the first to execute cancels the other. Cube enforces the one-cancels-the-other link in the order workflow so you can protect a position without manual monitoring.

1. Select the open position you want to protect in your Cube portfolio and note the exact quantity to cover.
2. Open the exit-order form and choose to create two linked legs: set the take-profit as a limit order with your target price and the quantity to close.
3. Add the stop leg: choose a stop trigger price and the stop order type (stop-market or stop-limit), and set the stop quantity so the combined legs do not exceed your position.
4. Review prices, quantities, and estimated fees, confirm the OCO linkage, and submit the linked order pair so Cube will cancel the other leg if one executes.