The Beauty of "Dobbing"

[pawras]

If you are backing to lay as it shortens up what about if it never shortens up and drifts instead? I.e. if it drifts instead by x trade out to mitigate your loss. But you need a bot for this and when you're in the robot wars like that then who has the best connection speed and latency comes into play.

 

[retriever]

No, because ideally you would place into the market 'a stop' for the drift.
So it would be 2 steps IN, 1 step OUT.....for example.

And, as you are placing your bets in the market beforehand, connection speed and latency is irrelevant......your bets are in the queue to be matched, one way or the other.

You just need more horses that shorten enough than those that will drift. You still have to 'know your stuff' re selections.
A bot just helps with turnover of bets.

 

[pawras]

From what I've seen I thought a stop is not guaranteed to be matched and not at the price you want because the order isn't put into the market until the price trigger is hit so latency will determine how quickly your software recognises that price point being hit and then how quickly it can fire in the stop order.
If you're purely working pre race with stops then it's less volatile and they're more likely to go in as your want.

 

[nicksar]

'Trobbing' seems about right !

I did go through the races again with BA yesterday, but it made another loss... although it did actually throw up a horse that got to the lay position and didn't win. 1 race amongst about 80-odd that actually dobbed is not indicative of a working system, and so I kept my money in my pocket today as opposed to my earlier comment about continuing it up to the weekend. It needs a bit more studying, and as soon as Clive Keeling follows up on his original mail, I'll post it here.

You could try Clive Keeling's "Hyperbets" secret platform which is what he's selling this week,it will be something else he's selling next week so you need to act quickly!!!!.

 

[paulb164]

Yes - true - I'd forgotten.
Can you not do testing in practise mode?

I guess so, but it won't be a true reflection of the system dynamic within BF, and where I join the queue for the 1.25 lay bet if/when it kicks in.

I am considering redoing the trial with exactly the same parameters as the original post, bearing in mind that there will be a much reduced amount of qualifying races... perhaps just sticking to;
- races with 6-8 runners
- 6-7f and 2-2m 4f distances
- A/W tracks only (or should I just stick with the 3 in the original post ? Does anyone think applying this to all A/W tracks will impact the system much ? I personally think it won't - probably not as lucrative as the 3 mentioned, but profitable nonetheless ?)
- I'm not entirely sure what he means by "Handicap and Hurdle races are clearly the biggest profit makers for layers, contrasting with the focus on all-weather above." - is he suggesting that handicap and hurdle races should be avoided if they are best layed instead ?

 

[paulb164]

From what I've seen I thought a stop is not guaranteed to be matched and not at the price you want because the order isn't put into the market until the price trigger is hit so latency will determine how quickly your software recognises that price point being hit and then how quickly it can fire in the stop order.
If you're purely working pre race with stops then it's less volatile and they're more likely to go in as your want.

The automation will enter a stop loss bet as soon as you want it to, not necessarily as soon as it hits the stop loss position - it is possible to get ahead of the game in that respect. With my current automation, as soon as the race goes in-play, it puts that 1.25 lay in immediately. There's nothing stopping me putting that same bet in before the race starts, and instructing BF to keep the unmatched bet into in-play which theoretically puts me even further up the queue.

 

[nicksar]

From what I've seen I thought a stop is not guaranteed to be matched and not at the price you want because the order isn't put into the market until the price trigger is hit so latency will determine how quickly your software recognises that price point being hit and then how quickly it can fire in the stop order.
If you're purely working pre race with stops then it's less volatile and they're more likely to go in as your want.

I have been using Betfair for many years & BetAngel is my software of choice,i trade Pre race a lot ( with sizeable stakes) the "stop loss" isn't bullet proof and I've seen a fast market move "blast" through my "stop loss" position plenty of times.

 

[pawras]

I have been using Betfair for many years & BetAngel is my software of choice,i trade Pre race a lot ( with sizeable stakes) the "stop loss" isn't bullet proof and I've seen a fast market move "blast" through my "stop loss" position plenty of times.

Indeed I've encountered the same kind of thing hence my comments about the difficulty of matching theory & reality, plus those with lowest latency have the advantage.

 

[pawras]

The automation will enter a stop loss bet as soon as you want it to, not necessarily as soon as it hits the stop loss position - it is possible to get ahead of the game in that respect. With my current automation, as soon as the race goes in-play, it puts that 1.25 lay in immediately. There's nothing stopping me putting that same bet in before the race starts, and instructing BF to keep the unmatched bet into in-play which theoretically puts me even further up the queue.

If you are putting in a lay below the current price you can put it in early to be front of the queue but if you are putting in a lay as a stop loss above the current price then your software can only put it in when it detects that price has been hit, then it's whose quickest before it drifts further out.