Monthly Archives: January 2022

A trading algorithm has a defined set of instructions which needs to be executed in predetermined order. The profit generating capability might differ from one algorithm to another but widely all algos benefits from a faster execution. A python code can be developed to execute these set of instructions efficiently.

Let’s look on how to develop a python program to execute an algorithm. Generally, any trading algo will have three basic steps:

1. Fetch different variables like timing, price, quantity, volume.
2. Run a mathematical model like calculating candles, options greeks, etc.
3. Place appropriate trades if required (defined conditions are met)

We developed a module ‘Algo Module’ to execute all the above steps.

Algo Module

The Algo Module contains three functional classes, data_guy, events_and_actions and trader, one for each function.

Data_guy

Data_guy is a class whose objects will be responsible for fetching all required variables. It will periodically fetch, calculate and store variables which will be used by the algo.

Data_guy has following functionality:

set_parameters

A function to set various parameters of the class object.

update_data

This function fetches the latest data like last traded price, updated profit or loss, candle values etc. It also stores all the data which can be used for further calculation or logic.

get_atm_strike

This is a function to calculate strike of an option which is closest to the current traded price, this strike can be considered as at the money strike.

candle

This function calculates candles based on the candle length provided. It has flexibility to calculate candle of any length and for any historical time period.

calculate_greeks

This function is used to calculate options greeks. It can be used to calculate delta, gamma, rho, vega and theta of multiple options in single run.

Events_and_actions

Events_and_actions is the core strategy. The whole strategy is designed across multiple events and all events are mapped to an action. Events are designed to have multiple conditions, if all the conditions related to event are satisfied corresponding action is triggered. For e.g. if event_total_loss_reached is satisfied then action_close_the_day will be triggered.

If one event is satisfied during a iteration no other event will be checked, thus the events should be prioritized.

Events_and_actions have following functionality:

set_parameters

A function to set various parameters of the class object.

Events – event_1, event_2

These functions represents different events which needs to be monitored during the execution.

Actions – actions_1, actions_2

These functions perform different actions, like execute trade, square off existing trades. Action populate the orderbook with orders that needs to be carried out. It then call trader to execute those trades. Actions are mapped to different events and are executed only when its corresponding event is satisfied.

events_to_action

This function checks for all events one by one to see if its required conditions are met. If and event is satisfied the corresponding action is triggered.

Trader

Trader’s objects will be responsible to communicate with broker and carry out trades.

Trader have following functionality:

set_parameters

A function to set various parameters of the class object.

place_order_in_orderbook

This function iterates over all orders in the orderbook and places them to broker one by one.

strike_discovery

The function takes in price or delta as input and returns strike of option which is the closest match. It scans through multiple options and calculate their greeks and finally return the best matched strike.

get_positions

The function is used to get current position of the day.

Algo_manager

Algo_manager class is designed to initiate and set parameters all objects: data_guy, events_and_actions, trader. This class’ functionality is to manage above classes.

Algo_manager has just one functionality – to initiate and run the algo

action

Action function is meant to kick off every iteration for the algo. It triggers update data and then check for all events.

The Algo Trader is a WIP project, to access source code please check it out on github.

Algo trading is also known as  Algorithmic trading or automated trading, is a method of executing orders using a computer program that follows a defined set of instructions (an algorithm) to place a trade. The trade, in theory, can generate profits at a speed and frequency that is impossible for a human trader. The defined sets of instructions broadly includes three steps:

1. evaluates different variables like timing, price, quantity, volume
2. run a mathematical model
3. place appropriate trades if required (defined conditions are met)

A simple algo trader can have instructions like buy 50 shares of a stock if its price goes below 52 week average, or sell 50 share of holding stock if its price goes beyond 52 week high. A computer program can be designed to execute these steps and thus eliminate the need of human interaction. A typical infrastructure would consist three components.

1. A computer program which running on a laptop or deployed over cloud.
2. A broker terminal
3. Stock Exchange

The program connects to broker terminal which is further connected to stock exchange. The broker fetches market rates from the exchange and passes it on to the program. The program then runs computations on this data and send buy/sell trade signals to broker. These signals are relayed to the stock exchange by the broker.

As the code runs without human oversight there are multiple things which can go wrong during the market hours, for instance there can be large movement in the prices or there can be a connection error. To test the performance of algo under these extreme circumstances we perform stress testing. Stress testing is a computer simulation technique used to test the algorithm against drastic scenarios. Such testing is used to help gauge the risk and help evaluate safe guards and controls. It uses multiple scenarios which can be mix of historical, hypothetical, or simulated data. While testing, the algo is run over these scenarios to gauge its performance over some key performance metrices (KPIs). The scenarios thus should be designed to cover all internal and external factors which might have an impact on algorithm’s KPIs.

