Self-Trade Prevention: When Your Own Orders Match

The trade that should not exist

Most matching-engine explanations assume two different participants. One wants to buy, one wants to sell, and the engine finds the price where both are willing. A self-trade breaks that assumption: the same person is on both sides, so the trade moves coins from one pocket to another, pays two fees, and prints volume that no independent counterparty agreed to.

The accidental versions are common. A market-making bot quotes a bid and an ask around a mid price. The market moves, the bot reprices both sides, and for a moment the new ask is at or below its own resting bid. A rebalancing script sends a sell while an older buy from the same script is still resting. Two strategies share one exchange account because the account is the unit of margin, and their orders meet in the book.

Venues treat this as a problem worth solving at the matching layer rather than leaving to the participant. The reason is not only fairness. Self-trades can be used to generate volume for rebates, to wash trades for tax or reporting purposes, or to create the appearance of liquidity. A venue that lets them through inherits the regulatory and reputational cost.

Binance’s six modes

Binance’s Spot API documents six self-trade prevention modes for the selfTradePreventionMode parameter. The definitions are worth reading in full because the differences are operational, not cosmetic.

The first four are easy to reason about: one side disappears, the other stays. DECREMENT is the one that surprises people. It does not choose a winner. It reduces both orders by the size of the prevented match, so a 10 BTC bid meeting a 4 BTC ask leaves a 6 BTC bid and a 0 BTC ask — the smaller order is gone, and the larger one keeps its remaining size. If the two are equal, both disappear.

TRANSFER is stranger still. It exists for accounts that are related but not identical, and it moves the prevented quantity and notional between them rather than simply deleting the overlap. For most retail and prop clients, TRANSFER is not the mode they want; it is a tool for a specific account structure.

The taker decides

The most important rule in Binance’s FAQ is not in the mode table. It is this: “STP behavior is typically determined by the STP mode of the taker order only.”

That means the resting order’s mode is usually irrelevant. If a maker order was sent with EXPIRE_MAKER and a taker arrives with EXPIRE_TAKER, the taker’s choice governs, and the taker is the one that expires. The maker’s preference does not protect it.

The exception is TRANSFER. For that behaviour to occur, both the maker and the taker must specify TRANSFER. If the taker asks for TRANSFER and the maker specifies something else, Binance says the behaviour falls back to DECREMENT.

For a client, this simplifies the design in one way and complicates it in another. You do not need to coordinate modes across every resting order, because only the incoming order’s mode matters. But you do need to set the mode on the order that is about to take, at the moment you send it, and you need to know what the venue will do to the order that is already resting.

The status that tells you it happened

An order removed by STP is not CANCELED. Binance documents a separate status, EXPIRED_IN_MATCH, described as an order “expired by the exchange due to STP.”

This matters for reconciliation. Three statuses can look similar in a dashboard and mean different things:

• CANCELED — the user cancelled the order.
• EXPIRED — the order was removed by its own type’s rules, such as an IOC remainder, or by the exchange during maintenance or liquidation.
• EXPIRED_IN_MATCH — the order was removed because it would have self-traded.

A client that maps every non-fill to “cancelled” will lose the distinction between a decision it made, a rule it chose, and a prevention event it may need to investigate. The user data stream carries the execution report that contains the status; the execution report guide explains how to read the fill fields around it.

Trade groups: when two accounts are one participant

STP is not limited to a single account. Binance compares orders that belong to the same account or to accounts with the same tradeGroupId. The FAQ defines a trade group as different accounts sharing that identifier, and says orders from members are eligible for STP according to the taker order’s mode.

A tradeGroupId of -1 means the account has no group set, so STP can only take place between orders of the same account. The value can be read from the account endpoint and appears in prevented-match responses.

This is the part of STP that a multi-account operation has to plan. Two accounts trading the same strategy, with no trade group, can trade with each other and neither venue nor client will call it a self-trade. Whether that is acceptable depends on why the accounts are separate. If they are separate legal entities with separate beneficial owners, it may be legitimate. If they are the same owner’s accounts, the absence of a group is a gap in the control, not a feature.

