Vonmo Trade Experiment. Part 2: Orders. Types and processing features

To figure out how exchanges work, we need to look into exchange orders and the way broker processes them.
This article deals with order types, the way they are executed at an exchange, and limitations imposed by trading system.

If you are curious to know what all those DAY, GTC, FOK, IOC, GTD, GAT, MOO, MOC, LOO, LOC, MIT, OCO, OSO, PEG mean, you are welcome.

Orders

All market players are interested in a good deal. To start bidding, we need to create a sell or a buy order for a required financial instrument. Consequently, a set of orders placed on the exchange creates current supply and demand. A market order is instructions from a client to their broker to buy or sell financial instruments at the exchange.
A typical order contains the following information:

• Financial Instrument Identifier
• Order type
• Order side. Buy or sell.
• Price
• Quantity
• Order duration type (optional)
• Additional instructions (optional)

We can break all the orders into three big groups:

• Market orders. This order must be executed immediately at the current market price. If there is no necessary amount, then the order is executed as soon as possible.
• Pending orders. A request enables to control the limit prices for buying and selling. Sometimes such orders can not be executed straightaway or at all. The price is always better for limit orders.
• Conditional orders. These are all requests except limit ones that require extra conditions to be activated and executed.

Time in force

You have, for sure, seen acronyms like DAY, GTC, FOK, IOC, GTD, GAT All of them indicate how long an order will remain active before it is executed or expires.

• DAY. These orders expire at the end of the trading day.
• GTC (Good till canceled). This order is valid until it is cancelled. To make sure they don’t stay at the market indefinitely, a special limitation is imposed, which is usually from 30 to 90 days.
• FOK (Fill Or Kill). The order must be fully filled or immediately cancelled.
• IOC (Immediate Or Cancel). The order is immediately executed or cancelled by the exchange. Unlike FOK, this type allows for partial fulfillment.
• GTD (Good-til-Date/Time).
• GAT (Good-after-Time/Date).

Conditions of order execution

By combining instructions on prices, time in force and extra limitations, we can get various types of order execution. To get a better idea, let’s get back to the order types structure which is presented at the beginning of this article.

Market-on-open/close orders

If we limit the duration of period when this market order is valid, we get the following:

• MOO (Market-On-Open). A market order of such type can be executed only at the opening of the trading day. Its execution is guaranteed provided there is liquidity.
• LOO (Limit-On-Open). Like MOO, LOO can be executed at the opening of the trading day only. However, limit orders of this type enable for setting instructions for the price. The execution is not guaranteed.
• MOC (Market-On-Close). These orders are similar to MOO, but the market order can be executed at the closing of the trading day only. The execution is guaranteed provided there is liquidity.
• LOC (Limit-On-Close). These orders are similar to LOO, but the market order can be executed at the closing of the trading day only. The execution is not guaranteed.

Conditional orders

When we want to tailor our orders for some trading strategy, we can do it with the help of conditional orders – the ones which are activated only after the condition has been satisfied. Thus, their main aim is to minimize the risk of significant financial losses.

Stop order

Stop order is a bid or an ask for a certain amount of a financial asset at a specified price or worse. As soon as the price equals or exceeds the specified stop price for a bid order, it automatically turns into a market order and is executed on general grounds. It works the same way with a stop order for selling. As soon as the price reaches the level set in the order and continues to fall, the order turns into a market one. This way, execution is guaranteed for active stop orders. Stop orders let us minimize potential losses, that’s why stop loss is the synonym for the stop order.

Stop-limit order

Unlike usual stop orders, where just the stop price is specified, stop-limit orders require also a limit price.
As soon as the asset price is equal or worse than the stop price, a limit order with the specified limit price is automatically created. The execution of such order is not guaranteed.

Trailing stop order

Unlike usual stop orders, where the stop price is shown in absolute units, trailing orders use percentage. After activation, it turns into a usual market order. This way, the stop price is linked to the market price and grows with it. For example, we’ve placed an order for 10 dollars and set the stop price at 10% from the current one, i.g. the absolute stop price equals 9 dollars. Then, the asset grew to 15 dollars alongside with the stop price which grew to 13.5 dollars.
This order type is used to minimize losses as well as maximize profit.

Trailing stop-limit order

Unlike trailing stop orders, this order turns into a limit one, not a market one, after activation.

PEG order

This is a kind of limit orders. It changes its price automatically after the change of bid or ask prices. In price instructions a shift for the worse from the current best bid/ask price is indicated.

OCO order (one cancels other)

This is a pair of orders. It usually consists of a stop order and a limit order. Both orders work with the same instrument. If one of them is executed, the second is automatically cancelled.
A simple example: let’s imagine that we’ve bought an asset for ＄10. We aim at getting at least ＄3 of profit and limiting the losses to ＄2 at most. Then our stop price will be ＄8 and our limit price ＄13.

OSO order (one sends other)

This order consists of the main order and a group of linked orders. Orders can work with different instruments. If the main order is executed,all linked orders are then sent.

Now when we’ve briefly reviewed orders theory, let’s get down to practice.

Practice

From the system point view, it’s crucial to define the basic structure for all orders in a flexible, but precise way. Erlang enables us to do that with the help of records:

-record(exchange_order, {
  id :: binary(),
  orig_id :: binary(), 
  ticker :: binary(),
  owner :: binary(),
  trader :: binary(),
  type :: non_neg_integer(),
  side :: non_neg_integer(),
  time_in_force :: non_neg_integer(),
  price :: binary(),
  trigger_price :: binary(),
  qty :: binary(),
  orig_qty :: binary(),
  created_ts :: non_neg_integer(),
  updated_ts :: non_neg_integer(),
  deals_history :: [#exchange_deal{}],
  linked_orders :: [#exchange_order{}],
  opts :: map()
}).

Order identification

After an order has been placed on the exchange, it gets an internal identifier – id field.
To improve user’s experience, when we are coordinating the exchange with external systems, we should enable an external system to set its own id to the order being created. It will give us a possibility to request orders both by id and by orig_id. Also, it will enable us not to use extra order mapping in the external system.

Order ownership

Let’s provide a possibility to create an agent (external broker) in our system. Orders can come directly from traders or from a broker that provides services to clients who don’t have direct access to the exchange.
In case of a direct order owner and trader coincide.

Instruction encoding

Let’s look at the rest of the fields. There are two fields for encoding the instructions by price: price, which is the limit price for limit orders, and trigger_price, which is the trigger price for custom types. For instance, in case of stop orders this field will encode the stop price.

We use qty and qty_orig for encoding the volume. Qty_orig sets the initial order volume and qty – the order volume while being fulfilled.
deals_history array will help to have precise information about partial fulfillments. With its help we can, for example, calculate the average price of the order after it’s been fully filled.
linked_orders field is necessary for encoding the information about linked orders for OCO and OSO.

To enlarge the system without changing exchange_order record, let’s add opts field which is a dynamic dictionary.

Interim conclusion

To be honest, I thought that the second part of the series would be more compact. However, I had to be more detailed to elaborate on the topic.
The theoretical part of the following article will shed the light on order book and the rules of order processing. The technical part will deal with the scheme of market data processing and issues of historical data storage.

Thanks to Nadezda Popova for proofreading.