How live betting works: from the event on the field to sportsbook settlement

A live market looks simple: odds change during the match, the user selects an outcome and submits a bet. Between an event on the field and confirmation of that bet, however, sits an entire chain of systems. Each one must receive information, validate it, recalculate markets and make a decision.

It is not enough for a sportsbook to learn quickly that a goal was scored. It must confirm that the event actually happened, update dozens of connected markets, check incoming bets and avoid accepting them at a price calculated for a state of play that is no longer current.

That is why an odd displayed on screen is not yet a final offer. In live betting, the moment a user sees a price, the moment the bet is submitted and the moment it is actually accepted are three different points in time.

The sportsbook’s task: maintaining the current state of the market

During a match, the state of a market changes almost continuously. Prices respond not only to goals, points or completed sets, but also to time remaining, dismissals, injuries, substitutions, possession and other match events.

One event usually affects several markets at once. A goal in a football match may change the odds for:

• the match winner;
• double chance;
• handicaps;
• match and team totals;
• correct score;
• the next goal;
• the half-time result;
• individual player markets.

Those prices must change consistently. Updating the main result while leaving related totals or handicaps unchanged would create logical contradictions between markets.

The challenge is not only the speed of recalculation. The system must assess how reliable the incoming data is and whether the event might be reversed a few seconds later. A goal can be disallowed for offside, an awarded point can be corrected, and the initially recorded outcome of a play can be reviewed.

The sportsbook therefore constantly balances two risks: keeping a market closed for too long or reopening it before the new match state has been confirmed.

Where the sportsbook gets match information

The live line is usually powered by a specialised sports-data feed. It may come from the league itself, an official rights holder or an independent company collecting information directly during the event.

One traditional method is an in-venue scout. This specialist attends the match and uses a dedicated application to record important events: kick-off, goals, cards, substitutions, serves, points, stoppages and restarts.

The scout is not writing a free-form description. The interface and workflow are designed in advance for a particular sport. The scout selects standardised events, and the system immediately sends them to a data-processing centre.

Major suppliers employ thousands of such specialists. Sportradar says it has a network of 12,600 scouts, while Stats Perform says more than 1,500 specialists work within its RunningBall network. RunningBall claims that data can be delivered from the venue in under one second. These are the suppliers’ own figures, but they demonstrate the scale of the infrastructure behind a live market.

Sportradar Live Data

RunningBall Ultrafast Data by Stats Perform

At competitions with official collection systems, data may come directly from officiating equipment, scoreboards, tracking systems or representatives of the organiser. Computer vision and automated event recognition are also used.

Human involvement does not always disappear. Automation may identify player positions or ball movement quickly, but disputed and ambiguous events can still require verification.

Why the broadcast may be behind

The user and the sportsbook do not necessarily see the match at the same time.

A television or internet broadcast passes through signal production, encoding, distribution, a content delivery network and the viewer’s device. Every stage adds latency. Even two viewers using the same service may see the same incident at different times.

An in-venue data feed can reach the sportsbook before the moment appears on the user’s screen. The opposite can also occur: another broadcast or information source may be faster than the sportsbook’s particular data channel.

Therefore, “I have not seen the goal on the stream yet” does not mean the sportsbook does not know about it. Conversely, seeing an event does not guarantee that every system at the operator has already received and processed it.

This is one of the main reasons sportsbooks temporarily suspend markets around potentially important incidents.

What happens to the data after the stadium

An event message is not sent directly to the user’s browser. It passes through several layers of processing.

A simplified chain looks like this:

event on the field → data collection → validation and normalisation → pricing model → risk management → sportsbook platform → user interface

First, the supplier converts the event into a common format. Team names, player names, periods and event types can differ between competitions and sources. The system must associate the update with the correct match and establish the order of events.

Automated checks follow. An event should not conflict with the current score or the sequence of periods. Critical updates may be checked against several sources or require additional confirmation from an operator.

The data then reaches the model that recalculates probabilities.

How live odds are recalculated

Before the match, the sportsbook already has an initial assessment of the teams’ strength and the probabilities of different outcomes. During play, that assessment is continuously updated to reflect the actual state of the event.

In simplified terms, the model may consider:

• the current score;
• time remaining;
• home advantage;
• dismissals and numerical advantage;
• possession or service;
• the current period, set or quarter;
• available match statistics;
• the participants’ initial strength.

The exact inputs depend on the sport and market. In tennis, serve and the score within a game are crucial. In basketball, the score margin, time and possession matter. In football, the score, time remaining and red cards are central.

The model converts the new state into probabilities, after which the sportsbook adds its margin and produces prices.

An automated model does not always make the final decision. An operator may use a ready-made external odds feed, its own trading team, or a combination of both. Traders monitor unusual situations, adjust parameters and can close individual markets manually.

