Session1: Trade Data Fundamentals and Securities Orderbooks

6 May 2012

 

The aim of this session is to learn about the elementary data types used by a trading engine. It focuses on a core component of any trading engine that is the order book.

Basic Assumptions

  • Students need to be familiar with the general concept of an electronic market, its participants and the way they interact with the market through transactions.
  • Although an electronic market is about buying and selling anything, we will be mainly addressing the buying and selling of financial securities. Students need to have some notions of what is a security in general and in an equity(or stock) in particular since we will be focusing on equities (or stock) markets. Many of the concepts explained here can be adapted to other products.
  • The computer system that implements the markets rules is called the trading engine. Transactions are submitted to the trading engine through some kind of communication network. We call these transactions input transactions. In turn, the trading engine generates transactions called output transactions.
  • In the practical exercises, the tools associated with most sessions use the concept of CSV files to avoid having to consider a communication network. CSV files will be used to represent list of transactions that are either submitted to the trading engine (input CSV files) or produced by the trading engine (output CSV files). In general, CSV files store comma-separated values where the values of one transaction (e.g. trading order) are entered in one line and separated from the next transaction by the newline character.
  • CSV files can simply be generated using MS Excel worksheet and then using “save as” option and selecting “Comma delimited” option. Alternatively, any simple editor can be used as Notepad or Vim (Warning: in some cases Excel changes the original data so you need to be careful when handling certain data types like dates and very long integers).

Introduction to trading data

The term “trading data” is used to describe three fundamental transactions types.

  • Order processing: correspond to requests from the market participants (i.e. brokers) regarding the buying and selling of securities. Such transactions can correspond to submitting an order (i.e. bid or ask), amending existing orders, or deleting existing orders. This is the main focus of this session.
  • Trades: such transactions are typically generated by the trading engine once some orders have been matched with each other. They indicate details such as the volume of the trade and the prices. Trades will be the subject of Session 2.
  • Market events: represent particular events such as the opening/closing of the market and moving between different market phases. Such transactions are usually called control transactions.

Different systems that participate in an electronic market use different methods for formatting and storing the trading data. This session will use the format used by Sirca, the main provider of financial market data to Universities in Australia and New Zealand. Starting from a basic format, this will be extended with more fields in future sessions. The main purpose here is to illustrate the construction and management of an order book for each security based on the input transactions.

Activity 1

Description of order transactions

Order data is stored in a CSV file. Each row basically corresponds to one transaction and each column corresponds to the attribute of the transaction. Here is the description of all different attributes of an order transaction that will be used in this session:

Instrument

Date

Time

Record Type

Price

Volume

Value

Trans ID

Bid ID

Ask ID

Bid/Ask

Security

Date of the order

Time of the order

Order status i.e.  Enter, Amend, Delete

The Price

The Volume

The Value

Transaction ID

The Bid ID

The Ask ID

A - Ask

B - Bid

String

Date
YYYYMMDD

Time HH:MM:SS[.MMM]

String

Double

Double

Double

Long Int

Long Int

Long Int

String

Table 1: Initial attributes in input transactions

The attributes are always listed in the first line of the file so they may appear in different columns. More attributes will be introduced in later sessions.

The attribute “Record Type” can be one of the following:

  • “Enter”    :  the order is being submitted from the dealer to the trading engine. The attribute “Bid/Ask” will specify whether it is a bid (“B”) or ask (“A”)
  • “Amend” :  the dealer wishes to amend a previously made order
  • “Delete”  : the dealer wishes to cancel a previously made order

#Instrument,Date,Time,Record Type,Price,Volume,Value,Trans ID,Bid ID,Ask ID,Bid/Ask

MQG,20100401,00:00:00,ENTER,45,5000,225000,5044,432356253461069000,,B

MQG,20100401,00:11:08,ENTER,54,197,10638,5044,,8890248881250480000,A

MQG,20100401,00:17:04,ENTER,51.5,250,12875,5044,,6572914060944080000,A

MQG,20100401,00:18:07,ENTER,49.75,101,5024.75,5044,,2420623594072300000,A

