I think I misstated myself. The platform is extremely modular, and the layer is, in some sense, already there. However, actually implementing a system utilizing multiple instruments factoring in currency-variable relationships requires a level of mathematical analysis that would employee aspects of the platform that need more stringent testing. For instance, I want to be sure that the back-test analysis, order-logging, and position management systems are more strictly tested with less complex systems before going into more advanced projects. Error testing the platform in use-case scenarios with more complex logic makes the error testing process itself more complex then is ideal at the moment. In terms of scalability and robustness, there is very little I can't just "plug" into the platform.
Unless it is highly specialized (options, baskets, pairs-trading) and thus requires special features, it is a foolish endeavor to create this very complex piece of software. Tradestation failed once doing it...however, their new platform is darn good as is Multicharts which just rolled out a new version.
Oh I agree with this wholeheartedly. Always put every function and feature "on the design table" BEFORE WRITING A SINGLE LINE OF CODE.
The types of strategies I am programming are far beyond the scope of what any retail platform I've mentioned can handle. Some of the things you've mentioned I am using. One part of one of my systems would take around 20 days to run a back-test on if I used a traditional retail platform. My platform churns out the results in less than 7 minutes. Believe me, if I could have, I would have used a normal platform, but it was just wasn't the right tool for the job.
retail platforms and a professionally coded platform architecture from the ground up are hardly comparable. Like everything in life good things take time. What is touted as a viable solution in the disguises of Multicharts, Ninja Trader, TradeStation, RightEdge, and what have you simply are not stable and certainly not efficient (memory and raw processing speed) enough to be considered for high frequency trading or any other frequency beyond a few symbols. I am very much in favor of utilizing existing technology instead of re-inventing the wheel but I do not consider it re-inventing some retail products that can hardly manage a bunch of orders or cannot keep a broker connection alive for more than 10-12 hours without errors propping up and messing with the whole platform. Dude, you could argue in the same way that it is a foolish endeavor for Google to have gotten into the complex mobile phone market or OS market. Fact however is, that money is not falling off the tree, and to be honest I do not know a single trader, friend, or for that matter a SINGLE VERIFIED story of a trader running systematic algo strategies within a retail product framework while consistently generating positive out-sized risk-adjusted returns. Maybe you can provide some (other than the made-up testimonials on the Russian/Ukrainian websites (last time I heard MultiCharts originated from a Russian or Ukrainian software house and just to start the app it had to connect to a single server and users had to pray that server was up and running. Or that there was software built-in that had the ability to send portions of strategy code to the company without users' explicit agreement nor knowledge. Funny world, those retail products, but hey, it must be foolish endeavor that all those hedge funds and investment banks and few independent idiots like us engage in. Thanks for setting my head straight.
I have made the same experiences unfortunately. No one is eager to write a trading platform from scratch, but when you just can't find any platform that provides the necessary features and stability, you have no choice. Compared with the high quality of other software tools today, retail trading platforms seem to be 10 years behind the industry standard. In the end, when you spend some time with trading strategies, it's far less work to write a platform that is designed just for your need, than permanently finding workarounds to overcome the limitations of existing software.
exactly right. Those who tout retail packages generally have a stake in such businesses (= snake oil salesmen). In no other industry fall so many greedy and unknowledgable people pray to sales men than in retail financial trading. I may sound rude, rough, but I am honest. An excellent example are logging libraries: I would never write my own log class because there are some excellent packages out there (including open source). I would do the same if there were Order Management Systems out there that were capable of doing what they promise, to manage open orders. But there are not. Most of the retail packages look fancy with dandy charts and lots of colors and indicators (lol) but nothing behind to support real-time, live automated trading. NONE. If I needed a charting platform I would go with Amibroker, a USD 200 package that is faster than anything out there in its class (even compared to professional high-priced software used by professionals in banks and hedge funds). Unfortunately charting is something I do very rarely, what I need is a functional trading framework for automated strategy trading and nothing so far fit the bill and thus I started to write my own platform 3 years ago and since then have never looked back nor regretted a minute I spent developing and growing it.
connections are probably the most error prone. use fix not sure about any frameworks. Use a message layer to make things easy, use events, and go easy on the threads
Which message layer are you using? I decided to go out-of-process for each module. A central controller with Dashboard in WPF, a strategy module, a data source module, an OMS/PMS/RISK module, and an execution gateway. All independent applications communicate through a brokerless message library, ZeroMQ. What are you using? In that way I have a free choice of language (GUI in WPF/Silverlight), execution related code in C++, most other code in C#.