Custom Trading Platform

Discussion in 'App Development' started by naifwonder, Aug 16, 2012.

  1. I've been working on testing out some ideas that involve analyzing a great deal of data across multiple assets. The amount of data to be analyzed in combination with the nature of the systems I wanted to build made my project unfeasible for typical retail trading platforms. As a result, I built my own platform and framework for building/testing trading systems. At the moment, it can process 10 years of intraday data for several hundred stocks within a few seconds. As great as this is working, I am trying evaluate scenarios in which such a platform might fail. Do any of you guys have experience with undertaking such a project? Some of my questions are:

    - What are some areas of a custom platform that you find to be particularly error prone?
    - What are some things to be extra weary of while building the layer to interact with brokers?
    - What are some good frameworks, if any, that one can use to analyze trading system performance based on a log of trades? I'm language agnostic when it comes to this since I am more interested in evaluating the programmatic logic then using the code itself.
    - What stability and maintenance issues have you run into while undertaking such a project?
     
  2. In the order asked:

    - OMS, no question. Managing and handling orders is where most platforms fail and it is imho at the same time the trickiest and most complex aspect of any trading platform to get right.
    - Make sure you get your "heart beat" to broker API/FIX connectors right. Nothing wrong with the connection getting lost at times (well not good either) as long as you know it happened RIGHT AWAY. I recommend to invest in hooking up through FIX with your broker rather than trading through an API for added stability.
    - Strategy Evaluation? Definitely something self-coded, no question. Not that most other evaluation algos are often incorrect but you may want to add other measures, metrics yourself.
    - Maintaining clean data for testing purposes is for me of the absolute importance. Once you have coded up a capable testing platform and algorithms what you are left with is the actual data and most often the data are unclean, miss data points, are not backward-adjusted, are unrealistic data because those are just data frome quote feed rather than tradable price feeds. Its of the utmost importance you peruse data as close as the data you execute trades on.

    Hope that helped.


     
  3. Thanks for the feedback. You're spot in regarding the OMS comment - that is the area I am proceeding with the most caution. I am most likely going to use a retail trading platform and interact with that via some form of API rather than directly interacting with the broker. This would give me a more strenuously tested layer between my application and the broker.

    In terms of evaluation algorithms, I just wanted to take a glance at the code to see what techniques programmers use for storing position history data (persistently and in memory) and how they iterate through the data. I coded my own solution for this, but there's always room to learn.
     
  4. When testing, the strategy statistics are stored in-memory and evaluations are computed after the test finishes because there is no need for real-time evaluations. After everything is computed the results are stored in my dictionary db.

    For live trading statistics and any execution related data (for TCA) are stored in-mem AND on a separate thread persisted.

     
  5. I wonder, why did you write your own platform for this?

    Thanks
     
  6. yeah, why??? You are right we must have been stupid, wasting all that time and effort, while we could have had it all for 100 dollars.

     
  7. LeeD

    LeeD

    Also see thread Best practices? for a lot of info on the topic (and in my posts in particular).
     
  8. nah, it's not about 100 dollars. The least I belief in is a 100 dollar product.

    But with plenty of open source platforms out there, why did you not choose one of those?
     
  9. thanks for a pointer to that thread
     
  10. *** full of errors
    *** chance of closure of the project and then I have to continue developing code I have not written myself and may need weeks to understand...
    *** lacking features
    *** arrogant attitude of the original coders

    should I add more?


     
    #10     Aug 17, 2012