OHLC fill/stop simulation

Discussion in 'Automated Trading' started by bihiselo, Nov 11, 2009.

  1. bihiselo


    Hello guys, I have been reading the board for a couple of years and finally got around to trying to develop something myself. Initially I want to be able to backtest on daily OHLC data and I am writing my own system (the tech is the easy part for me). What I wondered was how you evaluate your positions for events.
    Here is what I am thinking:
    Fills first against open,
    Stops vs. Hi/lo,
    Targets against shy of hi/lo
    Timed out trades at close.
    Generate limit orders at close
    Does anyone have any experience/suggestions on how this reflects reality? Tips on ordering?
    Any help is much appreciated - I know there are a few guys here doing impressive work.
  2. bihiselo


    Reading that post back made me realise how garbled it sounds. Simply put, I am trying to work out how my open positions would have been affected during a bar, using only open, high, low and close values. The questions is: in what order should events be evaluated and against which values to best reflect reality?
  3. You are toast. Seriously. You can not really make assumptions there.

    Get tick data, better tick data with best bid/ask (which is needed in SOME areas) and you can simulate your fills pretty perfectly, especially if your execution engine puts in a realistic delay to order execution.

    Anything else wont work. Open/Close may, but stops filled during a bar are just pure random guess.

    What you COULD do is:

    * Take bar height.
    * Divide by number of trades
    -> create assumption how well the bar was traded.

    Especialy during totally dead times this will give you low dividers and you could react with worse fills.
  4. bihiselo


    Thank you very much for the reply. Yes, I guess tick-data backtesting is what I would like to do, but I haven't got the infrastructure yet to handle that amount of data yet (db etc.).

    I am sure I have heard some people say they backtest on one minute bars. The same problem will arise there won't it.

    The reason I came up with that ordering is that it is worst case i.e. check fills first then stops, so if stop and fill and target are in all in the interval [low,hi] I automatically assume that I stopped out at a loss even though the reverse may be true.

    Maybe I should just get my chequebook out...
  5. I heartily agree with Net on this one.
    If you are reluctant to pony up for tick data and your broker has an API, you could always cobble together a data recorder to grab bid/ask/fill/volume tick data during the sessions you wish to simulate. Yep, it's cleaner (rogue ticks will be gone, etc) if you grab it from a provider, but it's always an option.
    In a pinch, 1-minute bars will give you an estimate of things and some brokers allow you to get finer snapshots (30 seconds, 10 seconds, etc), but ticks are the way to go to match the real world as close as possible.
    Unfortunately, some brokers only offer limited amounts of recent tick data (I think you can download 1 day and I'm not sure if it's actually available while the session is open).
  6. Technically if you go as low as possible with your resolution and assume worst possible trade - it should work as in it can not really get worse....

    ...escept on some things (currency mini in the night) there thigns dont really trade but move.... NO way to simulate execution there without bid/ask.

    And, obviously, you can not do anythin in another way like tick charts etc. ;)
  7. maxpi


    You can do iterative tests. For speed you can make assumptions about whether the high or low came first and make assumptions about whether you got filled if price only touched your limit. Slower but more accurate would be testing against tick data, that clears up the question about what came first but you still have to make assumptions about whether you got filled when price touches... and for even slower and more accurate you can test against Bid/Ask data......Personally, I won't bother with bars at all, those assumptions can just wildly skew results. I start with tick data and then retest with Bid/Ask data to get a feel for what the fill assumptions should be... I can't do what I want with a single software package yet and that leaves me with assumptions about differences between softwares....
  8. Have you considered simply forward testing your system?
  9. bihiselo


    Thank you all for your suggestions. I am planning to backtest first on training data (600days), then test data (200days) and then forward test any strategies which survive all that. I think I will give the simulation I suggested a go - as it is quite pessimistic (and I don't have to get any more data) but I will definitely buy some data for a few interesting symbols and get going on the tick data ASAP. Now I need to think about a whole host of issues:mad:
    Anyway better than losing money unnecessarily so thank you.