Today’s markets are dominated by professional traders employing high-speed algorithmic trading systems. Individual traders need to equip themselves with equally strong analytical muscle and risk management procedures. Traders can design algorithms with these elements at their core.
Computer automation and human intelligence are complementary. Traders need computers to execute trading strategies at ultra-fast speeds in a disciplined manner. Computers need humans to mitigate model risk. Performance is delivered through human traders controlling computer programs. We will discuss how to find trading strategies best adapted to the current environment and executing those strategies through timing triggers.
Darwinian strategy
Key to the success of computer-based trading is selecting the right strategy. Many algorithm-based systems implement their own proprietary trading strategy in a static manner. Unfortunately, there is no mathematical proof that any one strategy is profiting all the time. Model risk can be great when an incorrect trading strategy is automated in large scale.
To create the best strategy, modelers and programmers work to implement as many diverse strategies as possible. The best strategy is selected similar to the evolution process, where the system best suited to the current environment thrives. One approach puts all strategies in a dry run, or theoretical, state to select the best adapted system. This also can determine the optimum holding period.
Say you are trading a large block of stock or futures positions. First, the block is broken into a number of small units. The size of unit is determined by volatility of the market and trading cost. Each trade is conducted at a triggering event. Each strategy is conducted in a separate computer process.
In a real-time trading system, each trading process interacts with the brokerage to finish the transaction. In a dry run state, the national best bid and offer (NBBO) prices are logged and the trade is conducted in a simulated fashion. Alternatively, data can be purchased so that dry run is performed off trading hours without human intervention.
Both quantitative criteria and qualitative assessment can be applied to determine the best trading strategy. For example, a daily score based on profit and loss can be kept for each system. By combining daily scores, we can determine both the best holding period and best performer for the period.
You can devise as many trading strategies as you need, which can be based on fundamental as well as technical inputs. Some strategies work for a certain period of time and then break down. This is reflected in academic studies of past decades, many of which are devoted to the efficacy of these strategies. No conclusions have been reached about correctness of any one strategy all the time.
However, what you can do is dynamically and efficiently discover the strategy best adapted to the current market sentiment. Through constant dry runs and frequent comparisons, the winning strategy can be identified and employed in a timely manner (see "Testing and review," below).
In practice, there are two types of performance results you should be concerned with when consuming the data log. One is action related. The other is performance result without action. The former corresponds to buy or sell action. The latter is just for scoring. Triggers determine buying and selling.
There are two types of triggers: one is event-based, for example, an earning report can be a triggering event; the other is a technical trigger, such as a bear cross, which happens when the 50-day moving average crosses below the 200-day moving average. This is a technical sell signal. Both types of triggers can be used to execute strategies.
For the event-based trigger to work, the system may choose to subscribe to a news service that may supply 200-400 pieces of news a day. Users may choose to focus on a subset of news through a list of events of interest. A calendar module is needed to help prepare the list in advance.
Based on the list, a parsing module can be used to decipher news events. However, parsing news is only part of the job. Catching proper market reaction is much more difficult. For example, a beat on both top line and bottom line should result in a buy trigger. However, market reaction to the news is different in different times.
When JP Morgan reported better-than-expected earnings and revenue on April 14, 2010, the stock advanced 3.1% to $47.27. However, when the company reported better-than-expected earnings and revenue on July 15, 2010, it led to a 2.2% drop in the stock. Parsing news does not guarantee catching market reaction properly. JP Morgan is a bellwether stock, and a 2%-3% move in the stock affects major U.S. stock indexes. If a trading system cannot reliably catch market reactions to these events, it cannot be trusted.
This is where the human element thrives. Upon observation that JP Morgan advanced 11% the week before the July report, a trader may conclude that optimism has already been priced into the stock. In this case, JP Morgan would need much better-than-expected earnings for even further advancement. Behavioral finance is at work here. Behavioral finance combines cognitive, emotional factors with market statistics in making decisions. Behavioral finance at times plays an important role in forming direction. To account for this, human input is needed to determine buy or sell triggers.
A weight applied to a trigger is one way to accomplish this. When the weight is above system default triggering level, the trigger is executed. If the weight falls below the default triggering level, the trigger is in a "wait" state. A human operator can intervene at any time to alter the weight of the trigger. The weight is effective even after the trigger is executed. By strengthening or weakening the weight, a human operator can affect trading in action.
Assuming the system default triggering level is 0.6, the human operator can set the default weight for all triggers. Sensing market-wide optimism, the operator can set the default weight at 0.7. As a result, all triggering events as generated by the program will be executed as long as news parsing is satisfactory. Alternatively, if the operator believes the market is pessimistic, the default weight can be set to 0.5. Under this circumstance, trading is executed only when the operator adds weight to a selected set of triggers.
Note that weight still exists even after the trade is triggered. What is implied here is that the trade is always broken into a number of sub trades. The rule for breaking the trade is determined by the trading cost. Each sub trade is executed only when the weight is above the system default triggering level.
Take the JP Morgan trade. With lingering concerns about the European sovereign debt crisis and Federal Reserve concerns about the U.S. economy, the operator may choose to set the system default weight at 0.5. No trigger is executed without supervisor approval. If the operator decides that good earnings have already been priced in, the weight might remain as is. A buy is not triggered. Alternatively, if the operator assigns a weight of 0.7 for the stock, buying would be started as the earning news is parsed. Sensing a drop in price, the operator may lower the weight. No further trades are executed. With flexible weight intervention, the JP Morgan trade can be prevented or limited at various levels.
By breaking a trade into smaller sets of sub trades and controlling the weight, human traders exert influence on triggers. Because trades are indirectly controlled through triggers, traders must monitor both market and triggers. As a result, this design calls for a wider monitoring of indexes, stocks of interest, news flow, trading results and triggers. When confident, traders delegate trading to computers. In times of precaution, trades can be controlled.
Of course, all of this can fail if it is not executed in an orderly fashion. This calls for an optimized design.
System design
From a business point of view, trading is the centerpiece of the system. At the same time, the system also needs to be scalable. Scalability means the system can add modules without affecting performance. The system must support different type of services (news service, calendar service, technical analysis service, any service you might want to add to the system), potentially large number of users with different privileges, transaction support, etc. As a result, it must leverage a state-of-the-art relational database such as Oracle or SQL server.
As a result, the system is centered around two parts: trading and the database. Somewhat like 19th century Russian literature where stories are developed around parallel themes (see "Building the system," below), the diagram does not contain a human user interface. A web interface is assumed. In recent years, system design has followed a three-tier architecture where web interface, database and business logic are the tiers. This system design follows that architecture.
The trading block includes the trade agent, the exchange/brokerage router, trading rules pool, trade queue and trade logger. The trade agent executes bid/sell orders based on specified volume. The exchange/brokerage router supports load balancing on exchange/brokerage interfaces. The trading rules pool includes rules such as stop loss, limit order, etc. The trade queue interacts with the database (symbol, volume, buy/sell instruction, weight), and the rules pool generates trades ready for execution. The trade logger records every trade transaction in full detail.
The online support block includes market surveillance, candidate formulation, trade division, trade monitoring, candidate state formulation, news service, real time technical analysis, fundamental analysis, calendar service, etc. Market surveillance includes tracking intraday movement of index, active stocks, stocks and commodities of interest, etc. Candidate formulation derives trading candidates from asset and offline output in the database. Trade division breaks up big trades into sub trades.
Trade monitoring determines whether post trade the market deviates from intention. For example, if the market price goes up after the stock is bought, the post market aligns with trading intention. On the other hand, if post-trade market drops, a signal is generated to negatively feedback to the trade weight. When the trade weight drops below a defined threshold, no further buy is carried out (or a stop loss is triggered).
The news service parses an intraday news feed. Real-time technical analysis provides signals such as breaks of support or resistance. The fundamental service especially is useful for a big price movement. Calendar service helps the trade to analyze price not only in terms of existing events, but also future expectation such as how important announcements like employment numbers carry weight based on the prior direction of the stock price.
Offline supports include strategy selection and trading audit. Trading audit stores necessary information for reconstructing trades. This module is useful in an error situation, such as the "flash crash," and to test a what-if scenario. Scenario study is useful for improving trading.
The administrator block is self evident. This system follows standard IT practice.
The database is the main depository of transaction records, module outputs, events, signals, etc. Almost all modules need to interact with the database to perform. In the process, intertwining between programs is reduced. Every time a new proprietary code is added to the system, most of its input and output are from a database and not from other parts of the system. This way, the introduction of new codes minimally affects existing codes.
Big picture
Telecommunication, air traffic and finance are different applications, each with its own central purpose. The soul of telecommunication is high reliability. The soul of air traffic is safety. The soul of trading automation ought to be performance generation and risk control. The flash crash on May 6 highlights the importance of risk control in the era of algorithmic trading. As trading activity is dominated by machine traders, the adequacy of risk control (or lack thereof) determines frequent profit and loss on a large scale.
It is in this light that we focused first on a trading strategy to leverage the current market trend, then on risk control and finally on the overall framework. The key is dual centerpiece arrangement. Traditional design revolves around trading activity. With dual centerpiece arrangement, the system becomes scalable. A scalable system performs well even as new functionality is added. For the automated trading to perform well, new functionality needs to be added constantly.
In contrast to some automated trading programs, human traders play an important role in this design. Human traders can modify trades at both the macro and micro level. This arrangement helps facilitate an automated system’s conformation to the management style and implementation of the portfolio management strategy.
At the same time, this design offers tools for the evolution of portfolio management. Through constant testing and evaluation of trading strategies, portfolio management can absorb winning elements in a timely fashion. The system is a lab where ideas are tested and validated.
Yong Liu holds master degrees in physics and computer science and has worked at Nortel networks and Nav Canada Inc. Liu consults on trading automation for financial institutions in China. Reach him at emailyongliu@yahoo.ca.
