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.
The term “trading data” is used to describe three fundamental transactions types.
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.
Order data is stored in a
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 |
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:
#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:
The above CSV file can be created or edited
using MS Excel as shown in fig 1.
Figure 1: A Sample of Orders Data
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.
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.
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 |
|
45.830 |
190 |
3848629713164480000 |
|
49.750 |
101 |
2420623594072300000 |
|
45 |
5000 |
432356253461069000 |
|
49.990 |
290 |
5065228636431650000 |
|
|
|
|
|
51.5 |
250 |
6572914060944080000 |
|
|
|
|
|
54 |
197 |
8890248881250480000 |
Table 2: Content of the orderbook when all orders have been processed
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.
The orderbook can be manipulated using the following operations:
The following examples highlight the changes made on the orderbook due to the above manipulations:
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.
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.
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.