Why the market is repeatedly suspended

The betting button often disappears precisely when a match becomes most interesting. This is not necessarily a platform error.

A sportsbook may suspend a market:

• before a dangerous set piece;
• during a penalty or video review;
• after a goal;
• following a dismissal;
• during a medical stoppage;
• when contact with the data source is lost;
• when sources conflict;
• when a sudden wave of bets arrives;
• shortly before the end of a period or match.

A temporary suspension gives the sportsbook time to confirm the event and recalculate related markets. Without it, the operator could accept bets at a price that no longer reflects the actual match state.

At the same time, keeping markets closed for too long is commercially unattractive. No bets can be taken while a market is unavailable. The quality of a live product is therefore determined not only by the speed of its odds but also by the proportion of time markets remain open.

The result is a constant compromise: maximum market availability at an acceptable level of information and financial risk.

Why the price on screen is not a guarantee

The interface shows the latest price it has received. The match continues to develop after that price appears.

When the user presses the button, the request travels back to the sportsbook. The platform must check again:

• whether the market is open;
• whether the selected price is still valid;
• whether the match state has changed;
• whether the account has sufficient balance;
• whether the limit has been exceeded;
• whether that bet is permitted for the account;
• whether there is a related or conflicting request;
• whether the requested stake can be accepted.

Only after these checks is there a final outcome: the bet is accepted, the price changes, the stake is restricted, the market closes, or the request is rejected.

A live price is therefore better understood not as a guaranteed offer but as the latest available quote, which the system will validate again at execution.

It resembles a fast-moving market: information about a price and the actual execution of a transaction are not the same thing.

Where latency accumulates

Discussion of live-betting speed is often reduced to API latency. The API, however, is only one section of a much longer route.

Latency can arise at several stages:

1. Event capture. A scout or system must recognise what happened and send an update.
2. Data delivery. The message passes through the supplier’s network and infrastructure.
3. Validation. The system normalises the data and verifies its sequence.
4. Model recalculation. The new match state is converted into probabilities and odds.
5. Risk management. The platform decides which markets to open, which limits to apply and whether manual review is needed.
6. Price publication. The update moves through internal services, message queues, caches and sportsbook APIs.
7. Delivery to the user. The value crosses the internet and is rendered by the application or browser.
8. Bet submission. The request makes the return journey.
9. Final validation and confirmation. The sportsbook checks the price and market state once more.

Each stage may take very little time, but total latency is the sum of the entire chain.

A claim about a fast data feed or API therefore does not reveal how much time passes between an event on the field and an accepted bet. A meaningful assessment requires end-to-end latency: the full interval from the event occurring to the final response received by the user.

How odds are updated in the browser

Once a new price has been published inside the sportsbook platform, it still has to reach the user’s browser or mobile app. This is usually done through one of two approaches: periodic polling or a persistent streaming connection.

With polling, the browser requests the current market state at fixed intervals. If the price changes just after a request, the user will not see the new value until the next one. Shorter intervals produce fresher interfaces but increase the number of requests the server must handle.

With streaming, the browser creates a persistent connection, for example through WebSocket. The server can then send updates as they happen: a new price, a market suspension, a change in available limit or the result of a submitted bet. The browser does not have to ask repeatedly whether anything has changed.

In practice, a platform may combine both methods. Streaming is used for fast-moving prices and market states, while ordinary requests handle the initial page load, balances, betting history or restoration after a connection is interrupted.

Even WebSocket does not make an update instantaneous. A message still passes through the sportsbook’s servers, delivery infrastructure, the user’s internet connection and interface code. An overloaded tab, a slow device or a temporary disconnection can make the browser display a price later than it appeared inside the platform.

How external applications receive data

A separate layer is the API used by third-party applications, trading interfaces and automated systems to obtain sportsbook or exchange data.

A conventional API can also rely on periodic requests: the client asks for a list of markets and receives their state at the time of the response. For frequently changing live data, some platforms offer a dedicated streaming API that transmits only new changes and avoids repeatedly downloading the entire market state.

Betfair, for example, recommends that trading applications use its Stream API for price, market and order updates. A fast data stream, however, only means that the application learned about a change quickly. It does not guarantee that a bet submitted immediately afterwards will be accepted at the observed price: the request must still pass checks for current market state, available volume and execution rules.

Betfair application requirements

A streaming connection therefore reduces latency only in the delivery of a price that has already been calculated. It does not eliminate the time required to collect and validate data, run the model, manage risk and confirm the bet.

Why some latency is intentional

Not every delay is a technical problem.

On a betting exchange, users place orders against one another. After an important event, a participant with an unmatched offer in the order book needs an opportunity to cancel it before another user takes a price that is no longer current.

