jimibt wrote: ↑Sat Jan 27, 2024 3:03 pmpossibly that would work, but that is a very subjective view maybe. tbh -when i did this, i was leveraging the BF api using c# (rather than BA), so i used a dictionary object that had the runner name as the key with the *cargo* a list of objects that contained the datetime of the action, coupled with the prevailing odds at the time. what I then did was to capture those dictionary objects as frequently as the streaming presented them. i'd then process each runner against every other runner and if a pair was found to be heading off on a parabolic journey, i'd set a back bet on the ascending odds candidate. this would typically be matched at 4-6 odds and would then tumble back down to evens or thereabouts. I'd definitely NOT be looking to back at anything below 3 odds..Bobajob wrote: ↑Sat Jan 27, 2024 10:17 amjimibt wrote: ↑Fri Jan 26, 2024 5:26 pm
the KEY to this one is to monitor the book value on each runner using sv's (on a high streaming refresh) and then do a constant lookback across the last 10-15 changes and identify the point where you have 2 runners increasing and decreasing their book% in almost equal ratios. then, place either a back (or lay) at xx ticks above the current price with an offset xx ticks below the current price. with a bit of trial and error, you should manage to catch a few of these. thereafter, it's all about finessing things, sorry if i make it sound simple, it certainly isn't straightfwd but is do-able.The way I would finesse things is by backing the 'likely' winner from odds 1.2 downwards and 'greening' up before it became a 'likely' loser at odds of 1.05. If you think the 'likely' winner is certain to win then obviously no need to 'green' upit's all about finessing things
this was just one variation, but was the one that bore the most fruit.
Not a problem.possibly that would work
The only problem is when both 'likely' winners 'fall/UR' at the last fence. Double whammy. FFS
Swings and roundabouts. Snakes and Ladders