I will use this journal to capture automation results of the current system I have (primarily) been running semi-automated. Setups have been auto-generated for over a year. Interpretation of what is a buy setup or a sell setup has been coded/minimized to basically Enter here and Exit here (some have been marked as weak or strong but I find that this can be an opportunity for my bias to dismiss the setup). The past few months have been devoted to fully developing the ATS front-end, and meanwhile manually entering the setups. Using dosages of discretion, it has been possible to eek out a higher W:L week over week (and of course lower when the monkey believes he is smarter than the system). My goal is full automation, soup to nuts. Turn on workstation, hit the load systems button. Why do I want to automate? I trade because I want to, not because I need or have to. I want time for other personal projects, to also expand my trading into currencies, bonds or the N225 (building systems). Current: VB (not .net but planned) and some C++ (all version 6). Will be running this system unattended each week. For now I imagine the challenges will be: 1. Tweaking profit targets as this system is always-in/reversal (ATS has option for predefined profit amt to exit on, not ready to leave an always-in system unattended...). The targets will be kept to small slices. 2. Notifications. No remote access built in, but can set various notification rules such as email alerts, chart snapshots, anomalies. Also built in a remote IM bot that has been giving me trouble. 3. Pulling the plug on trend days. 4. Contract size. Starting small 5 contracts YM. With semi-automated, preferred ES instead. 5. Trading multiple instruments concurrently, only one instrument possible now. This is a forward test, I hope to have some "aha" moments (and no Doh moments). I plan to post some pictures of older build versions (GUI is lean, no garnish). I will posts points gained/lost occasionally. I cannot share any specs about the system, only automation-related issues. Willing to hear from anyone who has gone down the automation road and lessons learned. Challenges? Learning points?
I'll pay attention. I once had a dream of automation but for various reasons gave it up. I find my trading is too discretionary to code effectively although it is still rule based. When A happens, and B happens then enter when C happens unless..... Thanks Satchel
Completely automated yesterday, FOMC day, and today. I was not near the system either day. FOMC day captured 60 YM pts. (Not including started the day with ES short which system closed before 1st long setup for 4.5pts). I can only say that the profit target checkbox was on and set to auto-close within a 20 YM pt window, as I was a bit nervous about false FOMC setups. I must have called my broker about 12 times to check status, and even closed two trades early. System unimpeded pts would have been higher. Today 73pts. (Four trades today) Interesting, if I had been anywhere near the system yesterday I would have cancelled several trades that ended profitable Added to the to-do list, capture MAE (how much did price move unfavorably against the system entry), this was very high yesterday and inline today. Past two days the bot that I use to control remotely has gone down, so have been relegated to the default snapshots and other alerts that get sent via email. Thinking of dumping the chat bot, it's flimsy, was coded hastily and a host of issues with proper versions running on each side. I could install Windows Terminal Services software, Citrix but concerned with the bandwidth, especially bandwidth coming in, I want to be able to track and control truly remotely - whether that be from god forbid a dialup somewhere etc). I'm dreaming, but it would be decent to be able to SMS your system various codes (to reset various options). Just thought of something interesting, the front-end is not built to allow any intervention of which trades to enter, meaning "arbitrarily enter a position here". I can never 'create' a trade with the front-end. So it is impossible to intefere remotely other than to close a trade early, or only short, only long setups etc.) Back on topic, what are viable options for remote control (not talking pcanywhere or go to my pc class-level here)...if citrix 'listens' on ports for clients, couldn't I code directly to listen for specific commands...
What's up Satchel, tell your bot I am coming to take its money. #include <iostream> // for cout cin endl using namespace std; int main() { double x = 0.0; cout << "GIVE VOLENTE_00 THE $$$: "; cin >> x; cout << "x " << (x * x) << endl; return $ TO VOLENTE_00;
Cool satch. This is superior to results attained in your discretionary experience? Were you essentialy trading the same system when descretionary?
Hey Satchmo. If I had to do this, I'd probably do up a little webpage on the machine running the system so you could access it from any machine anywhere on the web (if simple enough, you could even use your mobile phone to trigger trades). It would just be a basic page with position info and a couple buttons to buy/sell X contracts, go flat, etc. There are lots of different ways the button pushes could get to your trading app, from just generating text files that the app reads, to being tied in more tightly as possibly even the same program. Or you could give up this silly automation dream and come back to ET chat. You skewed the wanker quotient when you left, so its getting high in there.
It's been a while since I started on the full autmation journey. It's amusing to see what my original thoughts were. Over a year and a half since I started this thread and planned to update. Let's see where have I been, spend half a year playing and learning with different broker API's, building risk modules, falling into trap of endlessly tuning trading algorithms within the automation engine as did forward test (don't do this! just let the strategy do what you originally planned). Here is an example of one of my very early systems, going back to when I began this journal. Slow-moving and flat-footed, it trades once or twice a day. Just a quick and dirty done in V C++ with hooks to broker API. I have other systems with layers of complexity and screens due to multi-strategy, and all the bells. This one, however, simply executed the strategy based on 'listening' for text files (orders). Probably similar to things like T-bolt and Ninja (I think there are a few others), those are great for turnkey - but doing the automation yourself you have obviously greater control and can slice and dice order types based on risk. For my strategy, early on, I was very concerned about orders being submitted during an early morning window of econ releases. I can plan and queue up days of the coming week or just certain hours not to trade, ignore incoming signals - but also to simulate it (do everything but submit the order so I can still capture data and analyze trades during forward testing). Looking at it now, it does the job but suffers from those early days of not well though out methodology. I was not able to re-use a lot of the code in the future systems. That was a drawback. To go from simple idea to a working system, I spent way too much time bouncing from design a hurried development of code, into testing it, back to design (tweaking strategy - a waste of time) rather than an iterative process. Code is about 800 lines, with code bloat. Now, I try to create simple modules and build on slowly, focusing on re-use. All my strategies are not even near the realm of high-frequency trading, so I do not have to worry about speed, latency, capturing level II, etc. Slow order files work for me. Things I want to do in the future: write a standalone backtest system - data storage and speed, so I can play with position sizing based on how the equity curve is doing and do all those 'runs' with a few clicks. There are no good backtesting systems, that are affordable, standalone (not talking about what is included with proprietary charting packages or Quant stuff). Even on the below ATS, I coded a ton of random position-sizing and random exits (points to capture) when an order was received - when the place for that is back testing. So here is ole flat-foot from 2006, hardly a big deal but still going strong. Currently short ES