Designing Stress Test’s Scenarios

Let’s design stress testing scenarios for a sample trading algorithm. I covered an algorithm implementing Short Straddle Strategy here, it can serve as a good example. The short straddle algo buys and sells NIFTY options to generate profits.

Key Performance Index (KPIs)

KPIs for this algorithm will be how much profit or loss was incurred. We will be testing on unfavourable scenarios and so we would be more interested in knowing the losses and that too what would be the max loss incurred. Thus the first KPI can be Max Loss.

Loss distribution is also a key indicator of algo’s performance. While testing it on different scenarios we can measure what is the rupee loss incurred per unit of time, i.e. how much money was lost during 5 minutes of distress and if that is static, linear or exponential. Similarly we can also measure loss per unit of movement in NIFTY index.

The algo might have some safeguards built in which basically sense upcoming unfavourable event and suspends trading to avoid losses due to same. One of the key metric would be to check the reaction time of these safe guards, i.e. what level of losses are already incurred before these safe guards kicks in.

To summarize we defined three KPIs for the algo:

1. Max Loss
2. Loss per unit time and per unit of NIFTY movement
3. Reaction time of safeguards

Unfavourable Events

Unfavourable events can be internal or external to the system.

External Events:

External events are events which occur outside the system and have impact on algo’s KPIs. External events can include market movements and volatility, liquidity or price discrepancies.

Marker Movements can be categorized into three forms

1. Upward movement
2. Downward movement
3. Sideways movement (flat movement)

Market Volatility can be categorized into three forms as well:

1. Below Average
2. Average
3. Above Average

The market movements can be combined with each volatility to have 9 different scenarios, for instance one scenario can be Upward movement with below average volatility, Sideways movement with above average volatility and so on.

Options’ prices are heavily dependent on Implied Volatility, thus change in IV should be included as one of the external events.

Implied Volatility can be:

1. Below Average
2. Average
3. Above Average

Liquidity can have an impact on performance as it will limit algo’s ability to scale its current position or square off existing position.

Liquidity can be modelled as following:

1. Normal Liquidity
2. Dried Up Liquidity (Close to no liquidity)

There are times when market experiences absurd prices of an instrument, for instance an instrument which should have been priced are say ₹100 got sold for ₹2. In such cases if the algo hold such position a loss of 98% will be reflected and might lead to stop loss being triggered. The prices come back to normal very quickly but stop loss once triggered will stay active and might exit position at a loss. Thus occurrences of such freak prices should be included in external events.

Internal Events:

These events occur inside of the trading system but can have impact on KPIs. The system includes: computer program, broker terminal and the exchange. All three are connected via internet.

In such setup one of the internal event can be connection error between Algo and Broker or Broker and Exchange. The connection error can also be of two types, delayed signals or complete disconnection. Thus combining all we can have four types of events:

1. Delayed Signal between Algo and Broker
2. Delayed signals between Broker and Exchange
3. Connection Loss between Algo and Broker
4. Connection Loss Between Broker and Exchange

Another event can be high computation time for the algo, if algo takes a lot of time to run computation, any trade signals it generates will be delayed and might lead to unfavourable event. Factoring in such high computation time error into stress testing thus would be a good idea.

To summarize there can be five internal events:

1. Delayed Signal between Algo and Broker
2. Delayed signals between Broker and Exchange
3. Connection Loss between Algo and Broker
4. Connection Loss Between Broker and Exchange
5. High computation time by algo

Combining Internal and External events:

The internal and external events are independent in nature and so two or more of them occurring at same time is a possibility and would also be more adverse to the algo. For example there might be a case the market is having a downward movement and there is a connection loss between broker and exchange. Thus combining these independent events will lead to even more scenarios.

Conclusion

Algo trading can be implemented by reducing a trading plan into a set of instructions and converting it into a computer. The program can directly interact with broker for market data and trades thus eliminating need of human intervention. Lack of human control can lead to drastic losses in case of an unfavourable event and thus to test algo for such events we conduct stress testing.

Under stress testing we define KPI of the algo which might include Max Loss and Loss Distribution. The algo is run under a simulated environment where it is subject to different possible scenarios. These scenarios are can be external, internal or combination of both.