Dennis Chen's blog

Algorithmic Trading

2009-07-31T00:05:00.000-07:00

Algorithmic Trading has been a hot topic for equity/derivative trading over a decade. Many ibanks and hedge funds have built their own algorithmic trading systems. Simply speaking, Algorithmic Trading System is an Artificial Intelligence(AI) System to simulate human traders' doing but it can do it much faster and manage much more orders. From the aspect of purposes, there are two types of Algorithmic Trading strategies(algo) in the market. One type of algo being used by hedge fund or proprietary trading, the ultimate goal is to "buy low and sell high". The performance of this type of algo is measured by trading profit from the round trip of buy and sell. The other type being used by agency broker to improve client order execution quality from one trip in buy or sell. The performance of this type of algo is measured by benchmarks, e.g VWAP, arrival price, close price etc..

This article is to discuss some of the popular agency(broker) trading algo.

1. Algorithmic Trading System

An algorithmic Trading System is usually quite complicate and can be built quite differently from one broker to another. However, if we break it down into functional areas, a typical Algo system usually consists of the following components

1.1 OMS(client orders)

OMS stands Order Management System and it is the place where client orders are held. OMS sends client orders(e.g. DSA orders) to Algo Engine for algo execution. Algo Engine works on the client order according to the instruction and sends executions and order status back to OMS.

1.2 Historical Market Data

This is usually a DataBase system which stores the raw and/or summarised historical market data that can be requested by Algo Engine for strategy decision. Examples are volume curve, average bid/ask volume, average bid/ask spread etc..

1.3 Real Time Market Data

Algo trading systems requires the real time market data to drive most of the tradings. e.g. bid/ask price, bid/ask volume. Broker can get market data directly from exchange or through vendors such as Reuters or Bloomberg, Wombat etc..

1.4 Exchange Access

Usually, an Algo Engine wont connect directly to exchange, it can make use of an exchange interface server which is shared by other trading system(e.g. high touch system), providing the latency is acceptable.

1.5 Algo Engine

This is the core part of the algo trading system, where the artificial intelligence is and where all the algo strategies store.

2. Some Basic Algo Concepts

This chapter is to talk about some basic but important concepts in algorithmic trading

2.1 Market impact

The orders require algo trading are usually large quantity orders. Those orders are quite likely to have huge impact to the market if whole or large part of quantity is released in one shot. Market impact by the order itself can drag the stock price towards the unfavourable side. To prevent a huge market impact, algo systems usually send many "slices" into the market over a period of time.

2.2 Passive Queuing

To improve execution price, a general approach is to queue the order passively in bid side(for buy orders) or ask side(for sell orders). This is to avoid paying the buy/sell spread. Take an example HSBC(00005.HK) as of now price is HK$70, buy/selll spread is HK$0.05 or 7.14 base points. Lots of brokers offer execution cost lower than 7 bases points these days, so order passive queuing can make a huge difference in the execution cost and profit making.

2.3 Aggressiveness

There are usually two goals for an algo order:

1. Price improvement.
the algo should try to seek price improvement. This implies the order should stay passive and avoid paying the spread

2. Completion of the order.
The algo should execute as much as the quantity of the order as it can towards completion within a defined time. This implies the order need to go aggressive, execute faster and cross the spread if the volume done is behind the trade plan.

As you can see these two goals are not always consistent. Especially when the market is moving away, they are actually in conflict. Most of algos will provide one or a few risk parameters for clients to control the aggressiveness of the algo orders to balance the need of these two goals.

3. Strategies

Some commonly used broker strategies are discussed below

3.1 VWAP

A VWAP strategy is benchmarked against market VWAP or order timed VWAP. A well implemented VWAP strategy should meet or beat the marke VWAP over the long run by average(but not in every case!)

Implementation

As we discuss above, to avoid market impact, we need to "slice" the order over the day with a number of market orders. A VWAP strategy usually requires the 20-60 days averaged historical volume curve from a stock to construct the trade plan. Base on the trade plan, VWAP strategy will try to complete % of the order at certain point of time. The following is an example of VWAP trade plan:

In theory, the VWAP strategy should follow the historical volume as much as possible since the VWAP algo philosophy is "history will repeat itself". On the other hand, we want price improvement and we need to queue order passively, but the timing of passive order execution is unpredictable since it is subject to some one else in market hitting your order. To allow certain time frame for passive orders to fill and enforce the volume curve to be followed to certain extent, we can define an aggressiveness factor. This aggressiveness factor is effectively of a % of volume of slippage. In the chart shown above, the black series shows the historical VWAP curve. The x axis is the % of the time span. The y axis is the % of the order volume we should complete. The yellow line shows when we should stop putting passive orders into market. The purple line shows when we should cross the spread to catch up when passive orders are not getting filled.
Basically we allow a zone of between yellow and purple lines for the passive order to operate in.

3. 2 TWAP

TWAP is similar to VWAP except the the trade plan is a straight linear line up such that it doesn't require historical volume curve. TWAP is used when trader believe that a stock doesnt have any volume pattern to follow, e.g. a low liquidity stock.

3.3 POV

A POV strategy can be benchmarked against both
order timed VWAP and arrival price. POV usually aims to execute a large order in a short time. The philosophy of POV is to "follow the crowd".

Implementation

The implementation of POV is relatively simple. Basically the algo system needs to listen to market trade volume and make sure our order follows it. Again, to allow the effect of passive queueing, we can define an aggressiveness factor like VWAP to let passive orders to operate within certain range of slippage.

3.4 IS

IS(Implementation Shortfall) strategy is benchmarked against arrival price. The goal of this strategy is try to execute the order at a price of close to(or better than) the arrival price.

Implementation

The implementation of IS is to execute large amount of order at very begining then slow down the execution gradually. The implementation can be similar to POV but with high participation rate at begining and low participation rate towards the end.

"In the money" and "Out the money"

When the stock price goes the same as or better than arrival price, this is called "in the money"; while the opposite is called "out the money". Some people suggest that the algo should execute the order more when it is "in the money", while some people suggest the price factor should be totally ignored.

3.5 MOC

MOC(Market On Close) is benchmarked against close price. The strategy is to execute the order when the time is close to market end and take full advantage of close auction(if any).

Implementation

MOC order usually contains a POV constraint instruction e.g. "30% of market on close." Even no such constraint on the order, we should still follow the magic number of 30% of market unless the client instruction is "must complete". The implementation of MOC is to look at the historical average volume curve of the stock. if the order quantity is over 30% of the close volume, we should start execute the order before the close auction and try to keep below 30% of the market.

3.6 SNIPER

A sniper strategy is quite simple. It doesn't queue any passive order in the market. You define the criteria yourself e.g. if best bid price > $100 and bid volume >5000, the algo will send a marketable order into the market when the criteria is met. SNIPER strategy is used for orders which client doesnt want to expose the intention of participation. Examples are those low liquidity stocks.

4. Some Considerations and Techniques

The is chapter is to discuss some common considerations on algo execution and tecniques.

4.1 Gaming

As of today, AI system is dumb as comparing to human brain. The merit of AI system is all about its speed, which translate to the capability of working on massive volume of data on a well defined and quantified domain. One consideration of algo implementation is to avoid the "dumb" AI system being gamed by other participants in the market. The techniques include(but not limit to) the following:

Avoid falling into a pattern. Add some randomness to your order slices and timing. Do not strictly follow an easy calculated formula.

Have some threshhold in price and/or volume of your order. Dont let the market lead your order to any price range, this is especiallly important for low liquidity stocks.

With above, feel free to implement some alarm system to send alert to human trader if the market goes beyond your algo defined thresholds. This is when the human trader should consider pick up the order manually.

4.2 Spread Crossing

When market buy/sell spread is one price step, this is easy. But what if the buy/sell spread is as wide as 2+ price steps? When your order is falling behind the trade plan, do you cross multiple price spreads to catch up? This can be quite costly. Naturally, one might suggest that this can be done with price step by price step. e.g. post a passive order on best + 1 price step for a buy order and do so again if we don't get filled. One challenge of this
implementation is the need of avoiding feedback loop. e.g. your best+1 order will change the best price in the market and which will drive your order send a new best + 1. The feedback loop effect will become worse when you have multiple orders of the same stock and same side, since each order will compete with other and quickly move the market price towards the unfavourable side.