MQG,20100401,00:27:01,ENTER,45.83,190,8707.7,5044,3848629713164480000,,B

MQG,20100401,00:34:02,ENTER,49.99,290,14497.1,5044,,5065228636431650000,A

 

For example the first transaction corresponds to the following order:

  1. Order
    1. Instrument = MQG (Macquarie Group)
    2. Date = 01-Apr-2010
    3. Time = 00:00:00
    4. Record Type = Enter
    5. Price = 45
    6. Volume =5000
    7. Value = 225000
    8. TransID = 5044
    9. Bid ID = 432356253461069943
    10. Ask ID =
    11. Bid/Ask = B

The above CSV file can be created or edited using MS Excel as shown in fig 1.

Figure 1: A Sample of Orders Data

 

 

Activity 2

Description of the orderbook content

An order book is a core component in any trading engine. It is a data structure that stores the input transactions. It maintains two separate lists of orders for each security that are the bid list (contains “buy” orders) and ask list (contains “sell” orders). There is always one order book per security.

  • Bid list is sorted according to price/time criteria where the earliest highest price is at the top of bid list (normally called best bid).
  • Ask list is sorted according to price/time criteria where the earliest lowest price is at the top of the ask list (normally called best ask)
  • The difference in price between the best bid and best ask at a particular time is called the spread.
  • Naturally, more than one order in either bid or ask list can have the same price but for different brokers (i.e. clients). The term price step is used to denote the minimum difference in price between two groups of same price orders. The price can be as low as 1c and can increase for higher value securities.

The orderbook is updated everytime an order is processed by the trading engine. Therefore, it is a dynamic data structure which is changing all the time. Figure 2 illustrates different cases of building an orderbook.

CSE - Orderbook1.jpg

Figure 2: Example of building an orderbook through a succession of ENTER transactions

Another example is the orderbook resulting from the sample of data shown in Figure 1:

Bids

Asks

Time

Price

Qty

ID

Time

Price

Qty

ID

00:27:01

45.830

190

3848629713164480000

00:18:07

49.750

101

2420623594072300000

00:00:00

45

5000

432356253461069000

00:34:02

49.990

290

5065228636431650000

 

 

 

 

00:17:04

51.5

250

6572914060944080000

 

 

 

 

00:11:08

54

197

8890248881250480000

Table 2: Content of the orderbook when all orders have been processed

Representing orderbooks using market depth transactions

To observe the content of the orderbook, trading engines must output a special type of transaction called Market Depth transaction. Each transaction represents a snapshot of the orderbook within a specific depth (e.g. top 4 best bids/asks).

This orderbook can be represented in a textual form by displaying the market depth at any point in time as one transaction stored in one CSV line. The market depth file only shows the total quantity at any given price so if there are many orders with the same price, only the total quantity is displayed.

The transaction record that corresponds to the orderbook shown in Table 2 is as follows:

#Instrument,Date,Time,Record Type,L1-Bid Price,L1-Bid Volume,L1-Number of Buyers,L1-Ask Price,L1-Ask Volume,L1-Number of Sellers,L2-Bid Price,L2-Bid Volume,L2-Number of Buyers,L2-Ask Price,L2-Ask Volume,L2-Number of Sellers,L3-Bid Price,L3-Bid Volume,L3-Number of Buyers,L3-Ask Price,L3-Ask Volume,L3-Number of Sellers,L4-Bid Price,L4-Bid Volume,L4-Number of Buyers,L4-Ask Price,L4-Ask Volume,L4-Number of Sellers

MQG,20100401,00:34:02,Market Depth,45.83,190,1,49.75,101,1,45,5000,1,49.99,290,1, , , ,51.5,250,1, , , ,54,197,1

This transaction shows an orderbook of depth 4. The format could show an orderbook of any depth.

Activity 3

Operations on the orderbook

