Matched betting runs on one thing: a bookmaker back price paired with the current exchange lay price, with a rating and qualifying loss attached. This is the complete picture of that data layer, and how to ship it without building the matcher.
Matched betting runs on one thing. Each bookmaker back price is paired with the current exchange lay price for the same selection, with a rating and a qualifying loss attached. Kept fresh across many books, that single pairing is the whole data layer. Everything a matched-betting product shows a user, every oddsmatcher row and every offer, is built from it. This guide is the complete picture: the components, the feed types, and why the matching step is the part that decides whether you ship in an afternoon or build for months.
It is the matched back/lay pair, repeated for every selection across every book and refreshed continuously. A raw bookmaker price is not enough on its own. The opportunity a matched bettor acts on is a relationship between two numbers: the back price at the bookmaker and the lay price on an exchange. One number is a quote. Two numbers, paired and rated, are a signal. This is the difference between an odds list and an oddsmatcher dataset, and it is the line almost every build underestimates.
So the data layer is not really "odds". It is the matched row: a back price, the paired lay price, the implied position between them, and enough liquidity for the lay to be real. Hold that definition and the rest of this guide follows from it.
A matched row is assembled from six moving parts, and the value lives in getting all six right at once:
bet365 included as standard, with coverage expanding into the domestic South African and Nigerian books the big aggregators skip.rating number that ranks how good a pair is, so a scanner can sort thousands of rows by value without re-deriving the maths.qualifying_loss field, so a user sees the real cost of unlocking an offer before they place it.The rating and qualifying loss are not decoration. They are what let a front end render a sorted, decision-ready list instead of a wall of prices. We go deeper on both in qualifying loss and ratings, and the plain definition sits in the oddsmatcher definition.
Here is one selection, with the bookmaker back price paired to an exchange lay price and both derived fields attached. This is the illustrative shape, not live data:
{
"event": "Newcastle vs Brighton",
"market": "match_odds",
"selection": "Newcastle",
"back": { "bookmaker": "bet365", "odds": 2.05 },
"lay": { "exchange": "matchbook", "odds": 2.08, "liquidity": 1320 },
"rating": 98.6,
"qualifying_loss": -0.09
// ... region, feed_type and freshness fields elided
}Read it back against the components. The back block is one of 60+ books. The lay block is one of three exchanges, carrying its own liquidity. The rating and qualifying_loss are computed from the pair. A raw odds API can give you the back block alone. The lay pairing and the two derived fields are the work, and they are the product.
Different offers need different matched feeds, and a mature product carries several. The matching logic changes with the offer type, so each is its own feed rather than a flag on a single one:
Each of these is available as its own matched feed. Which ones you turn on depends on the offers your users chase, and you can start narrow and widen later. The point is that they share the same row shape, so adding a feed type is a scope change, not a rebuild.
Because the matcher is never finished, it is the part most teams underestimate. Pairing a bookmaker selection with the correct exchange selection sounds like a join. In practice it is a moving target: event and selection names differ between every book and every exchange, markets appear and disappear, and the mapping that worked last week drifts this week. On top of that sits a liquidity model, three separate exchange integrations, and a rating calculation, all of which have to stay correct as the surface underneath them changes.
The prices are the easy part. The matching, the exchange coverage, the freshness monitoring and the maintenance that follows every change are the other 80%, and that 80% never ends. A matcher is not a feature you complete. It is a process you run forever, which is exactly why building one is a commitment rather than a task.
It does the matching before you receive the data, so your product renders results on day one. With oddsmatcher-ready data, each row already carries the paired lay price, the rating and the qualifying loss. There is no matcher to build, no exchange integration to own, and no liquidity model to maintain. You read the docs, make one authenticated call, and your oddsmatcher shows sorted, decision-ready rows.
That is the trade. Build it yourself and you spend months on a matcher before your first usable row, then maintain it indefinitely. License oddsmatcher-ready data and you spend that time on your product instead. For most matched-betting platforms the maths points one way: the matcher is undifferentiated infrastructure, so owning it rarely pays.
| Build the matcher | License oddsmatcher-ready data | |
|---|---|---|
| Time to first matched row | Months | An afternoon |
| Exchange coverage | You integrate Betfair, Smarkets, Matchbook | Three exchanges, already paired |
| Ratings + qualifying loss | You build and tune the maths | Computed on every row |
| Ongoing maintenance | Yours, forever, as books and markets shift | The supplier's job |
| Your focus | Keeping a matcher alive | Your product |
Fresh enough that a user never acts on a price that has moved. For a live, consumer-facing matched-betting product, that is the bar: a stale row is worse than a missing one, because it looks usable and is not. Our honest posture is pre-match polling on roughly a few-second cycle, which suits pre-match matched betting well, where the durable value sits today.
Treat any vendor promising "real-time" prices without qualification with caution. We do not claim sub-second in-play streaming, because that is not what we ship. Freshness, uptime and the live book count are published on the coverage dashboard so the claim is checkable rather than asserted. Reliability is the buyer's first fear, so it should be a feature you can inspect, not a number you are asked to trust.
The data layer behind matched betting is the matched back/lay pair: a bookmaker back price, the current exchange lay price for the same selection, and a rating and qualifying loss on top, kept fresh across 60+ UK books with bet365 included and three exchanges for the lay side. Building the matcher that produces those rows is the hard, never-finished part. Oddsmatcher-ready data does it for you, so you ship the product instead of the plumbing. It powers a leading UK matched-betting platform today. You can see the coverage live on the coverage dashboard, and the fastest way to read real matched rows is a free trial.
Written by
Founder, OddsRelay
James is the founder of OddsRelay — the odds-data feed behind matched betting, arbitrage and odds-comparison products: 60+ UK bookmakers with bet365 included, matched against exchange lay prices and delivered as one clean, documented API. He writes here about how that data layer actually behaves — coverage, matching, freshness and the trade-offs — from the side that builds and runs it. The same feed powers a leading UK matched-betting platform today.
18+ · Data product for licensed operators. Please gamble responsibly.
Matched betting & oddsmatcher
An oddsmatcher finds the best back/lay pairs across books and exchanges. Here is the data behind it: each back price matched to an exchange lay price, with a rating that shows how close the two are.
· 6 min read
Matched betting & oddsmatcher
Oddsmatcher-ready data arrives already matched, with the exchange lay price, rating and qualifying loss attached, so you render rows instead of building a matcher. Here is exactly what the term removes from your build.
· 6 min read
Exchange & lay data
A bookmaker back price is only half of a matched bet. This is the other half: what exchange and lay coverage is, the three exchanges we match against, and why the paired lay decides the opportunity.
· 6 min read