4.3 Multiple level queuing

Now we all know the benefit of passive queuing. To take this a step further, we can implement multiple passive orders to queue in different price level. The benefit is that we have further price improvement when market is moving rapidly towards us(e.g. someone in the market sending a market type of order to take out multiple price level of orders at your passive orders side). The cost of this is the implementation complexity plus you are telling the people in the market that "I am running an algo order".

4.4 Trading Risk

As any trading system, an algo system bears with trading risk and even more so than others for the obvious reason. Apart from testing perspective to make sure system is rock solid. There are a number of checks and thresholds that we can consider to implement to prevent an algo system go "rogue":

An abosulte price change vs close/open price. e.g. the aglo
will only trade within 10% variation of the last close price.

A "fair" price check. This can be done by some calculation
with the combination of open price and last few price movement.

ADV(Average Daily Volume) check. an order over 30% of this
is considered to be risky and may need hand trading.

Trade frequency check. If a stock has only been traded average 10 times a day over the last month. Would you trust algo to trade it?

5. Some Misconceptions on Algo

Algorithmic Trading System should be treated as a tool not a trader. It is good to know the strength and weakness where algo lies at.

"A good algo system should always beat human trader"

Yes and no. Given an experienced human trader and a good algo system, and assign only one algo order(say a VWAP order) for them for a
day, the human trader should beat the algo system. However, the human trader will struggle with 50+ VWAP orders, but a good algo system makes no difference of 1 order to hundreds of orders. The strength of algo system, just like any other computer system, lies at the processing power.

"A good algo system should always beat market VWAP"

Not quite. Assuming doing VWAP orders, a good algo system doesn't beat
market VWAP in every order(remember just like doing everything in real life, luck plays a factor here). However, a good algo system can beat market VWAP over the long run by average.

"A good algo system should work for low liquidity stocks"

As comparing to high liquidity stocks, an algo system usually
perform poorly at low liquidity stocks, so be ready to take some risk. It's worth to mention SNIPER can work well with low liquidity stock, only if the target price is well defined.

Electronic Trading

2009-07-07T02:08:00.000-07:00

This article is to discuss the operation model between Fund Managers(Client) and Broker Firms. They are usually referred as Buy Side and Sell Side.

High-Touch Model

Traditionally, the Buy Side and Sell Side have been operating in the way of

Clients(fund managers) send order to sales trader. This can be by means of phone calling, email, FIX message or data exchanged through third party software.
Sales Trader enters the orders into firms Order Management System(if its not electronically sent in) and assign them to different execution traders.
Execution Trader(or Dealer) picks up the orders(and communicates to Sales Trader if necessary) and enter the order into Trader Workstation.
The orders sent by Trader Workstation and get traded in exchange.

The diagram below illustrates the flow. Please note that it shows only the
functional blocks. Some software system(such as Fidessa) combines both Sales Application and Dealer Trader Workstation into one GUI application.

(Click to view larger image)

The above flow is usually called High-Touch flow it requires broker firm to
provide human intervention to the client orders.

Electronic Trading(Low Touch)

Lately the concept of Electronic Trading has been popular and many broker firms have built the systems based on this concept to meet the changing client requirements:

Clients want more direct control on the orders in the exchange
Clients want low latency trading on the competitive market
Clients want the service of Algorithmic trading.

The diagram below shows a typical Electronic Trading System

(Click to view larger image)

Some details about the flow:

Client sends order through FIX protocol

The Client software can be from any vendor or house built, as long as it talks FIX protocol. Broker firm should discuss the support FIX versions with Client and usually some conformance tests should be done before going live.

The broker FIX gateway receives the order and forwards it to FIX Router

FIX Router

FIX Router needs to make a decision on where the order should be forward to. Subject to the system configuration and broker office setup, the FIX Gateway could be regional and OMS partitioning could be office or country specific. FIX Router needs to look at the instrument and client instruction to route order to specific OMS for next handling.

Electronic Desk Handling.

An electronic order can go out to market without any human intervention from broker firm.

However, just like anything in life, it can go complicate:). Orders may run into some error state or failed Criteria Checks(Criteria Check is discussed in next section) due to various reasons, such as Client sends incorrect fields including unreasonable price/quantity, or even a bug in broker’s system itself.

