Betfair's official historical data service sells timestamped market files (back/lay prices, traded volume, market definitions) going back years, with free recent price files also available. You reconstruct a market's life from the update stream, almost always with Python. Used well, it powers backtesting, closing-line analysis and any quantitative edge.
This page contains affiliate links — if you open an account through them we may earn a commission at no cost to you. It never changes our verdict.
This is a cluster sub of our pillar on advanced Betfair strategies. The pillar surveys the expert toolkit; this page is the data foundation underneath much of it — because almost every advanced edge, from machine-learning models to honest backtesting, starts with getting real historical exchange prices and learning what they do and don't tell you. Our hands-on data analysis guide pairs with this.
Why Bother With the Data
Most traders form beliefs from a few hundred remembered markets and a lot of confirmation bias. "Favourites always get backed into the off." "The draw drifts late." Maybe — but you don't actually know until you measure it across thousands of markets, and the data is right there to settle it. Historical analysis replaces "it feels like" with "across 9,000 races, the favourite shortened on average X% in the final five minutes," which is a different and far more bankable kind of knowledge.
The single most valuable thing the data lets you do is test whether a strategy would actually have worked — honestly, against real prices you could have got, including how the market moved after you would have acted. That is the difference between a trading idea and a tested edge, and it is the foundation of everything quantitative. Without the data you are guessing; with it, you can be wrong in measurable, improvable ways.
Where to Get It
The authoritative source is Betfair's official historical data service, which sells downloadable files of past market data, typically offered at different detail levels — a "basic" level with price snapshots and an "advanced" level capturing the fuller order-book change stream. Coverage goes back years across sports. Betfair also publishes free daily price files for recent markets, which is the cheapest way to start experimenting before you pay for bulk history.
Third parties resell pre-processed or enriched datasets, sometimes joined to results, which can save you assembly work — but verify provenance and freshness, and treat the official service as the ground truth. For live data to pair with history, you pull from the Betfair API. The combination — bulk history for training and backtesting, live API for execution — is the standard stack for anyone building automated systems.
What's Inside a File
A Betfair historical file is not a tidy spreadsheet of final odds — it is a stream of timestamped updates describing how the market changed moment to moment. Each update can carry the available-to-back and available-to-lay prices and sizes at each level of the book, the traded volume at each price, and the market definition (the runners, the scheduled start, the in-play flag, the status). To know "what was the price at 14:58:30" you replay the stream up to that timestamp and reconstruct the book.
This stream structure is the conceptual hurdle for newcomers. You are not reading a table; you are reconstructing a film of the market from a list of changes. Once that clicks, the richness is the point — you can recover the price at any instant, measure how fast it moved, see where volume traded, and compute things like weight of money and the path into the starting price. The detail that makes it harder to parse is exactly the detail that makes it valuable.
Tools to Read It
For one market you can eyeball a file; for analysis you need code. The practical stack is Python with pandas, plus Betfair's own published historical-data parsing tools and community libraries that turn the update stream into tabular snapshots you can analyse. The workflow is: parse the stream into time-sliced rows (e.g. price at 60, 30, 10, 1 minutes before off, and at the off), join to results, then analyse.
You do not need a database to start — a few thousand markets fit comfortably in memory — but as you scale to seasons of data, storing parsed snapshots in a lightweight database or partitioned files saves you re-parsing the raw stream every time. Keep the raw files; reparse into whatever shape each question needs. Our data analysis guide walks the practical pipeline, and building bots covers wiring analysis to live execution.
The Gotchas Nobody Warns You About
Four traps eat beginners' time and credibility.
Timestamps and in-play turn
Reconstructing the price "at a time" means replaying to that timestamp precisely; off-by-one errors and confusion around the in-play turn (when the market goes live) produce subtly wrong snapshots that poison everything downstream. Be meticulous about exactly which timestamp each snapshot represents.
Available price vs. traded price
The best available back/lay is not the same as a price that actually traded, and neither is the same as a price you could have got in size. A backtest that assumes you matched at the touch for any stake is optimistic. Model realistic fills or your results will not survive contact with live trading — the same point our ML guide hammers.
Joining to results
The price data and the actual outcomes often come from different sources, and matching runners across them (names, IDs, non-runners, dead heats) is fiddler than it looks. A bad join silently corrupts win/lose labels. Validate the join on a sample by hand.
Survivorship and selection
If you only analyse the markets that are easy to parse, or drop the messy ones, you bias your conclusions. Decide your universe up front and account for what you exclude.
Questions Worth Asking the Data
Start with questions that are both answerable and useful. How sharp is the Betfair SP — do selections win at the rate their starting price implies, across price bands? How do prices typically drift or steam into the off in a given sport? Where is the market least efficient — which bands or market types show the biggest gap between early price and closing price? How much liquidity is actually available at different times before the off, so you know what you can really trade in size? And the big one: would strategy X have beaten the closing line over thousands of markets?
Each of these turns a folk belief into a measured fact, and several of them — especially closing-line and SP-calibration questions — directly inform whether any edge you think you have is real. This is the analytical backbone of the whole market-analysis discipline.
From the Desk: A Real Analysis I Ran
The question: a folk claim says the exchange overrates favourites and underrates mid-priced runners. I tested it on a season of UK/Irish racing win markets — roughly 8,000–9,000 runners after cleaning — parsed from historical files and joined to results.
The method: I took each runner's Betfair SP, bucketed by implied probability band, and compared the implied win rate against the actual win rate in each band. Clean, simple, and it answers the claim directly.
What I found: the SP was strikingly well calibrated overall. Short-priced favourites (implied ~50%+) won at close to their implied rate — no obvious "favourite-longshot" edge to exploit there. The mild, well-documented bias showed at the extremes: the very longest shots (implied <3%) won slightly less often than their price implied — consistent with the classic longshot bias — while the mid-band was essentially fair. Concretely, the implied vs actual gap in the mid bands was within roughly a percentage point; only the longest band showed a gap worth a second look.
The honest conclusion: the data killed the simple version of the claim. There was no free money in "back mid-priced runners" — the SP was too sharp. The only persistent signal was the well-known longshot bias, which is hard to monetise because those prices are volatile and the sample of winners is tiny. That is a useful negative result: it stopped me building a strategy on a belief the data did not support, which is exactly what historical analysis is for. Most of what the data tells you is "your idea doesn't work" — and hearing that on a laptop is far cheaper than hearing it from your bank balance.
A Sensible Starting Project
Don't try to boil the ocean. A great first project is small and self-contained: grab a few free daily price files for one sport, parse the price for each selection at a handful of fixed times before the off, join to results, and answer one concrete question — say, how the favourite's price moves in the final five minutes on average. You will hit the timestamp and join gotchas on a small scale where they are easy to debug, and you will come out with a real, measured fact and a reusable pipeline.
From there, scale gradually: more markets, more sports, then closing-line analysis of a strategy you actually use. Keep a research log exactly as you would a trading log — what you tested, on what data, and what you found — because the value compounds when you can trust your past results. The discipline of measuring honestly is the whole game; the Python is just plumbing.
Pair bulk history for analysis with the Betfair API for live data and execution. Start with the free recent price files to learn the format before paying for bulk history.
Betfair API Guide Open Betfair Account →An analysis that ignores realistic fills, commission, look-ahead bias or a bad results join will look profitable and lose money live. Data analysis reduces guessing; it does not guarantee an edge. Most traders lose money, and a strategy that worked historically can stop working. Validate honestly and remember past results do not guarantee future returns.
FAQ
Where can I download Betfair historical data?
Betfair runs an official historical data service that sells timestamped market price files going back years, in basic and advanced detail levels, with free recent price files also published. Third parties resell pre-processed datasets, but the official service is the authoritative source.
What is in a Betfair historical data file?
A stream of timestamped market updates: back and lay prices and sizes at each level, traded volume at each price, and the market definition (runners, start time, status). You reconstruct the market's life by replaying the update stream to any timestamp.
Do I need to code to analyse Betfair data?
For anything beyond a single market, yes. The files are large and stream-structured, so Python with pandas and Betfair's own historical-data tools is the practical route. See our data analysis guide.
What can you actually learn from Betfair historical data?
How prices move into the off, how reliably the SP predicts results, which markets are least efficient, how much liquidity sits at different times, and whether a strategy would have beaten the closing line. It is the foundation for backtesting and any quantitative edge.
Is using Betfair historical data allowed?
Yes — the official service exists precisely so traders and modellers can analyse markets, subject to its licensing terms. Read the terms for any restriction on redistribution; using it for your own research and model-building is its intended purpose.
Storing and Structuring Data So You Can Actually Use It
The part nobody mentions until it bites you is data management, and getting it wrong turns a promising research project into an unworkable mess of half-parsed files. The raw historical files are stream-structured and large, so the worst thing you can do is re-parse the raw stream every time you want to ask a question — you will spend more time waiting on parsing than thinking about results. The pattern that works is a two-stage pipeline: parse once into time-sliced snapshots (the price and available size for each runner at, say, 60, 30, 10, 5 and 1 minutes before the off, plus the in-play turn and the SP), and store those tidy snapshots separately from the raw files you keep as the source of truth.
For a few thousand markets, parsed snapshots fit comfortably in memory and a folder of Parquet or CSV files is plenty. As you scale to seasons across multiple sports, move the snapshots into a lightweight database (SQLite is enough to start; a columnar store if you go large) so you can query across markets without reloading everything. The principle is the same one good engineers use everywhere: keep the expensive transformation (parsing the stream) separate from the cheap, repeated work (querying snapshots), so that asking a new question costs seconds, not hours.
Two habits save you the most pain. First, version your parsing logic and record which version produced which snapshot table — when you fix a timestamp or in-play bug (and you will), you need to know which past analyses are now suspect. Second, keep a data dictionary: a short note of exactly what each column means, which timestamp each snapshot represents, and how the results join was done. It feels like bureaucracy until the day you return to a six-month-old analysis and cannot remember whether "price_10m" was the back, the lay or the last traded. Treat the data pipeline with the same discipline you would a trade log, and the analysis stays trustworthy as it grows — which is the entire point of doing it on a computer instead of guessing, the theme our data analysis guide returns to throughout.
Related Reading
Stay in the cluster: advanced strategies pillar, machine learning for Betfair, software automation. Foundations: data analysis guide, the Betfair API, building Betfair bots, market analysis techniques.