In-play markets are betting markets that remain active after an event has started.
Unlike pre-match markets, where prices are primarily built around information available before kickoff, in-play markets continuously incorporate new information generated by the event itself.
Every goal, card, injury, substitution, possession change, shot, red card, and change in game state can alter the estimated probability of future outcomes.
This makes in-play markets fundamentally different from pre-match markets.
The market is no longer reacting only to external information.
It is reacting to the event as it happens.
Consider a football match beginning at:
15:00
Before kickoff, the market may estimate:
Once the match begins, those probabilities are no longer static.
At 20 minutes, the score may still be:
0-0
At 35 minutes, the home team receives a red card.
At 60 minutes, the away team scores.
At 75 minutes, the home team equalizes.
Each event changes the probability distribution.
Conceptually:
P(Result) = f(Score, Time, Players, Cards, Performance, Context)
The market continually updates this function.
In-play probability depends heavily on the amount of time remaining.
A 1-0 lead after:
10 minutes
is fundamentally different from a 1-0 lead after:
85 minutes
There are fewer opportunities for the trailing team to respond as the clock approaches full time.
Therefore, time becomes one of the most important variables in live probability estimation.
A simplified conceptual model might consider:
P(Home Win) = f(Score, Time Remaining)
Even if everything else remains unchanged, the probability can change simply because the clock continues running.
The current score is usually one of the strongest determinants of an in-play market.
Consider:
Scenario A
0-0 after 15 minutes.
Scenario B
1-0 after 15 minutes.
Scenario C
0-1 after 15 minutes.
These matches began with the same pre-match probabilities but have now entered three different states.
A model must therefore update its probability estimates whenever the score changes.
A goal can cause an immediate repricing.
Suppose before a goal:
P(Home Win) = 40%
The home team scores.
The probability might immediately rise because:
The exact change depends on:
The important point is that a goal is not simply another data point.
It changes the state of the match.
A red card can produce an even more complicated repricing.
Suppose the score is:
1-1
with 30 minutes remaining.
If the home team receives a red card, the market must incorporate:
The market therefore reacts not only to the numerical reduction from eleven players to ten.
It reacts to the consequences of that change.
A useful way to model an in-play event is to define its current state.
For example:
State = (Time, Score, Players, Cards, Possession, Game Context)
The market then estimates the probability of future outcomes given that state.
Conceptually:
P(Result | State)
This is fundamentally different from using only pre-match probabilities.
Expected goals can also be incorporated into live models.
Suppose a team had a pre-match expected-goals estimate of:
1.60
During the match, the team's observed attacking activity may suggest a different scoring rate.
A model can update its estimate based on information such as:
However, observed statistics should not automatically be interpreted as future scoring ability.
A team can record many shots without generating high-quality chances.
Therefore:
Shots ≠ Goals
and:
Possession ≠ Probability of Winning
The quality and context of the events matter.
In-play systems depend heavily on data speed and accuracy.
A live feed may contain:
Different data providers can have different levels of latency.
This creates a major technical issue:
«The market may receive information before your system does.»
A model cannot exploit information it has not yet received.
Suppose a goal occurs at:
72:15
Your data provider records it at:
72:17
while the market has already adjusted at:
72:16
Your system is now reacting to information that the market has already incorporated.
This is latency.
In-play analysis therefore requires measuring:
Latency = Market Event Time − Data Reception Time
where possible.
Even small delays can be important when prices are changing rapidly.
After major events, markets are often temporarily suspended.
Typical triggers include:
Suspension allows the operator or exchange to reassess the market before reopening prices.
This creates a natural sequence:
Event → Suspension → Repricing → Market Reopening
The reopening price represents the market's updated assessment of the new state.
In-play markets have a constant stream of new information.
The market is continuously processing:
New Information + Existing Probability → Updated Price
For example:
75:00
Home: 2.10
76:00
Large attacking sequence.
Home: 2.00
77:00
Red card.
Home: 3.20
78:00
Market reopens after suspension.
Home: 3.40
The price movement reflects changing expectations about the remainder of the match.
In-play markets also involve market microstructure.
Important concepts include:
Spread
Difference between available buying and selling prices.
Liquidity
Amount of money available at different prices.
Depth
How much capital is available behind the displayed price.
Suspension
Temporary removal of the market.
Repricing
Adjustment of prices following new information.
These characteristics affect how efficiently a market can be entered or exited.
| Feature | Pre-Match | In-Play |
|---|---|---|
| Event state | Future | Current |
| Information flow | Relatively slow | Continuous |
| Price movement | Periodic | Frequent |
| Latency importance | Moderate | High |
| Suspensions | Less frequent | Common |
| Data requirements | Historical + pre-match | Historical + real-time |
| Model complexity | Moderate | High |
| Execution sensitivity | Important | Extremely important |
The key difference is information velocity.
In-play markets compress large amounts of information into very short periods.
A basic live model might estimate:
P(Result | X_t)
where X_t contains the current match information.
A richer representation could be:
X_t = [Score, Time, HomeStrength, AwayStrength, RedCards, YellowCards, Shots, xG, Possession, Substitutions]
The model then produces updated probabilities continuously.
For example:
P(Home) = 48%
P(Draw) = 31%
P(Away) = 21%
A minute later, new information arrives and the probabilities are recalculated.
Poisson-based models can be adapted for live football analysis.
Suppose the remaining expected goals for the home team are:
λ_H = 0.45
and for the away team:
λ_A = 0.30
A model can use these expected scoring rates to estimate the probability distribution of remaining goals.
The crucial distinction is that these are remaining expected goals, not the team's full-match pre-match expectation.
The remaining scoring rate must account for:
Teams behave differently depending on the score.
A team losing 1-0 in the final 15 minutes may attack more aggressively.
A team winning 1-0 may become more defensive.
Therefore, the scoring process is not necessarily constant.
Conceptually:
λ = f(Score, Time, TeamStrength, TacticalState)
This is why naive models that assume constant scoring rates can perform poorly in live environments.
One of the most important concepts in in-play analysis is the difference between:
What happened
and:
How the market interpreted what happened.
Suppose Team A records three shots in five minutes.
The event itself is objective.
The market's reaction may depend on:
Therefore, an analyst should not simply ask:
«What happened?»
The more useful question is:
«How much should this event change the probability of the outcome?»
Suppose an event occurs at time t.
Record:
P_before
and:
P_after
Then calculate:
ΔP = P_after − P_before
Across thousands of historical events, you can investigate how markets typically respond to:
This turns live-market movement into a research dataset.
A potential discrepancy occurs when:
P_model ≠ P_market
For example:
P_model = 54%
while the normalized market probability is:
P_market = 50%
The difference is:
4%
But this is only a candidate discrepancy.
Before treating it as meaningful, the system should examine:
In-play markets can change faster than a model can respond.
In-play models face several additional challenges.
High-frequency data
Events arrive continuously.
Small time windows
The amount of time available for analysis can be extremely short.
Latency
Information may reach the system after the market has already reacted.
Non-stationarity
The characteristics of the game change as the match progresses.
Execution risk
Prices can disappear or change rapidly.
Data quality
Live feeds can contain delays, corrections, or missing events.
Consequently:
Live Model
is not simply:
PreMatch Model + Live Data
It requires its own architecture.
A robust system can follow this architecture:
Live Feed → Event Parser → State Engine → Probability Model → Market Comparison → Risk Engine
The event parser identifies what happened.
The state engine updates the current match state.
The probability model estimates future outcomes.
The market comparison layer compares those estimates with current prices.
The risk engine evaluates whether any action is appropriate.
This separation makes the system easier to test and debug.
The state engine maintains a continuously updated representation of the match.
For example:
Time: 67:42Score: 1-0Home players: 11Away players: 10Home xG: 1.42Away xG: 0.61Recent attacking intensity: HighMarket status: ActiveWhen a red card occurs:
Time: 68:05
Score: 1-0Home players: 11Away players: 9Home xG: 1.42Away xG: 0.61Recent attacking intensity: HighMarket status: SuspendedThe state changes immediately.
The model can then calculate a new probability distribution when the market becomes available again.
23. Historical Replay
One of the best ways to test an in-play model is to replay historical matches.
Instead of simply looking at the final result, reconstruct the match minute by minute.
At each timestamp:
- Load the current match state.
- Feed the information into the model.
- Generate probabilities.
- Compare them with historical market prices.
- Record the difference.
- Move to the next event.
This produces a historical simulation of the live market.
It is far more informative than simply comparing final match results.
24. Evaluating an In-Play Model
A model should be evaluated using:
Calibration
When the model predicts 60%, do approximately 60% of those events occur over a sufficiently large sample?
Log loss
Measures the quality of probabilistic predictions.
Brier score
Measures squared probability error.
Closing-line comparison
Examines how model estimates compare with later market prices.
Stability
Tests whether performance survives across:
- Competitions
- Seasons
- Match states
- Time periods
The objective is to determine whether the model is genuinely informative.
25. Common Mistakes
Mistake 1: Treating Every Live Statistic as Predictive
Possession and shot counts require context.
Mistake 2: Ignoring Time
The same event has different implications at different stages of a match.
Mistake 3: Ignoring Red Cards
Player imbalance can dramatically alter expected scoring rates.
Mistake 4: Ignoring Latency
A signal arriving after the market reacts is not an exploitable signal.
Mistake 5: Using Pre-Match Models Without Modification
The match state changes the underlying probability process.
Mistake 6: Assuming Market Movement Is Always Wrong
A market moving against your model may contain information your model does not capture.
Mistake 7: Ignoring Suspensions
Prices immediately before and after a major event may represent entirely different market states.
26. A Complete In-Play Analytical Workflow
A disciplined system can operate as follows:
Step 1: Initialize
Load pre-match probabilities and team information.
Step 2: Start the live feed
Receive real-time match events.
Step 3: Update the state
Modify score, time, players, cards, and other variables.
Step 4: Recalculate probability
Generate a new probability distribution.
Step 5: Monitor the market
Record current prices and market status.
Step 6: Measure discrepancy
Compare model probability with market probability.
Step 7: Validate
Check latency, liquidity, data quality, and recent events.
Step 8: Record
Store the state, model output, market price, and eventual result.
Step 9: Replay
Use historical matches to test whether the same process would have remained effective.
Step 10: Improve
Refine the model based on observed calibration and failure modes.
Key Takeaway
In-play markets are continuously evolving probability systems.
Every moment changes the information available to the market:
Match State → Updated Probability → Updated Price
The most important variables include:
Time → Score → Player State → Events → Performance → Market Reaction
But successful in-play analysis requires more than collecting live statistics. The system must understand the current state of the match, process information quickly, account for latency, distinguish meaningful events from noisy ones, and compare its probability estimates against an equally time-sensitive market.
The central lesson is this:
«An in-play market is not simply a pre-match market with a clock attached. It is a continuously updating information system whose underlying probability structure changes throughout the event.»
Understanding that distinction is the foundation for building reliable in-play models and evaluating whether apparent live-market discrepancies contain genuine information.