Continuous

During continuous matching, new orders are accepted and will be matched immediately against existing orders on the opposite side of the book (buys against sells, sells against buys), if possible.

Depending on the order type of a new order, if it cannot be matched against existing orders, it may itself be placed into the order book or immediately withdrawn by the system:

• A limit order will match to the extent possible against existing orders in the book and the residual balance will be added to the book.

• A market order will match to the extent possible against existing orders in the book and the residual balance will be withdrawn.

• A FOK order must match completely with existing orders in the book, otherwise it will be withdrawn and not matched at all.

• A FAK order will match to the extent possible with existing orders in the book with the unmatched balance withdrawn.

Note: The difference between a market order and a FAK order is that a FAK order may have a limit price, while a market order matches at any price(s) available in the book.

Unless custom behaviour is required, orders are executed in price-time priority. That is to say, better prices (lower for sells and higher for buys) will be prioritised ahead of worse prices, and for the same price, older orders will be prioritised ahead of newer orders.

Matching Algorithm

For all incoming orders, the system attempts to fill as much of the order as possible at the best possible price. For buy orders, the best price is the lowest price on the sell side of the order book; for sell orders, it is the highest price on the buy side of the book. If the order cannot be matched in full, it will either be withdrawn or partially matched, depending on the trading type of the order.

Crossing: Two orders are said to 'cross' if they are of opposite sides (one buy, one sell) and the buy order is of an equal or higher price than the sell order, or one is a market order.

Incoming limit order

For an incoming limit order, the algorithm is as follows:

1. Let the 'resting orders' be an sequenced set of orders on the opposite side of the order book, in price-time priority. That is to say: the first order in this sequence is the oldest order at the best price, the next order is the next-oldest order at that price or the oldest order at the next-best price, and so on.

2. Let the 'considered order' be the first of the resting orders.

3. Compare the price of the incoming order with the price of the considered order.

4. If the prices cross:

   1. Generate a trade for the quantity that crosses.
      1. If the incoming order is fully filled, move it to a Matched state.
      2. If the incoming order is not filled, let the next order in the price-time sequence be the considered order, and go to step 3.

5. If the prices do not cross:

   1. Add the residual balance of the incoming order to the order book at its limit price.

Incoming immediate order

For an immediate order (a market, FAK, or FOK order), the algorithm is above, with the following alterations:

• Before step 2:

  • If the order is a FOK order, steps 2-4 are performed without generating any trades in order to determine the quantity that is available to execute against the order. If this quantity is less than the quantity of the incoming order, the order will be withdrawn without any matching.

• At step 4.1.2:

  • If the order is a market order and the MarketOrderSweepDepth setting is configured on the Market, the order will be withdrawn once the specified number of price levels has been reached, regardless of its residual balance.

• At step 5:

  • If the order is a market or FAK order, the residual quantity is withdrawn instead of being added to the book.

Order book example

Here is a sample continuous OrderBook, noting the non-overlapped price ladder with bids shown in green at the bottom left and asks shown in red at the top right, all mapped against a vertical, increasing price ladder. The last trade is shown at $3,040 in bold.

Suppose a buy order is entered for a quantity of 90 at a price of $3,060. It will be executed as follows:

After matching, the best ask is moved to $3,060, and the balance at that price is 30. The incoming order is fully filled, so there is nothing to add to the book.

Priority

Orders are executed according to price-visibility-time priority: at any given price, all visible orders are executed before any hidden orders, and older orders are executed before newer orders.

If pegged orders are used, midpoint pegs are prioritised ahead of bid or ask pegs.

Advanced priority settings

In addition to the standard price-time priority, it is possible to configure:

• Priority matching for a Firm;
• Priority matching for specific kinds of Account.

Firm priority matching is a simple form of prioritisation that allows orders from certain firms (such as a house firm) to be matched before other orders at the same price, regardless of time priority.

Account type priority matching is a more granular form of control that allows for different types of accounts to be prioritised according to a custom ranking. This is used for fine-grained control over matching.

Firm priority matching

Priority matching for Firms is configured by setting the FirmPriorityMatching field on the Firm.

Each Firm may be assigned one of the following priority settings:

• None: the firm's orders obey normal price-time priority
• First: at a given price, the firm's orders will be matched before all orders that are not prioritised.
• AfterMm: at a given price, the firm's orders will be matched before orders that are not prioritised, but after orders from market-maker accounts.

Account type priority matching

Priority matching for Accounts is configured by using AccountTypes. Each Account is assigned one AccountType, which represents the class of account. This may be used to differentiate market makers from regular broker accounts, or to create multiple tiers of accounts with different priority settings.

In this model, each AccountType may be assigned a MatchingPriority value from zero to 255. Accounts with higher priority values are prioritised before accouns with lower priority values.

Account type priority matching must be enabled on the InstrumentMarket by setting the MatchingPriorityType field to AccountType.

See also

The behaviour of the matching algorithm may be impacted by the following:

• Position tracking
• Limits tracking
• Self-trade prevention