Slow High Frequency Trading

Discussion in 'Automated Trading' started by Jerry030, Jul 21, 2010.

  1. Jerry030

    Jerry030

    Can anyone offer any suggestions on getting into HFT where instead of trading on ticks in the sub second range one is trading a time window of 10 to 60 second bars? The max trade length is 1 bar (10, 30, 60 seconds).

    This would be very slow by industry standards.

    Topics I'd welcome a comment on:

    1) What kind of server and capacity is required?
    2) Associated hardware
    3) Software platform (a package to take a signal to buy or sell from a 3rd party predictive model and execute and manage the trades)
    4) Co-location pros and cons, do's and don'ts

    For reasons unknown, HFT data is much easier to model and predict than the traditional 10, 30 and 60 minute bars I have always traded.

    Thanks

    Jerry
     
  2. At that speed, almost anyone retail would do from a regular internet connection:
    Tradestation
    IB
    Laser
    Sterling Pro
    Trading Technologies Pro
     
  3. Jerry030

    Jerry030

    Syswizard,

    Many thanks for the suggestions.

    Jerry
     
  4. What you want to do is not HFT it is simply automating a strategy. This is a very good approach for a first time/try into the automated arena.

    For hardware it all depends on your platform and what exactly you are going to do with the box. If you will ONLY be running the strategy on the box and nothing else (meaning no charts, no pulling data into excel, no intense calculations, no internet browsing) then a simple box with 4GB RAM and an e8400 or q9650 CPU would work.

    Some things to consider about your execution program: Is it multi thread capable? Is it hyper thread capable? Java based systems tend to be fairly CPU intensive while a .NET or C#/C++ app would be considered "lighter" (but that all depends on what the thing actually does). Do you need direct access or can you trade with someone like IB who crosses orders internally?

    Also, where are you getting your data from? Most bar data I know of has been created from tick data versus getting a bar feed.

    Good luck

    EDIT: Where are you located? If you are on the East Coast & trading equities or Midwest and trading futures you should be fine with a business class internet provider (something over 20mbit symetrical). Co location should only be considered if you need to process data and execute very quickly or if you are very remote from your execution servers and have latency issues.
     
  5. Jerry030

    Jerry030

    Winston,

    Thanks for the insights.

    My current trading set up uses three machines to trade:

    1) Price Server: Acquires price data, reformats, adds mathematical attributes and save as a input to the modeling process.

    2) Model Server: Reads prices once per bar cycle (currently either 30 or 60 minute) from the Price Server, applies production predictive model (saved as C++) to current price file. Output of model is passed to a program that makes the trade decision, sets stops, evaluates risk, and makes the actual trade/no trade decision.

    3) Trade Server: Gets the trade decision from the Model Server and applies the trade through a broker supplied API. Monitors fills and passes actual trade status back to the Model Server.

    All this works fine of course as I currently trade bars no shorter than 30 minutes so if the cycles time on all this is 4 to 6 seconds it means nothing in terms of a trade that might last for an hour or two.

    However in considering a move to trades that last no more than 60 seconds I figure that I need to incorporate at least some HFT approaches to get my cycle time < 1 second.

    I'm located in Chicago, about 10 miles form the CBOT, but the system is for Forex.

    Thanks to all who have commented as I now see that collocation is not really my first step or probably even required.




     
  6. maxpi

    maxpi

    it seems like you have hardware overkill there. More moving parts = less reliability too..
     
  7. dloyer

    dloyer

    3 boxes seems like a lot. You might be better off with one box or even one process in one box. Moving bits around is often the slowest part.

    Also, put some thought into what happens when you loose your network or power. It WILL happen. It depends on your system if the occasional missed trade or missed exit is more or less expensive than the monthly cost for a colo.
     
  8. Jerry030

    Jerry030

    My thought was to have each server doing one thing only.
    For 60 min bars the file trasfer time wasn't a factor but as you note now it becomes one.....live, learn, and modify!
     
  9. rosy2

    rosy2



    3) if you dont write it yourself there are many options: orc, rts,aeigis, portware,actant, ...
    4) since your doing FX. I think most banks have there matching engines in new jersey.

    you mentioned something about transferring a file. that doesnt seem right to me anywhere
     
  10. i would suggest trying to combine the modeling and execution box into the same thing.

    gigabit switches and a really good network can get you where you need to be.

    Write to a common drive/network drive/GOOD NAS, use RAID, use high I/O, use low latency broker/risk check, have decent connectivity.

    I know many people who take data in to one location and then bounce it to either a central database or to a bunch of boxes on their network (legally of course). Your method is sound, you just need to execute and work on some little network nuances and it seems like you would be fine.
     
    #10     Aug 3, 2010