… and this

For clarity on the discussion, I added the following image to the Gruss forum thread.

It includes the closing bets (a mirror as expected) and the p&l for the period. The moving average is just to give a clearer view of the trend. (And colour is different to first chart.)




Negapo and Captain Sensible commented/discussed over on the Gruss forum (click here to have a look) referring back to my discussion with Steve that started here. It’s about value and where we find value. Both discussions are interesting. Here’s how I see value and what it means to my bot.

True value

The true value (true odds/true price/etc) of any horse/dog/yacht can never be known before the event. The fact is a horse will either win or lose (except in a dead heat but let’s ignore that for now). The closest thing we have to true value is the starting price (SP). If you were to back (on Betfair) every favourite horse at it’s SP, I’d expect you would be on average around break-even, having winning/losing runs, but nothing consistent (your wallet would decrease due to commission paid). If this was not the case and SPs were always overpriced for example, then this would be known and people would exploit them, which in turn would effect change on the SPs, pressuring them towards true value, therefore making the SP near to true value. It’s a system constantly being balanced by it’s participants (the crowd).

Value bet

You’ll never know the true value of a single runner. You have your views though and decide that dog number two in the 15:35 has a true value of 4.0, the market is currently at 5.0, you back it with a stake of £10. It wins. Were you right or wrong to price it at 4.0?  Again, you’ll never know, not on that one outcome. After the win, and after the fact, the true value was 1.0, because it won. In the unlikely event that you always pick winners, not one loser, then stop reading this, you are unique and very rich (or you’re trying to sell something). You’d also be able to say the true value of any of your selections is 1.0, because they always win. In all other scenarios though, you’ll know if you’re finding value bets because you’ll be making profit in the long term. If you repeatedly back at 5.0 when the true value is 4.0, you’ll see it in your results. You wont win every bet, but you’ll be on the right side making profit.

Value trade

Finding value when trading is, or can be, different. Making profit will mean at least one bet in a trade is at value but this just has to be, as you’ll be making that trade across, or on one side of, true value, with both a back and lay position. I find it easier to explain this using some excellent graphics indicating back and lay points.

The trade in the image below, with respect to outcome, the lay bet is at value, the back bet isn’t. The result is profit.


The trade in the image below, with respect to outcome, the back bet is at value, the lay bet isn’t. The result is profit.


The trade in the image below, with respect to outcome, both the back and lay bet are at value. The result is profit.

The trade in the image below, with respect to outcome, the lay bet is at value, the back bet isn’t. The result is loss.


The trade in the image below, with respect to outcome, the back bet is at value, the lay bet isn’t. The result is loss.


The trade in the image below, with respect to outcome, both the back and lay bet are not at value. The result is loss.


From these professional quality graphics we can see two things for sure –

  1. If both back and lay bets are at value then you have a profit.
  2. If both back and lay bets are not at value then you have a loss.

In the other masterfully created images where one bet is at value and the other isn’t, it is the relative price of the back and lay that determines profit or loss.

What’s it mean to me?

This brings us back to the point I was challenging last year regarding API crashes – “Every bet you place with a bot should be sent because you believe it to be value at that time and it should be allowed to stand on it’s own merits.” – Steve.

Looking again at the first image –


If my entry point is the lay at 2.34 then not closing would leave me with a value bet. If my entry point is the back at 2.42 then not closing would leave me exposed with a less than value bet. However, I see statistical value in backing at 2.42 and I’m predicting a move to 2.34 due to market conditions, with no regard to the runner/selection/sport. I need to close the trade to profit. (These figures are for illustration, in reality I’d be expecting a move from 2.42 to 2.40, one tick only.)

I have no idea at all if my bot is entering the market at value with regards to outcome. My only concern is the short-term price movements. My bot is scalping, chasing pennies, harvesting small profit from others intended trades, jumping in the middle, whatever you want to call it. I have no care for the outcome or the sport, only the market and it’s behaviour. Therefore my requirement is to close out every time, for profit or loss, within seconds of entry. I am aware this type of trading is disliked by some, such is life.

Out of interest and in response to a comment by Captain Sensible, below is a chart of the results (P&L) of all the back entry bets placed over 6 months on the Australian horses. As can be seen I’d currently be over £300 up, hitting a high of over £400 and a low of around -£300. But there is no consistency to be relied upon here. This chart suggests to me that I’m not relying on my entry being at good value with regards to outcome. Closing all these trades resulted in a steady consistent profit.



2017 Results

Here are the numbers for 2017 –

Number of markets traded – 28,006

Number of bets settled – 167,836

Traded volume – £852,690.97

Profit and loss – £424.77

Return on traded volume – 0.058%

I haven’t really been bothered with it for a few months and am actually surprised with the final figures (DIY and family have had my time of late). I check in on the VPS now and again and was seeing the past few months not doing very well. The totals for 2017 are propped up by a strong start to the year (see image at bottom).

A little dig in to the numbers we can see that more markets were traded than in 2016 – up 1231 – I did run in other events for  a couple of months or so, which accounts for about the difference. Number of bets settled were down. Traded volume was down overall by around £150,000. Average traded per settled bet dropped from £5.27 to £5.08. Return dropped to 0.050% from 0.069% with a profit for the year of £424.77. (Taking into account the costs of the bot, currently at £21/month, gives a real profit of  £172.77 and a real return on traded volume of 0.020%.)

