System Presentation

Discussion in 'Professional Trading' started by dima777, Sep 4, 2008.

  1. dima777

    dima777

    if creating the execution code is an obligation for trading our system with a larger fund - then that is not for me...I would rather start up my own hedge fund instead...and manually open the trades..:)

    monitoring system full-time is a good idea..even if discretion is take out of the trading the pc and internet can fail..

    I am developing my system in a general purpose model building environment - not tradestation - which has proven to be rather weak in handling complex trading ideas....not saying they cannot be coded is TS, though...

    this system is the culmination of a few years of research - not something which fell on my last week in a daydream...why should I open this to them?

    Semantic system development is 99,99% of all system development...coding is relatively much more easy (idea development can be compared to writing a novel while coding to grammar and syntax correction)....they can ask any programmer to code their ideas.....
     
    #11     Sep 4, 2008
  2. What I mention is not about good or bad ideas. It's what you will be dealing with.

    Another thing is, you shouldn't expect the firms to use their resources. They've already done you a favor if they decide on going forward, and asking them to use their resources to implement a system will not give them a good impression.

    Implementing a system is not a simple process for us. Coding is the easy part. There's system evaluation (analyzing what type of equipments are required and the cost), multiple performance tests(running it on UAT, then gradually increasing size) and other process (like comparison analysis between hypothetical and real money, defining a contingency plan for a shock event... cut the system, reduce size... etc. etc.) before we take to go fully live for a fund.

    This is coming from a guy who's done what you're looking to do for over 6 years, in Chicago. Only thing you should be asking from them is the capital to implement it. If you start expecting anything other than capital... you'll start giving them an impression as a needy newbie.

    It's like:

    "I need money to trade the model.
    I need a programmer to implement this.
    I need a fast computer to run the system.
    I need...
    I need...
    I need...

    You guys do all the middle work and I won't give out my system. But I won't take any risks, and use any money.
    I've already made the system.
    You do the rest of the work..."

    Doesn't sound good. Unfortunately, there are guys like me who's acquired the skills to develop, implement and manage models. There's quite alot of guys in large funds who can do it too. They're the guys you have to compare against, not the average retail developer...

    Finally, you're not monitoring systems for operational risks like black outs or down service. You are expected to monitor the market for your system.
     
    #12     Sep 4, 2008
  3. dima777

    dima777

    i see..thanks for the detailed answer....Monitoring markets for structural changes is ok.....the system performance will indirectly signal any significant changes of the assumed underlying market dynamics...I am feeling that starting a hedge fund is not so less attractive as joining a fund if all the "dirty" work will still have to be made by me...))
     
    #13     Sep 4, 2008
  4. It's not dirty work.
    It's about understanding and being able to control aspects involved in trading.

    Without control and understanding, there is no management.

    It's nothing to be discouraged about. I started off with a prop. firm sponsoring my model and I was only able to use Tradestation. I was able to learn programming and all the other stuff with as I grew my reputation as a developer.
     
    #14     Sep 4, 2008
  5. dima777

    dima777

    I wonder how close they can reverse engineer a system based, say, on 1000 past trades.....BTW...I can provide any kind of performance metric, starting from Sharpe ratio,,,why reverse engineer the strategy?
     
    #15     Sep 4, 2008
  6. dima777

    dima777

    I am coding my strategy on my own now in excel and find it ok in terms of difficulty....I do not mind learning c++ or any other language as long as my top priority stays developing and implementing a system with a positive expectation...
     
    #16     Sep 4, 2008
  7. vita

    vita

    It's a pickle. Unfortunately there are many reputable firms, even GS, which ask you to present your model in front of their Quants in order to generate new ideas.

    I don't mean to discourage you but remember that if you join big banks they make you sign a paper that makes them the sole owner of any piece of code that you develop in their including any modification on your own model. Hedge funds may go easier and let you review the confidentiality agreement with a lawyer before signing up with them.

    About your system presentation, remember to layout how systematically you back tested it. To avoid curve fitting impression, you should show both in-sample calibration procedure (if any) and out-of-sample trading performance.
     
    #17     Sep 4, 2008
  8. dima777

    dima777

    thanks for your kind advice....:) I was thinking about including out-sample tests into the presentation just yesterday! :)
     
    #18     Sep 4, 2008
  9. vita

    vita

    Sure, here are other topics they would be interested to see in your presentation:

    1) Return (PnL) Histogram
    2) Equity curve
    3) Drawdown Statistics
    4) Sharpe Ratio (correctly calculated)
    5) Average No. of trades perday
    6) Win/Loss Win/Total ratios
    7) Margin to Equity Ratio (Leverage) and how you calculated it
    8) Hit ratio which is the same as the number of successful signals per total number of signals within a period of trading (day, weeks, etc)
    9) How your stops and limits are calculated or selcted. Or whether you use rolling stops.
    10) Risk limit as a percentage of equity capital (not margin) per trade, day, or week (e.g., 1.5%, 5%, 15%)
    11) how you taken into account slippage, commissions and fees.
    12) Backtesting procedure including in-sample calibration, out-of-sample trading, testing against time shift in data e.g. if you calibration started a month (or a day) earlier or later this should not have significant impact on performance if your system is robust.
    13) Other specific details...
     
    #19     Sep 4, 2008
  10. dima777

    dima777

    thank you...the list looks pretty comprehensive...
     
    #20     Sep 5, 2008