How to build an oddsmatcher (and the part most teams buy)

An oddsmatcher is two layers, and only one of them is your product. The data layer collects bookmaker prices, matches each one back to the current exchange lay price, rates it, gates it by liquidity, and keeps the whole thing fresh. The product layer is the UI, the filters, the alerts, the accounts. Most teams build the product layer and license the data layer, because the data layer is the part that never finishes. This guide explains why that split is the right one, and where your engineering time actually pays off.

What does an oddsmatcher actually do?

An oddsmatcher finds qualifying bets and arbitrage by pairing a bookmaker back price with the matching exchange lay price, then ranking the results. A user opens it, filters to the books they have accounts with, and sees a sorted list of opportunities they can act on. Underneath that simple screen are two very different jobs.

• The data layer: get the back prices from 60+ books, pair each one with the current betfair, smarkets or matchbook lay price for the same selection, compute a rating and a qualifying_loss, drop anything without real liquidity, and keep every row current.
• The product layer: turn that stream of matched rows into a product people pay for, with filtering, sorting, alerts, account tracking, and a UI that earns trust.

The mistake is treating these as one project. They have different costs, different risks, and different ceilings. The data layer is a maintenance commitment with no end date. The product layer is where your name lives. We unpack what a feed has to deliver for that first layer in what oddsmatcher-ready data means.

Why is the data layer the hard part?

Because the data layer is never finished. Collecting a price once is easy. Keeping prices accurate, complete and fresh across 60+ UK books, with bet365 included, is a standing obligation that grows as you add coverage. Every book is a moving target, and the work does not stop when the first version ships.

Walk the obligations honestly, because each one is a system you would have to own:

• Breadth: 60+ bookmakers is the baseline UK matched bettors expect, with bet365 the one they check first and the one widely held to be the hardest to cover well.
• The exchange side: matching needs a live lay price, so you also run an integration to three exchanges (Betfair, Smarkets, Matchbook) and a liquidity model on top.
• The match itself: the same football match is named differently across books, so selections must be reconciled before any back price can be paired with a lay. That reconciliation is its own engine.
• Freshness: a stale price is worse than a missing one because it looks usable. Every row needs a freshness signal and a cycle that keeps it current.
• Drift: coverage that is whole in January quietly degrades by March as books change. Keeping it whole is continuous, not a one-off.

None of that is the visible product. It is plumbing that has to be perfect, runs forever, and that your users never see unless it breaks. This post does not cover how prices are collected, and that is deliberate: the collection method is not the interesting part of building an oddsmatcher, and it is not where you should spend your time.

What does the data layer output?

A finished data layer hands the product layer a stream of matched rows, each one ready to render. The row carries the back side, the paired lay side, and the maths that turns a price into an opportunity. Here is the shape of a single matched row (illustrative, not live data):

{
  "event": "Spurs vs Newcastle",
  "market": "match_odds",
  "selection": "Spurs",
  "back": { "bookmaker": "bet365", "odds": 2.38 },
  "lay":  { "exchange": "matchbook", "odds": 2.42, "liquidity": 1260 },
  "rating": 97.8,
  "qualifying_loss": -0.15
  // ... region, feed_type and freshness fields elided
}

The back/lay pairing, the rating and the qualifying_loss are the whole point. A raw price feed gives you the back block and stops. Everything your oddsmatcher screen renders, sorts and filters on comes from the fields a raw feed cannot produce. The full envelope, with every field, is in the API docs.

Where do you actually differentiate?

You differentiate in the product layer, not the data layer. Two oddsmatchers reading identical matched rows can feel completely different, and the better one wins on product, not on having marginally fresher prices. This is where your engineering time earns a return.

• Filtering and sorting: by book, by sport, by rating, by minimum liquidity, by the accounts a user actually holds. Good filtering is the difference between a list and a tool.
• Alerts: notify a user when a row crosses their threshold, so they don't sit refreshing a screen.
• Account and profit tracking: remember what a user has done, show progress, surface the next sensible bet.
• Onboarding and trust: a clear, honest UI that explains the qualifying_loss and the lay step turns a curious visitor into a subscriber.

Every hour you spend reconciling selection names or chasing a book that changed its surface is an hour not spent on the things above. The data layer has a ceiling: it can be correct, but it cannot be remarkable. The product layer is where remarkable lives.

How do you start with the product, not the matcher?

Route the build to an oddsmatcher-ready feed, so day one is the product layer and not the matcher. With a feed, your first authenticated call returns matched rows with back, lay, rating and qualifying_loss already populated. You render them, build your filters, and ship a real screen in an afternoon instead of building a collection pipeline and an exchange integration first.

This is not a claim that building is always wrong. If odds collection is your core product and your moat, owning it can make sense. For a team whose product is the oddsmatcher itself, the matcher is undifferentiated infrastructure, and licensing it is the faster, cheaper path. We work through that decision in full in buy versus build, and the wider context sits in the matched-betting data guide.

The short version

An oddsmatcher is a data layer and a product layer. The data layer matches 60+ books, bet365 included, against three exchanges (Betfair, Smarkets, Matchbook), rates each pair and keeps it fresh forever. The product layer is your UI, filters and alerts, and it is the layer where you actually differentiate. Build the second, license the first. OddsRelay supplies that data layer, and it powers a leading UK matched-betting platform today. You can see what is matched right now on the coverage dashboard, or point an oddsmatcher at the real thing with a free trial and spend day one on your product. The feed also backs other matched-betting platforms the same way.