Planning the Development of a Bot

Time to get down to writing some bots. As a software developer by trade, that means we need to do some planning.

A bot is simply an automated way to do something you would do manually. It has several advantages we wish to exploit, and if anything we do negates one of these advantages we must reconsider whether it's suitable for a bot to be doing it.

1. Speed is of the essence. A bot can obviously act and react much faster than a human. Because of how the APIs work a bot can monitor many markets simultaneously and strike/cancel bets much faster than any human. This has obvious advantages as the earliest mover in a market to make the right decision typically will make the most money.
2. It will behave consistently according to design. We have all found systems, techniques and tricks that appear to be profitable. Those with strong discipline might even be able to stick to them. For the rest of us though, there is always a desire to have a quick punt or to break our system based on a hunch. It makes the statistical analysis of what we're doing borderline ridiculous. That's when losses occur. Bots will do what they're programmed to do, and only what they're programmed to do.
3. They free you up to do other things. Back in 2002 when I was first trading I was spending 10-12 hours/day at screen. It was demoralising and boring work grinding out a meagre existence. I would have rather spent my days enjoying watching the sport without needing to keep an exchange screen open constantly, or doing something entirely different instead. A bot can - and probably should - work completely unaccompanied and perhaps running on a server in a data centre so I don't even need my computer to be turned on if necessary. It should be able to work on markets whilst I am enjoying the fruits of its labour.
4. The nature of building a bot forces you to be more systematic and analytical. Rather than going with "it's a hunch" style of betting/trading, you must justify every line of code. Even better, following industry standard programming methods, a bot can be "iteratively" developed, that is to say tweaked and enhanced bit by bit based on data and results. This requires us to go back and revisit our assumptions regularly, and make new ones. It's a healthier way to think about what we're doing here.

So we want speed, consistency, complete automation and iterative development based on systematic and analytical thought processes. What could be easier?

A bot has a few things it needs to be able to to meet these objective.

It must be able to login to a betting exchange or bookmaker website (the latter important for arbing bots), select an event or events, determine which selection or selections it will bet on, strike the bets thereby committing capital according to some sort of staking method, monitor those bets and impose a stop loss if necessary, green up when optimal if we believe greening up is the best way to behave, and log all the data about what it's done somewhere so we can go back and check what it was doing in a spreadsheet later.

There's a couple of bits of this which are relatively straight-forward, and others where we need to make some decisions. The logging into an exchange at first appears trivial (use the "login" function of the API), but do we want to use the API or do we want to screen scrape? Why have we made that choice? I'll be exploring that at some point and showing what the code for each looks like. If you've never written/read any code before, don't panic! It'll be understandable.

However the other jobs all give us much more to think about. We need to justify every line of code, and to meet the "systematic and analytical" test that a bot should pass, we need to handle event selection, runner selection, staking, stop lossing and greening up based on some sort of scientific analysis.

Next job then, it's time to do some data gathering to test some hypotheses.

The first idea for a bot I am going to test is one I expect to fail at the analysis stage (which is good! If it's going to fail, that's the point in time I want for it to fail, not after the bot is built and running out onto the exchanges with hard cash), but will be relatively simple to implement and therefore a good "starting project" for this blog. It is very simple to state:

Find non-handicap UK/IRE horse races which will go in-play, and back the favourite for 5% of my betting bank in the place market 5-10 minutes before the official off. Then lay it at a price giving a 10% RoI greened up with the "keep in play" option on the bet selected.

It's a very naive system based on the assumption that favourites in non-handicaps are priced fairly, and I currently have no evidence of it being profitable. Each component needs to be tested and verified before I build any code. I'm happy to modify my thoughts based on the results I get back, and I have plenty of other ideas for bots if this one doesn't stand up to analysis: the purpose of this idea is primarily to go through the analysis stages.

In the next few posts I'll be grabbing data from multiple sources and building/using tools to analyse whether this system is viable. I'll be using statistical analysis, of course, but also some funkier analysis tools like decision trees to refine event selection and the like.

Feel free to ask any questions if you have them.