Finally: Working on our new trading agent.

Trade-Robots.com is using our own developed trading infrastructure. This is one of our core advantages – together with our string background in software development and a very professional approach to strategy development. Our framework has one weak point at the moment – trading. Now this gets fixed.

Trading – the last step of strategy development

When one is starting strategy development, real trading is the last concern. There are a ton of steps that have to be done before trading can take place. When one is prototyping and developing a trading infrastructure, it is easy to push the real trading part down the road and then, when trading starts, to just do the absolute minimum possible. We did that – and now it is time to clean up.

Agility has a price – our trading prototype never got love

We started with prototype level code, and what worked. When one starts a framework, trading real money is not a top priority - it is the end of a long chain and a long process. As a result, this part of the framework was never getting more than the minimum development time needed for some basic trading capabilities. We never created a real and full features trading server component. The original prototype approach made by our partner was not suited to run a lot of strategies. In fact, it only ran one strategy. Which was compiled into the program. The trading server – which is essentially a command line program – can only run one strategy now and needs a manual restart when issues happen. Running 80 strategies? That is 80 running programs. With 80 separate data connections. With no central position reporting. With no central risk management. With no web based user interface. Not nice, and definitely not comparable to the rest of the framework - the part that got all of our attention in the last years. It worked for a while, with very few setups – now the time has come to say “thanks, but no thanks” to this approach and bring it up to the capabilities of the rest of the framework. Because now - we need it. Our "ready to move forward" wall of setups has just breached 100 ready to trade strategy instances.

The new Trading Agent finally is getting some love

Months behind the time schedule we now finally give the new trading agent some love (and development time). We call it an agent because of the standard terminology we use in the Reflexo Trading Framework – the Grid Agent is executing tasks on our performance grid, doing backtests, data exports and other distributed and computing intensive tasks. The Trade Agent will do the actual trading and replace our nameless command line based prototype.

The new software is totally different from the old approach. We go for a windows service that can connect to a number of providers – for data and / or trading. The goal is a web based user interface, though we currently hit for a windows desktop based application for the initial states – once the whole data flow is done, this will move. Prototyping phases sometimes use different technology for some parts.

The server is managing different named “environments” (and we determine data and trading provider on environment level) and can do simulation (so we can have a staging environment where we can test strategies before giving them real money). Strategies are loaded from “containers” (which are folders containing the strategy code) into separate application domains (we use .NET and that is a .NET technical term), which means we can unload a strategy without restarting the whole server.

SQL Server and a Web Interface will make a practical difference

The Trading Agent has to run independent from our main infrastructure. Our trading computers are connected to our main office via a virtual network (over the internet), but we cannot rely on that to be available all of the time. Simple matter of fact – better design a system for failures. As we do not do multi exchange arbitrage, we also do not need this connection, though. So we design the trade agent to be independent. A local SQL Server (the free version is way more than enough here) will serve as local data store for executions and configuration. We will use a web based API to control the server from a locally installed web application – and a central service will be able to pull execution data from the serve. Possibly down the road is a webhooks or SignalR implementation to push executions to our backoffice. For now, we are happy with a webpage updating regularly that shows us what the strategies are doing.

The new trading server brings new capabilities

But this is not only about optimizing the nightmare we have from the operations side. 80 running programs and 80 data connections – our brokers would hate us if we would trade it all. No, the new server will also increase our risk management possibilities and allow us to integrate additional functionality. Publish trades and executions to Twitter? Easy. As it will allow us to integrate Collective2. Or work with more professional investors and partners where we either give up trades or deploy a trading agent in their computer park (although control of the intellectual property is an issue here, but we can work around this, modern computers have a lot of interesting features to the one reading the documentation).

We are especially interested in the integration of external interfaces (twitter and collective2) as well as the execution database, because then we can finally easily publish monthly or weekly trading results for our trading- something that right now is quite a feat that involves parsing a lot of text files or the broker account statements. Once we have the trades in the database – things really turn easy. Analyzing live trades will then be as easy as analyzing a backtest.

And then there is the possibility to put in central and complex risk management once into one server for one account – because we have only one server running then, not one per strategy. A very important point and one that has been a very bad weak point in our current setup because we cannot manage something like a central risk profile for a pool of strategies at the moment.

Our time plan: end of 2014 for a public trading start in January 2015

Due to consulting (pretty much until the end of the year) our core system development bandwidth is very limited – so working on this trading agent will take some time. Until then we have to live with the current limited solution. I expect to have a working structural prototype some point this month, then take it from here to a full agent until mid of December, so that we can actually start utilizing this new features starting January, once our winter holidays end. This agent is the core reason we are delaying publishing any trading results on this website for the moment – we want full integration first.

So, with a little luck we should have the capability to do some paper trading with the new server end of the month. Not with an internal simulator, but with the external simulator provided by one of our trading infrastructure providers – a good test to measure capabilities and performance. And then we will take it from there. Updates on this blog will be coming. And in the meantime there are a lot more blog articles – and the first real website content – that is awaiting publication.