 |
| Trading System V1 - ERM Diagram |
The security_option table is a placeholder for a parent table called security. The SecurityOption will be a subclass of the Security abstract class in code.
Sunday, February 2, 2014
Trading System V1 Thoughts
Using the data model from the revised backtesting system as a starting point, I've started planning the data model and Java component interaction / logical architecture. The first draft of the ERM diagram is below:
The security_option table is a placeholder for a parent table called security. The SecurityOption will be a subclass of the Security abstract class in code.
The security_option table is a placeholder for a parent table called security. The SecurityOption will be a subclass of the Security abstract class in code.
Saturday, February 1, 2014
Backtesting System V2 Thoughts
During the last few months, I've been studying how to retrofit my backtesting system to to work as plug-in strategy engines for a live trading system. Commercial algorithmic systems have had a big impact on the design and architecture of the new system.
A table structure for storing the back test results was one of the first focus areas. At this time, all of the back test results are automatically dumped to CSV files at the end of each run. Three files are generated:
A table structure for storing the back test results was one of the first focus areas. At this time, all of the back test results are automatically dumped to CSV files at the end of each run. Three files are generated:
- Trade summary - performance metrics for each trade at trade closure.
- For example, if one multi-legged trade is entered per monthly expiration over a two year period, then there will be 24 summary lines in this file.
- Trade summary by day - metrics for each trade by day.
- For example, if the days in trade (DIT) is 30 then each rade will have 30 lines in this file. For two years of monthly expiration trades, there will be 24 x 30 lines in this file.
- Trade blotter - list of all of the transactions for each trade (all legs - entry, adjustment, exit).
Saturday, January 25, 2014
Backtesting System V1
Most of my focus during the last year, was spent on the backtesting engine for multi-legged options strategies. Backtesting of six legged options strategies with start dates at approximately 60 DTE will run in less than two minutes for nine years worth of trades. This application:
- Is written in Java (1.7), using the following libraries:
- commons-collections-3.2.1.jar
- commons-configuration-1.9.jar
- commons-dbutils-1.5.jar
- commons-io-2.4.jar
- commons-lang-2.6.jar
- commons-logging-1.1.1.jar
- guava-14.0-rc1.jar
- joda-time-2.1.jar
- log4j-1.2.17.jar
- mysql-connector-java-5.1.22-bin.jar
- Runs in Eclipse Juno (4.2) and Keppler (4.3)
- Uses property files for strategy and database settings
- Uses data stored in MySQL (5.5.29):
- Because of the amount of historical options data, there is a table for each symbol:
- ivolatility_rut (end-of-day options data from iVolatility.com)
- ivolatility_spx (end-of-day options data from iVolatility.com)
- ...
- livevol_rut (15-minute options data from LiveVol.com)
- livevol_spx (15-minute options data from LiveVol.com)
- ...
- hod_iwm (end-of-day options data from HistoricalOptionData.com)
- hod_spy (end-of-day options data from HistoricalOptionData.com)
- ...
- Contains two utility tables:
- market_holidays
- List of market holidays: Jan-1-2000 to Dec-31-2014
- optionsexpirations
- List of monthly expirations: Jan-1-2000 to Dec-31-2014
- The historical data from iVolatility is the most current, with options data spanning from Jan-4-2006 to Dec-20-2013.
Subscribe to:
Posts (Atom)