BIG FIGURE – Traded volume since restart in 2015 is –


That’s a multi-million pound botting operation right there!

I spend more time thinking of coding than actually doing. I sat down to do some tonight but ended up sorting results and doing this post. We’ll have to see what I get up to this year but I would like to advance the current bot.

To my fellow bottors – I hope you all profit from your hard work, happy 2018.



August ’17

The streaming version of Gruss is better now, none of the issues of late with missed market list updates or getting stuck on expired markets.

The new Oscar on the Aus horses has performed flawlessly (apart from another schoolboy error that lead to it trading one race the first day out and not moving on). I now need to add all those changes to the UK dogs, not that I have any trouble there but the code is neater and more efficient, so good practice to implement.

I haven’t done any more with the bots other than update Gruss when new beta versions are released, as I’ve been busy with other things.

A good chart from the UK dogs, less up and down than last month.


Generally good for the Aus horses. The sharp up then down was a run of four races where only one back bet was placed. No offset or green bets placed/matched. I’m assuming there was either an API issue or connection problem. These races don’t seem to suffer from early starts, so it isn’t that. And they were different venues. One of those things.

The sharp drop prior to those four errors was a failed offset/greening sequence. There were 7 back bets placed/matched fully but the seventh lay bet wasn’t matched and then greening only partially matched.

These were all before the new code for greening went in, so I’ll have to wait and see if it happens again. I’ve probably said it before but in the long run, these errors tend to have very little effect.


Although I praised the US horses last month, compared to the Aus dogs, this chart has pushed me to stopping the bot. Four missed offset bets resulting in a gain overall. I think the way my algo trades the markets, it just isn’t worth the risk with too few bets placed. There isn’t the turnover to recover in time for the next problem/error.


As mentioned last month I went to the Ebor festival at York for the Saturday races. It was a good event, nice weather, plenty to eat and drink. I’d gone with a tight limit on the betting and placed bets with the on-site bookies, to enjoy the experience. I don’t really like gambling though (in the traditional way), I can’t get past thinking I’m just going to lose as I don’t know anything about picking winners. Won nothing, surprise, but had loads of laughs and enjoyed getting to the front to see the horses race past the finish post, great atmosphere and very impressive. And Saturday night in York was a laugh too, finished with a kebab, “large… hic… everything on it mate… hic…  “, which seems like the best thing ever at the time but probably best forgetting about afterwards, rather than contemplating it’s content.

VPS data usage – streaming

Here is the data usage for my VPS, taken from the Tagadab dashboard.


As you can see, since streaming started in July, the amount of data/bandwidth used has reduced considerably. The differing previous monthly figures are down to various reasons – number of bots live/number of events/missed days due to errors/etc. June – 13GB – and July – 2.33GB – both had the four Oscars and one other running most of the time. Even when I wasn’t running full-stream, the data is still delivered via the stream, it’s just how the data is refreshed in Excel that is regulated, so it makes no difference to the bandwidth. (There are options to run off stream but I haven’t used these with the new version.)

The £0.00 value is because there is 50GB included in the package, charges are only incurred for exceeding this amount.

Updated updating and simply greening

First, Liam replied to July ’17

You can set the conflation during the market subscribe request, defaults to 0 but you can choose how often you want to receive it. It’s odd because it’s a handy feature but none of the trading apps seem to use it.

I know betfair use a piece of open source software called Kafka for managing streaming updates but there is probably something else handling slow consumers (conflation). Sockets are complex but at a high level it is my understanding that once the receivers buffer is full the server is told this which then allows the server to halt sending more data. I believe it is then a case of updating that ‘halted’ data to prevent the consumer receiving ‘stale’ data.

Hopefully that makes more sense.


Thanks Liam, it does. I appreciate this is more in-depth stuff and beyond most of us but I am interested in these things. It’s the sort of detail that gets exploited by those in the know before anyone else cottons on. I wonder if the lack of utilisation by trading apps is because setting it for optimal performance would be very specific to an individual socket, the machine’s processor, what else it was doing at the time and the level of market activity?


Now, bench testing complete, I’ve put the new Oscar live on the Aus horses only (staged implementation, sounds good). As mentioned in the last post, there are two areas where significant changes have been made to the code.

I trialled two different methods of navigating the markets. One is quite basic and simple code, the other more complex but I thought it would handle any troublesome delays better. It was over complicated though and as I worked through the errors whilst testing, it became bloated and confusing. Impact wise, the simpler code is only one extra step on an if-then-else statement. And it’s the same amount of steps as the old code. I’ve set it to update after a set time, 1:45am, then select first race in list shortly after. I use the day number, as integer, to check if the process has completed today. Previously the list update was performed within a set time period, which was fine when there were regular updates at the desired refresh rate. But with streaming, if there’s a market loaded that’s a few day’s off, as is sometimes the case for big events, there are no regular refreshes. This can mean that the set time window see’s no updates to run the list refresh code.

That change is almost not needed because of the next change. I’ve coded to turn full streaming off when not within the trading time zone. This forces regular refreshes. The above change will still come into use though if there are any issues causing a delay (can’t think what, but the code is better now, I’m sure).

Finally for this update, I’ve employed the green up trigger to replace my code. The module is less than a quarter of it’s previous size and the trigger takes care of cancelling any unmatched bets, submitting a greening trade and then chasing every second until matched. Splendid.