Orders can have several attributes assigned to them.
Time in Force (TIF)
Time in force is a special instruction used when placing a trade to indicate how long an order will remain active before it is executed or expires.
|
GTC |
Good till cancel (GTC) - GTC is the default setting. The order will remain open until it is filled, cancelled, or the instrument expires. |
|
GTD |
Good till day (GTD) - If it has not already been filled or cancelled, the order will be cancelled automatically at the end of the current daily session (8 AM UTC). |
|
FOK |
Fill or Kill (FOK) - The order is either filled immediately and completely, or not at all. |
|
IOC |
Immediate or cancel (IOC) - Any portion of the order that cannot be filled immediately will be cancelled. |
Order type attributes
|
Iceberg |
• An Iceberg order allows a trader to hide the full size of an order while revealing only a portion (the display amount) in the order book. The visible portion behaves like a regular limit order, while the hidden portion remains concealed until the visible part is filled. • Aggressive iceberg orders match as regular taker orders. When placed into the order book iceberg orders match as maker orders on the displayed part and taker orders on the hidden part. The hidden amount of an iceberg order also loses priority to regular orders. To enforce proper usage and maintain order book integrity: • The initial display amount must be at least 100 times the instrument’s minimum order amount. • The ratio of the displayed portion to the total order amount must be at least 1% (i.e., the display amount must be at least 1/100 of the total amount). When using the API: • The private/buy, private/edit and private/sell endpoints support an optional display_amount parameter to define the visible portion. • Responses and events related to Iceberg orders include: • display_amount: the currently visible part of the order (the “tip”). • refresh_amount: the original value of display_amount from the order request. Noterefresh_amount remains constant throughout the order’s lifecycle. It represents the intended size of each iceberg “tip” as it gets replenished. The actual display_amount can be lower than refresh_amount when the order is partially or nearly fully filled. For example, if the total order amount is 10,000, refresh_amount is 1,000, and 9,500 has already been filled, the current display_amount would be 500 — the remaining visible portion. ImportantIceberg Orders and Fees When using iceberg orders, the fee treatment depends on whether the executed portion was visible or hidden at the time of the trade. The visible portion of an iceberg order rests in the order book like a regular limit order and is charged the maker fee when executed. As each visible slice is filled, the next slice is automatically revealed at the original display size, and this process continues until the order is nearly or fully executed. However, if an incoming taker order consumes more than the currently visible amount and starts matching against the hidden portion, the hidden quantity is always charged the taker fee. Example: Consider an iceberg order of 10,000 contracts with a display size of 1,000.
|
|
Post_only |
Post only (post_only) - This setting will ensure the order will not act as a taker, and therefore will not match against orders that are already resting in the orderbook (excluding hidden orders). If the price of the order is such that it would otherwise execute against the best available price, the post only order will be placed into the order book one tick away from the best available price. |
|
Post_only_reject |
reject_post_only - This setting will ensure a post_only order will be rejected instead of having it's price adjusted. (Only available by API) • This setting is only available via the API. |
|
Reduce_only |
Reduce (reduce_only) - This setting will ensure the order can only reduce an open position. It can not increase the size of any existing positions, or open any new positions. |
Trigger fill attribute (OCO, OTO, OTOCO)
The trigger fill attribute is set to "incremental" for orders placed on the user interface.
Via the API, the trigger fill attribute can be defined at the time of placement of the primary order.
|
First Hit |
First Hit - A type of fill condition for linked orders. Any (partial) execution of the primary order will fully trigger or cancel the secondary order(s). • OCO - The secondary order will be completely cancelled upon the first (partial) hit of the primary order. • OTO - The secondary order will be fully triggered and placed upon the first (partial) hit of the primary order. • OTOCO - Both secondary orders will be fully triggered and placed upon the first (partial) hit of the primary order. |
|
Complete fill |
Complete Fill - A type of fill condition for linked orders. A complete execution of the primary order will fully trigger or cancel the secondary order(s). • OCO - The secondary order will be completely cancelled upon the complete fill of the primary order. • OTO - The secondary order will be fully triggered and placed upon the complete fill of the primary order. • OTOCO - Both secondary orders will be fully triggered and placed upon the complete fill of the primary order. |
|
Incremental |
Incremental - The default fill condition for linked orders. Any partial execution of the primary order will cause a proportional trigger or cancel of the secondary order(s). • OCO - The secondary order will be incrementally cancelled proportionally to a (partial) fill of the primary order. • OTO - The secondary order will be incrementally triggered and placed proportionally to a (partial) fill of the primary order. • OTOCO - Both secondary orders will be incrementally triggered and placed proportionally to a (partial) fill of the primary order. |
API
To place, amend, and cancel orders programmatically, including Time in Force, Reduce Only, and other flags, see Order Management - Best Practices in the API documentation.