The orderbook can be manipulated using the following operations:

  • Submit order (“ENTER”): inserts an order of a particular security in the Bid list or Ask list of the corresponding orderbook. The inserted order is placed in the list based price/time time priority.
  • Delete order (“DELETE”): uses an existing order’s transaction id to locate this order in either bid or ask list of the corresponding orderbook and then removes it from that list.
  • Amend order (“AMEND”): amends one or several attributes of an existing order. There are different rules associated with amending an order. In this session, we use ASX rules in which only the volume or the price of an order can be amended as follows:
    • Decrease volume: given the order id, the particular order is located in either bid or ask list of the corresponding orderbook and then its volume attribute is amended with the new value. The amend volume does not affect the queuing position of the order.
    • Increase volume or Amend price: similar to deleting an order and inserting a new order with a new time stamp but with a similar id.

The following examples highlight the changes made on the orderbook due to the above manipulations:

Example 1: Amend Order - Increase Volume or Change Price

Suppose an orderbook with the orders as shown in Table 3.

 

Bids

Asks

Instrument

Time

Price

Qty

Bid ID

Time

Price

Qty

ID

MGG

00:00:01

45.830

190

3848629713164480000

00:00:07

49.750

101

2420623594072300000

MQG

00:00:07

45

5000

432356253461069000

00:00:04

51.5

250

6572914060944080000

MQG

00:00:10

45

50

832356454561069000

00:00:08

54

197

8890248881250480000

Table 3: Example of an orderbook

Amending the bid order 432356253461069000 by adding 400 to the volume is achieved with an order similar to the original order in which the RecordType is changed from ENTER ŕ AMEND:

MQG,20100401,00:00:20,AMEND,45,5400,243000,6111,432356253461069000,,B

The effect is that the existing bid is removed and reinserted into the orderbook and therefore loses its place in the queue with bids having the same price. The resulting orderbook is shown in Table 4.

 

Bids

Asks

Instrument

Time

Price

Qty

Bid ID

Time

Price

Qty

ID

MGG

00:00:01

45.830

190

3848629713164480000

00:00:07

49.750

101

2420623594072300000

MQG

00:00:10

45

50

832356454561069000

00:00:04

51.5

250

6572914060944080000

MQG

00:00:20

45

5400

432356253461069000

00:00:08

54

197

8890248881250480000

Table 4: Content of the orderbook after the volume was increased

Similarly, any amending to the price will result in the corresponding order being at the bottom of the queue with orders having similar prices.

Example 2: Amend Order - Decrease Volume

Suppose that instead of increasing the volume, the bid order 432356253461069000 has 400 reduced from its volume. The corresponding transaction would be:

MQG,20100401,00:00:20,AMEND,45,4600,207000,6111,432356253461069000,,B

The effect is that the existing bid is changed but does not lose its place in the queue with bids having the same price. The resulting orderbook is shown in Table 5.

 

Bids

Asks

Instrument

Time

Price

Qty

Bid ID

Time

Price

Qty

ID

MGG

00:00:01

45.830

190

3848629713164480000

00:00:07

49.750

101

2420623594072300000

MQG

00:00:07

45

4600

432356253461069000

00:00:04

51.5

250

6572914060944080000

MQG

00:00:10

45

50

832356454561069000

00:00:08

54

197

8890248881250480000

Table 5: Content of the orderbook after the volume was decreased

Figure 3 illustrates both cases of amend with a different example.

CSE - Orderbook amend.jpg

Figure 3: Examples of amending an orderbook

Example 3: Delete an order

Deleting an order is achieved with a transaction having RecordType equal to “DELETE” and quoting the original bid or ask order ID. For example:

MQG,20100401,00:11:59,DELETE,,,,7890,,8890248881250480000,A

When applied to the orderbook in Table 3, the resulting orderbook is shown in Table 6.

 

Bids

Asks

Instrument

Time

Price

Qty

Bid ID

Time

Price

Qty

ID

MGG

00:00:01

45.830

190

3848629713164480000

00:00:07

49.750

101

2420623594072300000

MQG

00:00:07

45

5000

432356253461069000

00:00:04

51.5

250

6572914060944080000

MQG

00:00:10

45

50

832356454561069000

 

 

 

 

Table 6: Example of an order deletion

Figure 4 illustrates a case of deleting an order.

CSE - Orderbook delete.jpg

Figure 4: Example of deleting an orderbook