Betfair therefore applies betDelay to live orders. Depending on the market, the delay usually ranges from one to twelve seconds. It begins after an order is submitted and is intended to protect both sides of the market.

Betfair’s explanation of in-play order delays

A conventional sportsbook works differently because the operator is the other side of the bet. It may nevertheless apply confirmation time, additional checks or restrictions around important moments in the game.

Such a delay makes the experience feel less immediate, but it reduces the chance that a bet will be accepted at an obviously stale price.

Where live systems are vulnerable

A live platform depends on several external and internal components, so errors cannot be eliminated completely.

Problems may be caused by:

• lost contact with a scout or data supplier;
• an incorrectly recorded event;
• disagreement between two sources;
• a match or participant mapped incorrectly;
• a delay in a message queue;
• a model failure;
• inconsistent updates across related markets;
• overload during a popular event;
• stale cache data;
• temporary desynchronisation between the interface and server.

The existence of a weak point does not mean it can be exploited reliably. The sportsbook records when data was received, when a request was submitted and when a decision was made. Anomalous bets can be detected during execution or later review.

Operators’ rules also usually describe what happens after an obvious technical error, an incorrect price or a bet accepted after the market outcome was already known. Depending on the rules and circumstances, a bet may be recalculated, voided or sent for manual review.

Trying to benefit from brief desynchronisation therefore creates a separate risk: the displayed price may not survive final validation, while repeated behaviour can lead to account restrictions.

How sportsbooks protect the live line

Operators use several layers of protection to reduce risk.

Multiple data sources

Critical events may be confirmed through an additional feed, official statistics or an operator. This reduces the chance that an erroneous message is treated as final.

Automatic market suspension

The system stops accepting bets around a potentially significant event before it is fully confirmed.

Consistency across related markets

A score change must be reflected simultaneously in match results, totals, handicaps and derivative markets. They are therefore tied to a common match state.

Dynamic limits

The acceptable stake may depend on the sport, competition, market type, time remaining, data quality and behaviour of the market itself. The greater the uncertainty, the more cautiously the operator accepts risk.

Monitoring the flow of bets

A sudden series of requests in the same direction may indicate that the market has not yet incorporated new information. The system can temporarily reduce limits or suspend betting.

Logging

The platform stores the time of data updates, price changes, incoming requests and final decisions. This allows the sequence of events to be reconstructed during a dispute.

Manual trader oversight

Automation performs well in standard situations. A rare incident, an erroneous feed or unusual market behaviour may still require a human decision.

Speed and quality are not the same thing

The fastest source is not necessarily the best one.

An incorrect message delivered in a fraction of a second may cause more damage than a correct update received slightly later. Sports-data suppliers therefore sell not only speed but also accuracy, stability, official rights, redundancy and quality-control procedures.

A sportsbook evaluates a combination of characteristics rather than one latency number:

• how quickly an event arrives;
• how often the data is wrong;
• how quickly errors are corrected;
• how many events are covered;
• which in-match events are available;
• how stable the connection is;
• whether the data source can be verified;
• how easily state can be restored after a disconnection.

The more confidence a sportsbook has in its data, the longer it can keep live markets open and the less often it needs to suspend them.

What happens after the match ends

The final whistle does not always mean every bet can be settled immediately.

The system must receive a confirmed result and apply the rules of the particular market. The main result is usually straightforward, but individual statistics can be revised later.

Unusual situations also occur:

• the match is abandoned;
• the event is postponed;
• the organiser changes the result;
• a statistical value is corrected;
• a participant withdraws;
• part of the match is declared invalid;
• the official source has not yet published a final result.

In such cases, the sportsbook applies its settlement rules. Some markets may be settled, others refunded, and some left open until an official decision is available.

As with bet acceptance, the important result is not only the one shown on the broadcast, but the one published by the source the operator recognises for settlement.

What the user ultimately receives

From the user’s perspective, a live bet takes only a few actions: open a match, select a price and confirm the stake. Inside the sportsbook, much more happens during that time.

Data is collected in the venue or through official infrastructure, validated, passed into a model, converted into prices, checked by risk controls, published to the interface and checked again after a bet is submitted.

Live betting therefore contains three distinct moments:

1. the user saw the price;
2. the user submitted the bet;
3. the sportsbook confirmed acceptance.

Only the third moment means that the bet has been accepted.

Weak points exist in this chain, as they do in any distributed real-time system. Market suspension, price revalidation, delays, limits and error-handling rules are built specifically around those risks.

A live line is not simply a table of odds following the score. It is a system for managing rapidly changing information and financial risk. Its quality is not defined by one attractive latency figure, but by how accurately, consistently and predictably it carries a bet through the entire journey, from the event on the field to final settlement.