# Orders

The Nekuti Matching Engine natively supports all major order types and variants, providing traders with a comprehensive suite of order execution options.

# Reference

This section details the core parameters available on the main order creation endpoint.

# Explanation

# Basic Order Types

The Nekuti Matching Engine supports several fundamental order types:

• Market Orders: Execute immediately at the best available price
• Limit Orders: Execute at the specified price or better
• Stop Orders: Trigger when market reaches the specified stop price
• Stop Limit Orders: Trigger at stop price, then execute as limit orders

# Limit Orders: Visible, Hidden and Iceberg

Limit orders are the bread and butter of liquidity in the central limit order book. These orders fill when their prices cross with orders on the opposite side of the market.

# Execution Mechanics

When a limit order aggresses (takes liquidity):

• Trades occur at the price of the resting order
• Orders are filled in time-priority at the same price level
• The aggressing order fills all possible resting orders until:
  • Its quantity is fully satisfied, or
  • No more resting orders exist within its limit price
• Any unfilled portion will rest in the order book, unless timeInForce is set to FillOrKill or ImmediateOrCancel
• Resting orders continue to be partially filled while they rest until fully filled, canceled, or amended

# Visibility Options

Limit orders can be configured with different visibility characteristics:

Visible Orders

• Default behavior when displayQty equals orderQty
• Have time priority over hidden orders
• Generally receive the lowest fees for maker orders (see Fee Schedule)

Hidden Orders

• Created by setting displayQty to 0
• Not detectable in order book feeds or margin calculations
• Subject to different fee structures than visible orders

Iceberg Orders

• Created by setting displayQty to a value less than orderQty
• Consist of two segments: visible ("berg") and hidden
• Execution dynamics:
  • The visible portion has time priority like a normal visible order
  • When the visible portion fills completely, the next "berg" becomes visible
  • The new visible portion receives time priority based on when the previous portion executed
  • If the berg size is not a multiple of the entire order size, the final berg will be smaller
  • Different fees apply for aggressing and resting visible portions versus hidden portions

# Order Book Matching Behavior

When an aggressing order consumes all visible resting orders at a price level, it then proceeds to consume hidden orders at the same level (including hidden portions of icebergs) before moving to the next price level.

# Time in Force

The timeInForce parameter controls how long an order remains active in the market:

Day

• Order is canceled at the end of the trading day
• End of day is determined by a command sent to the control gateway's "close day" endpoint
• Useful for traders who don't want orders to remain open overnight

GoodTillCancel (GTC)

• Order remains active until it is either filled completely or explicitly canceled
• Provides maximum flexibility for long-term positioning
• Default for most trading scenarios

GoodTillDate (GTD)

• Order expires automatically at the specified expireTime (in epoch milliseconds)
• Requires the expireTime parameter to be set
• Useful for time-sensitive trading strategies

ImmediateOrCancel (IOC)

• Fills as much of the order as possible at the specified price or better
• Immediately cancels any remaining unfilled portion that would otherwise rest in the order book
• Useful for capturing immediate liquidity without leaving resting orders

FillOrKill (FOK)

• Order must be filled in its entirety immediately or be canceled completely
• No partial fills are possible
• Useful when the exact fill quantity is critical

The choice of Time in Force affects both execution behavior and market impact, making it an essential parameter for order management.

# Triggered Orders

The Nekuti Matching Engine supports several types of triggered orders that remain inactive until specific market conditions are met.

# Stop and If-Touched Orders

These orders do not immediately enter the market but are triggered when certain price conditions are met:

Stop Orders

• Trigger in the direction of market movement
• A sell Stop triggers when the price falls below stopPx
• A buy Stop triggers when the price rises above stopPx
• When triggered, places a Market order (Stop) or a Limit order (StopLimit)

If-Touched Orders

• Trigger in the opposite direction of market movement
• A buy If-Touched triggers when the price falls below stopPx
• A sell If-Touched triggers when the price rises above stopPx
• When triggered, places a Market order (MarketIfTouched) or a Limit order (LimitIfTouched)

# Trigger Price References

These orders reference a price specified in the execInst parameter:

MarkPrice

