What is the Crypto.com Exchange’s Self-Trade Prevention (STP) feature?
Self-Trade Prevention (STP) is an optional feature that allows Crypto.com Exchange users to prevent the matching of orders for accounts with common ownership within the Exchange.
The definition of a self-trade depends on the following factors by user and/or by exchange:
STP Scope: Whether orders are sent from the same master account and/or sub-account(s) belonging to the same user (stp_scope)
STP ID: Whether orders have the same STP ID (stp_id)
How does STP work?
The STP check occurs when an aggressor order (a taker order) is submitted. If the order is not rejected and becomes a maker order, it is considered to have passed the STP check. The STP check will occur again with the next aggressor order.
Depending on the Self-Trade Prevention Instruction set, one of the following actions will be taken when STP is detected for customers who choose to use it:
Taker orders will be cancelled
Maker orders will be cancelled
Both the taker and maker orders will be cancelled
How do I set up the STP feature?
There are three levels of STP instructions. They will take effect in the following order of precedence:
Exchange level STP - default control
Order level STP - user-specified
Account level STP - user-specified
Exchange Level STP
Presently, there is no default Exchange level STP implemented on the Crypto.com Exchange (Global). Users may set up order and account level STP instructions.
*Crypto.com Exchange (HK) has implemented default STP for all users, Hong Kong users should refer to the region-specific Exchange FAQs.
Order Level STP
Users can specify their STP settings for each individual order via order API (REST, WS, FIX). Order Level STP settings can be set through the following API requests:
The following fields set the STP:
STP Scope (stp_scope):
M - Master Account or Sub Account(s)
S - Sub Accounts only
STP ID (stp_id): 0 to 32767
STP Instruction (stp_inst):
M - Cancel Maker
T - Cancel Taker
B - Cancel both Maker and Taker
For STP to be effective, both Taker and Maker orders must have the STP setting in their respective API requests.
Please refer to the “How does the STP Scope setting affect order matching across different account types for the Order Level STP setting?” section for the Order Level STP scenarios.
Account Level STP
STP can also be specified at the account level. Account Level STP settings have the lowest precedence.
If individual orders don't have any STP settings, the account's default STP settings will be used.
Account Level STP settings can be set through the following API request:
The following fields set the STP:
STP Scope (stp_scope):
M - Master Account or Sub Account(s)
S - Sub Accounts only
STP ID (stp_id): 0 to 32767
STP Instruction (stp_inst):
M - Cancel Maker
T - Cancel Taker
B - Cancel both Maker and Taker
For STP to be effective, both accounts that create Taker and Maker orders must have the STP setting in place. To prevent a master account and sub-account from matching, users need to set STP on both accounts separately.
Account Level STP settings can be retrieved in the following API request:
Please refer to the section on “How does the STP Scope setting affect order matching across different account types for the Account Level STP setting?” for examples of Account Level STP scenarios.
Which instruments are compatible with STP?
STP is supported for all instruments in the Crypto.com Exchange.
Which order types are compatible with STP?
STP is compatible with both Limit Orders and Market Orders.
How can I check if an order has been cancelled due to STP?
If an order has been cancelled due to STP, there will be a "reason": 43012 in the order cancellation API response in private/get-order-detail and private/get-order-history.
For more details, please refer to the Response and Reason Codes section of Exchange API documentation.
If STP functionality is employed, will it add latency relative to orders that do not utilise STP?
No. All orders submitted to the Crypto.com Exchange, irrespective of whether they contain an STP ID, are subject to the same STP ID check at the trading engine. Therefore, whether a participant employs the functionality or not has no impact on latency.
Is there a fee for using STP?
At this time, the Crypto.com Exchange is not charging a fee for using STP.
Is the use of STP required by Crypto.com Exchange users?
The use of STP functionality for Crypto.com Exchange (Global) is currently optional. If a future Order Book Level STP is implemented by the Exchange, it will take precedence over the User-Specified Order Level STP. For the time being, users can tailor their use of STP in ways appropriate for them, provided that they adhere to all STP requirements and relevant exchange rules.
*Crypto.com Exchange (HK) has implemented default Order Book STP for all users, Hong Kong users should refer to https://help.crypto.com/en/collections/9971368-crypto-com-exchange-hk
How does the STP Scope setting affect order matching across different account types for the Order Level STP setting?
Criterion: For STP to be effective, both Taker and Maker orders must have the STP setting in their respective API requests.
Given:
A user has a master account and two sub-accounts – sub-account1 and sub-account2
Order-level STP is used
All orders have the same STP ID
The following are STP behaviours for different combinations:
Master account order and Master account order
stp_scope: M - STP applied (orders don't match)
stp_scope: S - STP applied (orders don't match)
Master account order and Sub-account1 or Sub-account2 order
stp_scope: M - STP applied (orders don't match)
stp_scope: S - STP not applied (orders can match)
Sub-account1 order and Sub-account1 order
stp_scope: M - STP applied (orders don't match)
stp_scope: S - STP applied (orders don't match)
Sub-account1 order and Sub-account2 order
stp_scope: M - STP applied (orders don't match)
stp_scope: S - STP not applied (orders can match)
How does the STP Scope setting affect order matching across different account types for the Account Level STP setting?
Criterion: For STP to be effective, both accounts that create Taker and Maker orders must have the STP setting in place.
Given:
User has a master account and 3 sub-accounts: sub-account1, sub-account2, sub-account3
Account-level STP is used
stp_id is the same for all accounts
Scenarios:
Preventing orders from all accounts under the same master account from matching
Setting: Set stp_scope as "M" for the master account and all sub-accounts
Outcome:
Orders from the master account and all sub-accounts with stp_scope = M will not match with each other
If a sub-account (e.g., sub-account3) sets stp_scope = S, it will only prevent self-trading within that sub-account. It can still match with orders from the master account and other sub-accounts
Preventing orders from only the same account from matching
Setting: Set stp_scope as "S" for the master account and desired sub-account(s)
Outcome:
Each account with stp_scope = S will only prevent self-trading within that specific account
Accounts without any STP settings can match with all other accounts under the same user
Special case: The master account's resolved UUID is always its own, even when stp_scope = S. If a sub-account sets stp_scope = M, it will avoid trading with the master account and itself.
Preventing orders from a specific sub-account (e.g., sub-account1) from matching with its own orders
Setting: Set stp_scope as "S" for sub-account1
Outcome:
Sub-account1's orders will not match with other sub-account1 orders
Setting the master account to "M" has no special effect unless corresponding STP settings are applied to the sub-accounts
Preventing orders from a specific sub-account (e.g., sub-account2) from matching with orders from all other accounts under the same master account
Setting: Set stp_scope as "M" for sub-account2 and all other sub-accounts
Outcome:
Sub-account2's orders will not match with orders from the master account and other sub-accounts that also have stp_scope = M
If the master account is set to "S", it has no special effect on sub-accounts unless they have their own STP settings