This is when traders in Electronic Desk need to manually sort out the error by contacting Client if the error is in the order itself or broker firm’s support staff if the problem is in the broker firm system.

Electronic Trading OMS

In addition to the traditional OMS functionalities which requires

Showing the client order details
Showing executions
Operating on orders

An Electronic Trading OMS also needs to be able to perform

Criteria Check
Exception reporting and handling
Order Routing

Criteria Check

Criteria Check is to prevent trading risk and meet the compliance requirement from stock exchange regulatory.

Exception Reporting and Handling

When an order has failed the criteria check or caused some internal system error, Electronic Desk needs to be informed immediately such that they can decide to inform client or remedy the problem in a timely fashion.

The last thing a broker firm wants to happen is to let the client find out the problem before the broker firm do, which surely will upset the client and lose the firm's credibility. This is why Exception reporting and handling are important that can made or break the whole electronic trading system.

Presentation of the Exception:

GUI alert to Electronic Desk
Monitoring software notification to system support staff

Severity of Exception

Info
Warning
Error

DMA vs. DSA

A DMA order goes straight into the market without any changes to the client order. DSA order will be routed to Algo Server for strategy execution. Subject to the algo strategies offered by the broker firm, a DSA order can result in many “slices” of child orders to the market.

Asia Stock Exchanges

2009-07-07T01:55:00.001-07:00

hmm...Google blogger doesnt seem to be able to handle a slightly more complicate html file. The article is posted at this link below:

Asia Stock Exchanges

Electronic Trading

2009-07-06T19:49:00.001-07:00

This article is to discuss the operation model between Fund Managers(Client) and Broker Firms. They are usually referred as Buy Side and Sell Side.

High-Touch Model

Traditionally, the Buy Side and Sell Side have been operating in the way of

Clients(fund managers) send order to sales trader. This can be by means of phone calling, email, FIX message or data exchanged through third party software.
Sales Trader enters the orders into firms Order Management System(if its not electronically sent in) and assign them to different execution traders.
Execution Trader(or Dealer) picks up the orders(and communicates to Sales Trader if necessary) and enter the order into Trader Workstation.
The orders sent by Trader Workstation and get traded in exchange.

(Click to view larger image)

The above flow is usually called High-Touch flow it requires broker firm to
provide human intervention to the client orders.

Electronic Trading(Low Touch)

Lately the concept of Electronic Trading has been popular and many broker firms have built the systems based on this concept to meet the changing client requirements:

Clients want more direct control on the orders in the exchange
Clients want low latency trading on the competitive market
Clients want the service of Algorithmic trading.

The diagram below shows a typical Electronic Trading System

(Click to view larger image)

Some details about the flow:

Client sends order through FIX protocol

The broker FIX gateway receives the order and forwards it to FIX Router

FIX Router

Electronic Desk Handling.

An electronic order can go out to market without any human intervention from broker firm.

Electronic Trading OMS

In addition to the traditional OMS functionalities which requires

Showing the client order details
Showing executions
Operating on orders

An Electronic Trading OMS also needs to be able to perform

Criteria Check
Exception reporting and handling
Order Routing

Criteria Check

Criteria Check is to prevent trading risk and meet the compliance requirement from stock exchange regulatory.

Exception Reporting and Handling

Presentation of the Exception:

GUI alert to Electronic Desk
Monitoring software notification to system support staff

Severity of Exception

Info
Warning
Error

DMA vs. DSA

Stock Exchange Simulator

2009-06-03T20:32:00.000-07:00

Exchange Simulator

Google project link: http://code.google.com/p/webcurvesim/

If you work for financial industry especially in Equity/Derivative trading area, often you may want a stock exchange simulator for your application testing. There are a few reasons for this:

The test exchange gateways provided by exchange may not be always available. e.g. some are not available after working hours or in the weekend.
The test exchange gateways provided by exchange are shared by other brokers and your testing may be interfered by other people.
An exchange simulator provides you the freedom of total controling when and how to use it since you own the simulator.
You could perform load testing on your application against the simulator where its usually prohibited on the test exchange since it might overload the system and affect testers from other brokers.
It's extreme useful for algorithmic trading testing due to

