KEY TAKEAWAYS
A live bet, also called an in-play bet, is placed while the game is under way. A sportsbook cannot treat it like a bet placed days ahead, because the situation can change between the moment a player taps the button and the moment the system receives the request. A goal, a foul or an injury can alter the fair price in seconds, so the software has to decide, quickly and consistently, whether to accept each bet at the price on screen.
Several systems cooperate to make that decision: a data feed that reports what is happening in the event, a pricing system that turns that information into odds, an acceptance check that tests each incoming bet, an account system that moves the money, and monitoring that watches for irregular activity. GLI-33, a technical standard for event wagering systems published by Gaming Laboratories International, sets out requirements for many of these parts, and state regulators add their own rules.
This guide follows one live bet through the system, explains why delays exist, shows the arithmetic behind a delay and a price, compares bet types, and separates myths from what the technology does. It offers no picks.
How a Live Bet Moves Through the System
It helps to follow the path in order. First, event data comes in: scores, game status and other facts reach the sportsbook from a data source. Regulators set conditions here. Massachusetts rules, for example, require a data source used for settling wagers to be complete, accurate, reliable, timely and available.
Second, a pricing system turns the data into odds, often using statistical models, with human traders able to adjust them. Third, prices are pushed to apps, which show them to players. GLI-33 version 1.1 says the current odds and prices must be shown as accurately as possible within the constraints of communication delays and latencies.
Fourth, when a player submits a bet, the request travels to the server. There the system checks that the player’s account can cover the wager, that the market is open and that the price has not changed. GLI-33 says an account balance must not go negative, the balance is debited when the wager is accepted, and the player must be clearly told whether the bet was accepted or rejected, in full or in part.
Finally, the system records the wager and later settles it from the result data. Throughout, operators must be able to suspend activity: GLI-33 requires the system to suspend all wagering, individual events, individual markets, individual devices or individual player logins on demand.
Under the Hood: Delay, Price and Suspension
Two small calculations explain much of live betting. The first is the time a bet takes to be accepted:
where network latency is the travel time between the app and the server, processing time is how long the checks take, and the intentional delay is any hold the operator adds. With fictional figures of 120 milliseconds, 80 milliseconds and 5 seconds, the total is 0.12 + 0.08 + 5 = 5.2 seconds. GLI-33 expects an operator’s published rules to tell players that delays may be built into the registered time of an in-play wager to prevent past-post wagers and cancellations, and that updates on screen may leave a player at a disadvantage to others with more current information.
The second calculation is the price itself. In decimal odds, the probability implied by a price is one divided by the odds:
For a fictional two-way market priced at 1.91 on each side, each side implies 1 ÷ 1.91 ≈ 52.36%, and the two together come to about 104.71%. The extra 4.71% is the margin built into these fictional prices, which is how a price can differ from the bare probability of an outcome.
Suspension and logging complete the picture. GLI-33 expects procedures for suspending markets or events, with an audit-log entry showing the date, time and reason, and records of any loss of contact with statistics or line services, kept for 90 days or as the regulator specifies.
Walkthrough: One Hypothetical Live Bet
This is a fictional, simplified example; delay lengths, checks and wording vary by supplier and state. Suppose a player sees a price on a basketball market and taps to bet.
- Tap: the app sends the request with the selection and the price on screen.
- Travel: the request reaches the server after 120 milliseconds.
- Hold: in this fictional system a 5-second in-play delay applies, and processing takes 80 milliseconds, so the bet is evaluated at about 5.2 seconds.
- Meanwhile: the data feed reports an injury at 3 seconds, and a trader suspends the market.
- Check: at 5.2 seconds the server sees the market is closed and rejects the bet.
- Response: the app tells the player the bet was rejected. No money has been debited, because the debit happens only when a wager is accepted.
- Record: the suspension and the rejected request are logged, so the sequence can be reviewed later if the player contacts support.
Had the market stayed open but the price moved, the system would instead have shown the new price and asked the player to confirm.
Variations: Pre-Game, In-Play and Pool-Based Bets
Not every wager takes the same path. The table summarizes general differences, which vary by state and supplier.
| Feature | Pre-game fixed-odds | In-play fixed-odds | Pool-based (pari-mutuel) |
|---|---|---|---|
| Price | Locked in when the bet is accepted | Locked in when accepted, but moves quickly beforehand | Dividends are calculated from the pool under published rules |
| Timing risk | Low, the event has not started | High, so delays and suspensions are common | Wagering periods close before results |
| Data needs | Mainly the final result | Fast, frequent updates | Results and pool totals |
Data rules also differ between bet types. Illinois law, for example, defines a tier 1 wager as one determined solely by the final score or outcome and placed before the event begins, and a tier 2 wager as any other. Operators may use any data source for tier 1 results, while for tier 2 results they must use official league data once the relevant sports governing body notifies the regulator, with exceptions such as no feed being available on commercially reasonable terms. Massachusetts regulations set a similar framework.
Virtual events are another variation: their results come from a random number generator rather than a real match, as covered in GamingTechNow’s RNG guide.
Myths, Limits and Misconceptions
Myth: the price on screen is a live, exact feed. The standard itself acknowledges communication delays and latencies, which is why the price is checked again when a bet arrives.
Myth: a bet delay is a trick. The standard describes delays as a way to prevent past-post wagers, meaning bets placed after the outcome is already known, and it expects the operator’s rules to disclose them. Whether and how long a delay applies varies by sport, supplier and state.
Myth: if the price moved, the bet was lost. The system must identify the change and ask the player to confirm, unless the player has opted in to auto-accept, which cannot be on by default.
Myth: pricing models know what will happen. A model estimates probabilities from data; it cannot predict a specific result, and no pricing system or tool can guarantee outcomes.
Limits apply: public standards set minimums, and how fast a particular system reacts depends on its design, its data source and the player’s connection.
Key Facts and What a Player Can Do
The essentials, with steps a player can legitimately take:
| Topic | What to know |
|---|---|
| Acceptance | A bet is accepted only if the balance covers it, the market is open and the price check passes |
| Rejection | The player must be told if a bet is rejected, in full or in part |
| Price change | The player is asked to confirm unless auto-accept was chosen |
| Suspensions | Operators must be able to suspend markets, events or all wagering and log it |
| Delays | Short in-play delays may be applied, and the rules should explain them |
A player can read the in-app rules for in-play wagering, check the bet slip for the accepted price before leaving the screen, and contact the operator’s support if a bet’s status is unclear. Rules differ by state and by operator, and the app’s published rules govern each case.
Related Concepts and Next Steps
For the wider system that holds accounts, wallets and game content, read how an online gambling platform works behind the screen. For another case where a server, not the app, enforces every rule and decides the outcome, see how online poker software deals a hand. For the randomness used in virtual events, read how casino RNGs work.
Natural next topics include how cash-out values are calculated, how same-game parlay pricing handles related outcomes, and how integrity monitoring flags unusual betting patterns in general terms. Readers who want to understand how location checks fit into a mobile bet can also follow how geolocation works in gambling apps, and how operators keep a record of every wager for audit and dispute review.
Frequently Asked Questions
Sources & References
- Gaming Laboratories International — GLI-33: Standards for Event Wagering Systems, Version 1.1 (revision date May 14, 2019)
- Massachusetts Gaming Commission — 205 CMR 247: Uniform Standards of Sports Wagering (effective September 1, 2023)
- Illinois General Assembly — Sports Wagering Act, 230 ILCS 45, Article 25
