Crypto self-trade prevention stops eligible buy and sell orders under the same account or venue-defined ownership group from executing against each other. Its policy may cancel an incoming order, a resting order, both, or reduce their available quantities. Check the exchange's exact scope and resulting order state: a prevented match is not a fill, and earlier fills remain real exposure.
Two bots can disagree without either malfunctioning. One still wants to sell inventory at a resting limit while another sends a buy that crosses it. The matching engine sees the account relationship, rather than the strategy names. Self-trade prevention, usually shortened to STP, decides what happens at that meeting point.
This educational article uses an original fictional order ledger to explain the resulting obligations. It does not establish which STP parameters KLINEO exposes or recommend trading against your own orders.
Start with the ownership boundary
Ask which orders the venue considers related. An application label, separate API key or different bot identifier may have no effect on that boundary. Conversely, some venues apply prevention across a defined group of accounts.
For Binance Spot, the documented relationship covers the same account or accounts sharing a tradeGroupId. Its symbol configuration also declares the default and allowed prevention modes. Read those values for the actual market instead of importing another symbol's settings. Binance Spot STP documentation.
That is a product-specific example. Do not transfer its identifiers or defaults to Binance.US, another exchange, or a futures product. The subaccount isolation guide covers the broader account boundary; separate account areas do not by themselves answer whether a venue groups their orders for STP.
STP also needs a possible match. Merely holding opposing resting instructions at prices that do not cross is a different state. For the basic price relationship, see market versus limit orders. A buy limit can become a taker when it meets an eligible resting sell.
Use the price-band worksheet to validate an order's permitted price before interpreting a later prevention event.
Four policies produce four different obligations
Consider a fictional spot market, ABC/USDT. The account starts with 20 ABC and 500 USDT. An older sell order originally requested ten ABC at 50 USDT each. Three ABC have already sold to unrelated participants, leaving seven available on that order. Ignore fees and every other balance change: the account now holds 17 ABC and 650 USDT.
A second strategy submits a new buy for five ABC at 50. Assume both orders meet the venue's rules and funding requirements, the buy meets the older sell first, no unrelated liquidity is available, and any permitted remainder is good till canceled. Both orders fall inside the same STP boundary.
The following are alternative policies applied to the same constructed state, not sequential actions:
| Prevention policy | Older sell after the encounter | Newer buy after the encounter | ABC traded in this encounter |
|---|---|---|---|
| Cancel incoming order | Seven ABC remain offered | Five-ABC request canceled | 0 |
| Cancel resting order | Seven-ABC remainder canceled | Five ABC remain bid | 0 |
| Cancel both | Seven-ABC remainder canceled | Five-ABC request canceled | 0 |
| Decrement and cancel | Two ABC remain offered | Five-ABC request canceled | 0 |
Coinbase Exchange documents these four policies as cn, co, cb and dc respectively; dc is its documented default. For that product, the incoming order's instruction takes precedence. Coinbase Exchange matching-engine rules.
In the last row, subtract the smaller available quantity from both instructions: 7 − 5 = 2 remaining on the sell, and 5 − 5 = 0 on the buy. This changes instructions, not inventory. The account still holds 17 ABC immediately after every row, because none of these encounters traded.
The three ABC sold earlier stay sold. Their hypothetical gross proceeds remain 3 × 50 = 150 USDT. A final canceled or expired label must not erase those executions. The partial-fill ledger explains how to preserve that distinction.
The future permissions differ sharply. In the first row the account can still sell seven more ABC; in the last it can sell only two through that order. In the second it can instead buy five. Treating every row as simply “order failed” loses the information needed for the next decision.
Translate behavior before translating parameter names
Binance Spot uses names including EXPIRE_TAKER, EXPIRE_MAKER and EXPIRE_BOTH for policies affecting remaining instructions. Its current documentation also includes quantity-reduction and transfer behavior, with additional conditions. A list of familiar cancellation names is therefore not a complete account of every supported mode. Verify the full rules and account effects before selecting one. Binance Spot mode behavior.
Do not assume all modes are selectable for every symbol or client. Record the requested policy, the accepted policy and the observed outcome separately. A configuration file can show intent even when a request was rejected or a venue applied a default.
The worksheet deliberately used sized limit orders. Funds-based market orders can have additional product-specific treatment. Coinbase's documentation distinguishes how decrement-and-cancel acts when a market buy supplies funds, size or both. Do not reuse the five-unit arithmetic for a quote-budget instruction without reviewing that rule.
A prevention event needs its own ledger entry
Keep actual executions separate from prevented quantities. Binance Spot's user data stream documents conditional prevention fields, including a prevented-match identifier, quantity and counter-order identifier. These help connect the affected instructions without inventing a trade. Binance Spot order-event fields.
A useful incident record captures:
- Account, environment, product and symbol, plus the applicable ownership group.
- Both order identities, their strategy owners and their state before the encounter.
- Accepted STP policy, event time, actual cumulative fills and prevented quantities.
- Final remaining instructions, inventory or position, and any unresolved observations.
Use the venue's authoritative quantities and lifecycle definitions. “Original minus filled” is insufficient when another mechanism has reduced the executable instruction. Likewise, a prevention event is not a reason to add a synthetic sale and purchase to the trade journal.
If the response is missing, the state remains uncertain. Follow the order-timeout reconciliation process before replacing either instruction. Retrying the same conflict can repeatedly cancel useful orders while creating no desired exposure change.
If the conflict is discovered after downtime, the maintenance restart worksheet helps separate unresolved submitted orders from signals that were never sent.
The difficult failure: a valid exit disappears
Suppose the older sell in the worksheet was an intended inventory exit. Selecting cancel-resting allows the new buy to remove that seven-unit exit. No self-trade occurred, but the original reduction plan no longer has that working order.
The opposite policy can frustrate the incoming strategy instead. Cancel-incoming leaves its five-unit entry absent. A workflow that advances merely because the placement request was accepted may start managing a position that the attempted entry never created.
These are ownership and sequencing problems as well as matching problems. Before allowing several order sources to share an account, decide which process can cancel or supersede another's intention. Give exit management a documented owner and reconcile actual exposure before advancing dependent steps. STP alone cannot choose the correct trading objective.
Do not disable prevention as an automatic recovery action. Establish why orders conflict and whether one intention has expired. A supported test environment can check lifecycle handling, but it cannot prove live liquidity or queue behavior; the testnet versus live guide explains that limit.
A preflight card for shared-account automation
Before activation, write one sentence for each answer: Which account relationships trigger STP? Which policy will this product accept? Which order survives each conflict? Who receives and reconciles the prevention event? What happens if that event removes an intended exit?
Then rehearse the four-row worksheet with your own documented order forms, including an earlier partial fill and a missing response. The target is a verifiable account state and an explicit next decision. Preventing an internal match does not remove market risk, preserve every protective instruction or guarantee that a desired trade executes.
Editorial method: Prepared with AI assistance on 23 October 2026 using official Binance Spot and Coinbase Exchange documentation. The order ledger and quantities are hypothetical. No live account test, customer incident or expert review is represented.