"you own the market" such that you could generate any scenario for your testing
you can replay the market data for your back testing and even play different strategies or same strategy with different parameters against the replay market to fine tune performance.

Features

WebCurve simulator provides the following features for you with an open sourcelicense(its basically free, please read the license for details):

A set of core functions to simulate the exchange behavior.
A FIX gateway supported by QuickFIX/J for your FIX application testing
Market making simulation to provide a simulated market
Market replay function to support replay live market data

Known limitation

No stock, price, price step, lot size validation. This would require a huge database implementation.
Only support FIX 4.2. I am happy to implement other versions in a later stage if there are enough interest out there.
Webecurvesim.jar provides a generic interface to java 6/5/1/1.4.2. The sample programs main()s are written and compiled with java 5 so you need to get java 5/6 runtime to play. If your application is at 1.4.x, you are stillable to the webcurvesim.jar lib but just need to write your interface program in 1.4.x way.

There are 4 sample programs come with this bundle which demonstrate how WebCurve simulator works. Feel free to contact me at dennis_d_chen@yahoo.com if you have any questions or want to see any features to add.

Samples Programs

Please unzip webcurvesim.zip to a directory. You can find 4 windows batchfiles test1.bat, test2.bat, exchange.bat and trade.bat. Unix users should find it simple to convert them into shell scripts.

Test1

This demonstrates how to use the core Exchange class and OrderBook class in a basic way.

Test2

This demonstrates how to get order and trade updates in a call back way.

Exchange

This demonstrates the exchange simulator in a GUI application with the following features

Order transaction in interactive way
Market activity simulation
Market replay
Serves as a FIX gateway server(see next)

Trade

This demonstrates how a simple OMS system interacts with exchange simulator through FIX 4.2 protocol. This sample program requires the above Exchange sample program running as server.

Usage

Create client orders(parent order) with "Enter Order" button.
Select one or many client orders then send child orders with "Split Order" button.
Amend client order or child order with "Amend Order" button. Only allow amend down quantity and amend price.
Cancel client order or child order with "Cancel Order" button.

Known issues

No quantity check between parent orders and child orders. It is possible to overfill order.
Some time you may hit some GUI refresh problems when expanding the order tree.

Dependent Packages

QuickFIX/J
Appache MINA required by QuickFIX
SF4J

Contact Me

Author: mailto:dennis_d_chen@yhoo.com
Feel free to contact me if you have any comments/questions/suggestions.

Release History

r1.0.0 first release on 3 June 2009

Electronic Trading

2009-05-18T22:14:00.000-07:00

This article is to discuss the operation model between Fund Managers(Client) and Broker Firms. They are usually referred as Buy Side and Sell Side.

High-Touch Model

Traditionally, the Buy Side and Sell Side have been operating in the way of

Clients(fund managers) send order to sales trader. This can be by means of phone calling, email, FIX message or data exchanged through third party software.
Sales Trader enters the orders into firms Order Management System(if its not electronically sent in) and assign them to different execution traders.
Execution Trader(or Dealer) picks up the orders(and communicates to Sales Trader if necessary) and enter the order into Trader Workstation.
The orders sent by Trader Workstation and get traded in exchange.

(Click to view larger image)

The above flow is usually called High-Touch flow it requires broker firm to
provide human intervention to the client orders.

Electronic Trading(Low Touch)

Lately the concept of Electronic Trading has been popular and many broker firms have built the systems based on this concept to meet the changing client requirements:

Clients want more direct control on the orders in the exchange
Clients want low latency trading on the competitive market
Clients want the service of Algorithmic trading.

The diagram below shows a typical Electronic Trading System

(Click to view larger image)

Some details about the flow:

Client sends order through FIX protocol

The broker FIX gateway receives the order and forwards it to FIX Router

FIX Router

Electronic Desk Handling.

An electronic order can go out to market without any human intervention from broker firm.

Electronic Trading OMS

In addition to the traditional OMS functionalities which requires

Showing the client order details
Showing executions
Operating on orders

An Electronic Trading OMS also needs to be able to perform

Criteria Check
Exception reporting and handling
Order Routing

Criteria Check

Criteria Check is to prevent trading risk and meet the compliance requirement from stock exchange regulatory.