Products

Products in MarketGrid are a set of tables that define the entities that are traded using the System.

For more details, see: Product hierarchy

Sessions and Trading Rules

How an InstrumentMarket is traded, and what rules apply to orders entered for each InstrumentMarket, is governed by the Session and Trading Rules that apply to each InstrumentMarket.

Session

At any time, a particular Session applies to each InstrumentMarket. The Session effectively defines the matching algorithm that is used for the InstrumentMarket.

Session Change Trigger

A Session change for any Product (Market, InstrumentGroup, Instrument or InstrumentMarket) may be initiated by a manual administration operation or automatically at a specific time. The Session for an InstrumentMarket may be triggered by one of the following:

  • The Session for a parent of the InstrumentMarket (Market, InstrumentGroup, Instrument) changes and the InstrumentMarket has been setup to inherit changes from that parent through its Inherit_Market, Inherit_InstrumentGroup or Inherit_Instrument fields.
  • The Session for the specific InstrumentMarket changes.

When a Session changes for a particular Product (a Market, InstrumentGroup, Instrument or InstrumentMarket), an InfoMessage will be sent to all Users informing them of the change.

Session Flow

At any point in time, every InstrumentMarket is trading in one of the possible Sessions from the table above. When the Session changes (triggered as described above), the current Session is terminated and the new Session is started.

For each InstrumentMarket, when its Session changes, the following steps will occur:

  • The System will automatically withdraw any active orders for the InstrumentMarketthat have the Order Type expiry set to Good For Session.
  • It can be specified for the Session change that all active orders for the InstrumentMarket, regardless of Order Type should be automatically withdrawn, in which case this will be done.
  • Any orders not automatically withdrawn will be removed from the order book for the InstrumentMarket and re-entered. In being re-entered, they will be re-validated against the rules in force for the new Session InstrumentMarket. Any orders that fail validation will have their Status set to Invalidated and will not be entered in the order book. During the new Session, an Invalidated order can be amended to allow it to pass validation and to enter the order book, if required.

Session Matching Algorithms

NOTRADING Session

This Session is used to place Products into a state where new orders and amendment of existing orders is not possible. However, existing orders can be cancelled and off-market trades can be reported.

CLOSED Session

This Session is generally used at the finish of the Trading Day for Products. Orders may not be entered, amended nor cancelled and trade reports may not be entered.

AUCTION Session

During an AUCTION Session, new orders may be entered and will be placed in the order book, but no matching will occur. This means that the order book may become "crossed" which means that there may be buy orders in the order book with prices higher than the highest price sell order.

For each InstrumentMarket in an AUCTION Session, when the Session finishes, the Trading System calculates a matching price that will generate the greatest volume of trades (by lots traded) from the orders in the order book at that time. It then matches the orders in the order book using a price-time priority algorithm to generate the trades.

During the AUCTION Session for an InstrumentMarket, the Trading System will calculate an indicative price every few seconds, which is the price that would be generated if the Session was closed at that time. The indicative price will be distributed with Level One data for the InstrumentMarket.

During an AUCTION Session, Order Types FillOrKill, FillAndKill, and Market are not accepted since they are all Order Types that require matching to be done immediately.

CONTINUOUS Session

During a CONTINUOUS Session, for each InstrumentMarket, new orders may be entered 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 Trading System.

  • A Limit order will match to the extent possible with the balance resting in the order book.
  • A Market order will match to the extent possible with existing orders in the order book with the unmatched balance withdrawn.
  • A FillOrKill order must match completely with existing orders in the order book otherwise it will be withdrawn and not matched at all.
  • A FillAndKill order will match to the extent possible with existing orders in the order book with the unmatched balance withdrawn.

New orders are added to the order book in price-time priority, that is, with priority given to the best price (highest for buy orders, lowest for sell orders) and for orders at the same price, priority is given in the time order that the orders at the same price were received by the Trading System.

Assignment of Session and Trading Rules

At any time, a particular set of Trading Rules applies to each InstrumentMarket. For each InstrumentMarket, its current set of Trading Rules is used to validate orders entered for the InstrumentMarket. The Session and Trading Rule parameters outlined above may be set for the following Products:

  • InstrumentMarket
  • Instrument
  • Instrument Group
  • Market

