Building an ATS - Logbook

Discussion in 'Automated Trading' started by tiagor, Dec 5, 2012.

  1. tiagor

    tiagor

    Hi,

    After spending some time reading a few threads from this forum section I thought of giving something back. This thread will aim to provide a logbook on the buildup of my own ATS and the results achieved with it, be them good or bad.

    Just to provide some background, I've played with some live trading with CFDs and Forex in the past, using small size accounts just to try and get the feel of how the market works. This will be my first experience with automating strategies.

    Be advised this is not my job nor I have plans for it to be in the future. It is an intellectual challenge to prove myself it is doable by an interested invidual with limited resources. I've worked in IT for the past 15 years and even though I'm not a developer I feel reasonably comfortable with programming languages and automation.

    Everybody is invited to participate and provide suggestions for improvement and guidance. However, I appreciate no trolling on this thread. If you don't like it just don't read it.

    I'll split some details on my plan and the work already done over the next posts so as facilitate the thread readability.
     
  2. Broker's API or FIX messages? :p
     
  3. tiagor

    tiagor

    Removal Request
     
  4. tiagor

    tiagor

    Here are some macro details of what is going on:

    MARKET: For now I’ll be focusing exclusively on FOREX
    Reason: Less instruments to focus on, greater market liquidity and increased volatility. I will be working mostly on the EUR/USD pair possibly extending to other non-exotics in the future.

    BROKER: MBTrading
    Reason: Already have an account with them, they provide direct market access and provide an easy to access API. I rather pay predictable commissions for order routing than dealing with unpredictable marked-up spreads on a dealing desk. I’ll be using their COM API because using FIX involves additional fees and introduces greater complexity on the design of the ATS. As I don’t plan to do High Frequency Trading (HFT) I don’t anticipate significant negative effects from the increased overhead of using the API.

    LANGUAGE: Python and (if needed) C
    Reason: Python is faster to write and maintain than other high level languages such as C# and C++. If needed for specific time critical functions Python easily integrates with C.

    STRUCTURE: The program is structured around two modules, what I call the SHELL and the GHOST. This was chosen so as both modules can be redeveloped without significant impact on the other (e.g. if I want to change to a FIX based SHELL in the future, or change to another Broker, the logic won’t have to be redesigned). Here follows a macro description of both:
    SHELL: Provides interaction with the broker API for establishing and maintaining connection, order execution, quote management and logging. This module implements two main components that can be invoked: live trading and simulation. Each component may interact with one or several GHOSTs.
    GHOST: Main logic modules that implement the decision making based on live or historical data. Can range from simple decision making procedures (price action or indicator based), or decision based on learned datamined patterns.

    Current Progress: The SHELL is mostly developed by now. I can log in, receive quotes and introduce orders. I’m finishing work on the simulation component which breaks an historical data feed in 2 segments, allowing for backward testing for in-bound and out-bound data for optimization and correlation. The simulation incorporates broker commissions and tries to model both slippage issues and order execution problems (unfilled limit orders).
     
  5. Looking forward to reading about your progress :)

    Good luck.
     
  6. CT10Gov

    CT10Gov

    It's interesting that your ghost (in the shell... very nice) is the least fleshed out part of your project.

     
  7. tiagor

    tiagor

    Indeed. But one could argue what's the use of a ghost without a proper shell.

    Seriously though, I've got a pretty decent idea for 2 GHOSTs that work on entirely different levels but I will not even try to "guess"timate their performance before some simulation and then again, with live testing.

    I'm laying out the code for some of the logic of the first GHOST (I'll later provide it with the gift of a name if it proves worthy).
    Even though this thread is oriented to the buildup and performance of the whole system I won't be going to the minute details of the strategies in particular (for obvious reasons). I can advance though that its decision process will be based on an estimation of the very near term market direction by shoving around some given interpretation of patterns in time, price action and tick volume. This are not fixed rules though but depend on the behavior of the market on the short term, weighting some probabilities.

    Failure is already guaranteed. Let's see if I can prove it can have a different ending. :D
     
  8. Are your shell and ghost two separate executables?
     
  9. tiagor

    tiagor

    No, the ghost(s) run(s) within the shell.
    They are a different module/class that is passed as an argument to the sim/live trading functions of the shell. This way I can have a single shell instance (required by design on the broker I'm using) trading on multiple ghosts (which may on their turn be trading on different instruments).
     
  10. 2rosy

    2rosy

    is this open source? from what i gather SHELL is the infrastructure and GHOST is the algo. Considering this is python I am familiar with how remarkably fast this can be developed in.
     
    #10     Dec 5, 2012