Friday 31 July 2009

Algorithmic Trading

- To see an algo trading system in action, you may take a look at Cyan Spring Open Source ATS

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. To see an algorithmic trading system in action, you may go http://www.cyanspring.com to take a look at Cyan Spring ATS.

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":

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

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

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

  4. 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.

6. Summary

I wish this brief article gives you some overall idea of what algorithmic trading is. To see one in action, you maydownload Cyan Spring Open Source ATS from http://www.cyanspring.com

Tuesday 7 July 2009

Electronic Trading

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

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

Monday 6 July 2009

Electronic Trading

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.