At any point in time, for each InstrumentMarket, the current active Session and set of Trading Rules is derived from the values set for that InstrumentMarket and its parent Instrument, InstrumentGroup and Market.

Each InstrumentMarket_ has three additional parameters:

  • Inherit_Market
  • Inherit_InstrumentGroup
  • Inherit_Instrument

These parameters have a value of 1 or 0 (TRUE or FALSE). When the Trading System is started and the static data tables are first loaded from the MarketGrid Static Database, for each InstrumentMarket_, its initial active Session_ and set of Trading Rules is determined as follows:

  • If Inherit_Market is TRUE then the InstrumentMarket's active Session and set of Trading Rules will be set to those of its Market
  • Else if Inherit_InstrumentGroup is TRUE then the InstrumentMarket's active Session_ and set of Trading Rules will be set to those of its InstrumentGroup (the InstrumentGroup to which its Instrument belongs)
  • Else if Inherit_Instrument is TRUE then the InstrumentMarket's active Session_ and set of Trading Rules will be set to those of its Instrument
  • Else the InstrumentMarket's active Session_ and set of Trading Rules will be set to those of itself

During trading, if the Session or any of the Trading Rules is changed for a Market, InstrumentGroup or Instrument, the corresponding active setting for any InstrumentMarket that has its Inherit parameter TRUE for the changed Product will have that corresponding active setting changed.

For example, for the Market SmallStones, if the Session is changed from AUCTION to CONTINUOUS, any InstrumentMarket in the SmallStones Market that has Inherit_Market set to TRUE will have its active Session changed to CONTINUOUS. If an InstrumentMarket in the SmallStones Market has Inherit_Market set to FALSE then its active Session will not be changed when the session for the Market changes.

ExchangeRate →

Used to persist the prevailing exchange rate for each currency pair when the system is shut down or shared memory is refreshed. For fast lookup of the exchange rates in the engine, see the `CurrentExchangeRate` table. For consumption of rates by other processes, see the `ExchangeRate_change` change table.

Fee →

Fees are reserved on orders and paid on trades. This table stores fee configurations & multiple Fee records are grouped in the FeeSet table. [More details on fees](/concepts/trading/fees)

Industry →

Industries are a part of the mechanism for the economic classification of the Instruments that are modelled in the system. An Industry is a collection of Sectors and an arbitrary number of sectors may be placed within an Industry. Each Sector_ that is defined in the data, must belong to one Industry.

Instrument →

An Instrument is the entity that represents something to be traded in MarketGrid. In order for an Instrument to trade it must be listed on a Market_ to produce an InstrumentMarket_. Each Instrument may be traded simultaneously on one or more Markets, each such instance being an InstrumentMarket_.

InstrumentGroup →

An InstrumentGroup is used to group Instrument instances into logical sets, such as Equities or Currencies, to facilitate the setting of common parameters and rules across each InstrumentGroup.

InstrumentMarket →

InstrumentMarket is the entity that represents an Instrument in a specific Market. It is the entity for which all trading activity is undertaken and at which level all the market data is collected for distribution.

Market →

A Market is the entity used to provide the mechanism by which a set of Instruments can be traded using a common set of parameters and rules. Each Instrument_ may belong to one or more Market_ enabling the Instrument_ to be traded simultaneously using different rules and matching algorithms

PriceStepSet →

A PriceStepSet defines a set of price steps that are permissible when validating the price being used for a particular Entity. Each price step is applied from a given price point until the next price step is defined.

QuantityStepSet →

A QuantityStepSet defines a set of quantity steps that are permissible when validating the quantity being used for a particular Entity. Each quantity step is applied from a given price point until the next step is defined.

Sector →

Sectors are the primary mechanism for the economic classification of the Instruments that are modelled in the system. A Sector is a collection of Instruments that usually share a common underlying economic characteristic that makes grouping them convenient for a number of purposes.

Session →

The Sessions that define the matching algorithms that may be used for Products are maintained in this table.

SessionTime →

Controls when Sessions and Trading Rules are applied to Products.