OKX: three modes and a FOK exception

OKX approaches the same problem with a smaller vocabulary. Its stpMode parameter accepts cancel_maker, cancel_taker and cancel_both. The account-level acctStpMode is used by default, and the documented default value is cancel_maker.

Two details in OKX’s documentation are worth carrying into a client.

First, OKX states that “the STP mode is always taken based on the configuration in the taker order.” That is the same principle as Binance’s taker rule, stated without the TRANSFER exception.

Second, cancel_both does not support FOK. OKX says combining stpMode=cancel_both with ordType=fok returns error 50016. A strategy that uses FOK for all-or-nothing entries and cancel_both for self-trade protection has to choose which guarantee matters more for that order.

OKX also documents that mandatory self-trade prevention does not add latency. That is a claim about implementation rather than a user-facing behaviour, but it matters for anyone who assumed STP was a post-trade check that could be disabled for speed.

Why the default is maker-expiry

Binance’s October 2023 announcement made STP mandatory for all Spot and Margin users and stated that the default mode is for the maker order to expire. That default is a policy choice, and it is worth understanding rather than accepting.

If a taker would self-match, expiring the maker keeps the taker alive. The incoming order can continue matching against other makers at the same price. Expiring the taker would remove the new instruction entirely, which is safer for the resting order but worse for the participant who just sent an order expecting it to work.

Maker-expiry is therefore the compromise that preserves the incoming order’s intent while removing the stale side. It also means a market-making bot can lose its resting quote without ever sending a cancel, which is exactly the kind of event a reconciliation process needs to catch.

What STP does not solve

Self-trade prevention is a matching-engine control, not a complete market-abuse control. Four gaps are worth naming.

It does not identify every related account. Accounts without a shared tradeGroupId are treated as independent. A group is a configuration an operator chooses, and a venue cannot infer beneficial ownership from an API key.

It does not stop wash trading across venues. Two accounts at two different exchanges can trade with each other freely, and no single venue sees both sides. Cross-venue wash trading is a surveillance problem, not a matching-engine problem.

It does not decide the tax treatment. A blocked self-trade produces no fill, so there is no disposal to report. But a self-trade that was allowed under NONE, or that happened across ungrouped accounts, may still be a wash sale or a reportable transaction depending on jurisdiction. The wash sale guide covers the US rules and why crypto is treated differently from securities.

It does not guarantee a better price. Expiring the maker removes liquidity from the book. If the taker was the only order at that price, the remaining book may be worse for the next participant. STP protects the participant from trading with itself; it does not improve the market for anyone else.

A checklist for a client that can self-trade

• Decide the STP mode per strategy, not per account, if the strategy’s behaviour differs.
• Set the mode on the taker order, because that is the one the venue reads.
• Treat EXPIRED_IN_MATCH as its own event in reconciliation, not as a cancellation.
• If two accounts belong to the same owner, decide whether they should share a tradeGroupId; -1 means they do not.
• On OKX, check whether any strategy combines cancel_both with FOK; the combination is rejected.
• Log the prevented quantity when using DECREMENT or TRANSFER, because the remaining size is not the size you sent.
• Do not use NONE as a performance optimisation unless the account genuinely has no self-trade risk.

Sources and what they support

• Binance Spot API, Self Trade Prevention FAQ — defines all six modes, states that the taker order’s mode normally governs, defines EXPIRED_IN_MATCH, and explains tradeGroupId and the -1 value. Read 2026-11-03.
• Binance, Enhancing User Protection with Mandatory Self-Trade Prevention (25 October 2023) — states that the requirement applies to all Spot and Margin users and that the default mode is maker expiry. Read 2026-11-03.
• OKX API v5, Place order — defines stpMode values, the cancel_maker default, the taker-order rule, and the FOK restriction on cancel_both (error 50016). Read 2026-11-03.

Risk note. STP behaviour is set by each venue and can change. The mode names and rules above were read from the venues’ own documentation on 2026-11-03; a production client should verify the status it receives rather than infer it from the request. Nothing here is investment advice.