• References the exchange-provided mark price for the instrument
• Typically a calculated price representing fair market value

IndexPrice

• References the underlying index for the instrument
• May vary from the mark price
• For term futures, the mark will be the index plus a component to account for the expected basis or forward curve between the immediate index and expiry

LastPrice

• References the last traded price
• Potentially more volatile than mark or index references

LastWithinMark

• References the last traded price that is "within" the mark
• Only triggers if the trade occurred within 5% of the mark at the time of the trade
• Trades occurring more than 5% away from the mark will not trigger the stop
• Provides protection against triggering on outlier trades

The combination of triggered order types and trigger price references allows for sophisticated trade entries and exits based on market movements.

# Position Management Orders

The Nekuti Matching Engine provides specialized order types for managing positions safely and efficiently.

# Reduce Only Orders

Setting the execInst parameter to ReduceOnly creates an order that can only reduce an existing position, never increase it:

• The quantity of the order is automatically modified to be no larger than the size of the position in the opposite direction
• If a Reduce Only order is resting in the book, it will be amended downward as position changes occur
• If execution of any lot of the Reduce Only order would open a new position, its size is reduced
• Position changes from better-priced orders (whether Reduce Only or not) are accounted for first
• A Reduce Only order is never amended upward, even if the position increases after decreasing
• If a position is entirely closed, any resting Reduce Only orders will be canceled
• Self-matches also cause a Reduce Only order's size to be amended downward
• Margin is calculated on the actual size of the position to be reduced
• Market orders can also be Reduce Only and are downsized to position size before entering the market

Behavior Details:

• If a Reduce Only order is smaller than the position size and is resting, and the position is reduced but remains larger than the Reduce Only order, the order remains unchanged
• When position changes occur, the entire order book on the account is evaluated:
  • Resting orders are counted against any position
  • Any resting Reduce Only order that exceeds the accumulated offsetting position will be reduced or canceled

# Close Orders

Setting the execInst parameter to Close and the quantity parameter to null creates an order that will completely close an existing position:

• The order size is automatically set to exactly match the current position size in the opposite direction
• Ideal for quickly exiting positions without calculating the exact position size
• Can be combined with other order types (e.g., Stop with Close to create a stop-loss that closes the entire position)

These position management instructions provide powerful risk management tools, allowing traders to protect profits and limit losses without constant manual order size adjustments.

# Additional Execution Instructions

# ParticipateDoNotInitiate (Post-Only)

Setting the execInst parameter to ParticipateDoNotInitiate (also known as "post-only"):

• Ensures the order will only rest in the order book and never aggress (take liquidity)
• If the order would cross and aggress against an existing order, it is canceled instead
• Useful for market makers and fee-sensitive traders who want to ensure they only receive maker fees
• Can be combined with other order types like Limit orders

# Contingent Orders

Contingent orders allow traders to create sophisticated order relationships and automated trading strategies. The Nekuti Matching Engine supports two types of contingency relationships:

# One Cancels the Other (OCO)

Set contingencyType to OneCancelsTheOther and provide the same clOrdLinkID for all orders in the group:

• All orders in the group rest in the market immediately
• If any order in the group is partially filled, all other orders in the group are canceled immediately
• The partially filled order continues to rest and execute normally
• Useful for placing multiple exit strategies simultaneously (e.g., take-profit and stop-loss)

# One Triggers the Other (OTO)

Set contingencyType to OneTriggersTheOther and provide the same clOrdLinkID for all orders in the group:

• The first order placed in the group acts as the trigger
• All subsequent orders in the group are held back until the trigger order is fully filled
• Once the trigger order completes, all other orders activate simultaneously
• These activated orders can themselves be OCO orders, creating complex order chains
• If the triggering order is canceled or expires, all dependent orders are also canceled

# Implementation Details

• Contingent orders can be combined with stops or if-touched orders
• Contingency groups must have unique clOrdLinkID values across all accounts
• The order of placement matters for OTO orders (trigger order must be placed first)
• Complex strategies can be built by nesting OTO and OCO relationships

Contingent orders provide powerful tools for implementing complete trading strategies with entry, take-profit, and stop-loss components in a single operation.