Building an ATS - Logbook

[themickey]

Quote from tiagor:

... I must say I'm actualy amazed you implemented all those rules only with excel. Depending on excel to do all that would definitely freak me out (and I must say like excel a lot).
By the way.. do you have and estimation of the Sharpe ratio for your system?

The Algo is built on SierraCharts Excel.
The saying "How do you eat an elephant? Answer: "One bite at a time" applies here. It is something no one could do off the top of their head in a week. If I lost the formula I would have difficulty rebuilding it quickly.

I don't use Sharpe ratio, Amibroker use it standard in their backtesting model, but I'm not too much a fan of ratios due to the fact market conditions change and what once was doesn't always transpire to the future. Another issue is I have only 9 months of intraday data to test on. I do have many years of EOD data on Amibroker however I can only eyeball this as it relates to my signals.
I don't wish to advertise much about my system other than to say it is not HFT. Trading 1 x SPI contract (that's all I'm doing until bedded down) returns approx $100/ trading day over past 9 months (backtested). 1 x SPI contract at the moment is $114,000.
Profit loss ratio and win rate is very high and I'm sure would return lots of negative comments about unsustainability etc were I to mention it, so I'll leave this bit out.
I've actually erred on the side of caution in design. Many trades the algo won't take, I would rather not hit so many trades but get a higher win rate.

 

[tiagor]

Progress report: The simulator engine is fundamentally done. It has been taking somewhat more than expected to finish because of a lot of details that need to be taken into account. For testing purposes I'm using a dummy Ghost which goes long/short on some given SMA/EMA crossovers.

By now this is what I've got working:

- Able to deal with any historical quote timeframe
- Auto-detects pip unit for currency pair
- Configurable start equity, default order size, maximum drawdown allowed per trade, estimated slippage
- Calculates and accounts for all broker commissions for opening/closing orders
- Its aware/reacts accordingly to minimum margin requirements for all open orders, minimum equity for opening new positions, maximum loss per trade and margin calls
- Outputs detail for all trades and final report of end equity, max drawdown, total commissions
- Only one trade allowed at a time. I considered allowing for adding to existing positions but couldn't find a good enough reason to do that as it increases exposure and non-linearities on the algo performance.
- A short decision while carrying a long position will close the previous long and vice-versa. This means if we're long on the market, we can only enter the reverse direction after two signals to short.

What's missing:

- Sharpe ratio calculation (near completion)
- Configurable max drawdown per day
- Report total wins vs. losses
- Graphical output? (not a priority)
- (...)

Current code size:
SHELL: ~600 lines
Dummy GHOST: 10 lines
MBT Broker API constants/enums: ~400 lines (will not grow unless there are API changes)

 

[CT10Gov]

You not trading fx futures right? Are you accounting for overnight carry charge for your net pnl?

Quote from tiagor:

Progress report: The simulator engine is fundamentally done. It has been taking somewhat more than expected to finish because of a lot of details that need to be taken into account. For testing purposes I'm using a dummy Ghost which goes long/short on some given SMA/EMA crossovers.

By now this is what I've got working:

- Able to deal with any historical quote timeframe
- Auto-detects pip unit for currency pair
- Configurable start equity, default order size, maximum drawdown allowed per trade, estimated slippage
- Calculates and accounts for all broker commissions for opening/closing orders
- Its aware/reacts accordingly to minimum margin requirements for all open orders, minimum equity for opening new positions, maximum loss per trade and margin calls
- Outputs detail for all trades and final report of end equity, max drawdown, total commissions
- Only one trade allowed at a time. I considered allowing for adding to existing positions but couldn't find a good enough reason to do that as it increases exposure and non-linearities on the algo performance.
- A short decision while carrying a long position will close the previous long and vice-versa. This means if we're long on the market, we can only enter the reverse direction after two signals to short.

What's missing:

- Sharpe ratio calculation (near completion)
- Configurable max drawdown per day
- Report total wins vs. losses
- Graphical output? (not a priority)
- (...)

Current code size:
SHELL: ~600 lines
Dummy GHOST: 10 lines
MBT Broker API constants/enums: ~400 lines (will not grow unless there are API changes)

 

[vincegata]

@tiagor - do you use multithreading? Such as downloading quotes (Shell) in one thread and processing quotes (Ghost) in another thread.

 

[tiagor]

Quote from CT10Gov:

You not trading fx futures right? Are you accounting for overnight carry charge for your net pnl?

Only trading spot FX. Thanks for the input. I was not accounting for rollover interest rates. :eek:

 

[tiagor]

Quote from vincegata:

@tiagor - do you use multithreading? Such as downloading quotes (Shell) in one thread and processing quotes (Ghost) in another thread.

No, not yet. Both quote event handlers and the ghosts run on different classes so the change to go multithreaded should be minimal. By now my main priority is having a minimum working setup.
When everything is working I have to go threaded to be able to trade multiple instruments - 1 thread per ghost/per instrument.

 

[2rosy]

Quote from tiagor:

No, not yet. Both quote event handlers and the ghosts run on different classes so the change to go multithreaded should be minimal. By now my main priority is having a minimum working setup.
When everything is working I have to go threaded to be able to trade multiple instruments - 1 thread per ghost/per instrument.

since you're using python look into zeromq instead of python's builtin threads which aren't what you might think they are. Also, the reactor pattern is commonly used in these systems so as to avoid messy threading. python has a library called twisted its like c++'s ace

 

[tiagor]

Quote from 2rosy:

since you're using python look into zeromq instead of python's builtin threads which aren't what you might think they are. Also, the reactor pattern is commonly used in these systems so as to avoid messy threading. python has a library called twisted its like c++'s ace

Thanks. Checking it out now and will try it as my previous experiences with threading (mostly with C) have not been happy because of locking and synchronization issues.

 

[hft_boy]

Quote from vincegata:

@tiagor - do you use multithreading? Such as downloading quotes (Shell) in one thread and processing quotes (Ghost) in another thread.

Why thread? It's expensive, and more importantly, bug prone (it's tricky to get the locking and syncing right). Locking and unlocking can take between 30-100 ns, in C. Assuming your code doesn't actually do much (and there's not much you can do in 600 lines), you're not actually saving that much, and you can save a lot more just by writing more efficient code and data structures. Most threaded code I've seen is written that way because the developers are lazy and start a new thread for every random task they have; they can't be bothered to write it correctly.

 

[tiagor]

Quote from hft_boy:

Why thread? It's expensive, and more importantly, bug prone (it's tricky to get the locking and syncing right). Locking and unlocking can take between 30-100 ns, in C. Assuming your code doesn't actually do much (and there's not much you can do in 600 lines), you're not actually saving that much, and you can save a lot more just by writing more efficient code and data structures. Most threaded code I've seen is written that way because the developers are lazy and start a new thread for every random task they have; they can't be bothered to write it correctly.

Threading IS expensive. But I'm not even attempting to compete in the HFT league so I'm not overly concerned with timing issues at the moment. I will need threading though for parallelizing trading on multiple instruments.