Match-fixing detection: AI analysis of odds and bets

Match-fixing detection: where manual analysis breaks

Match-fixing detection is limited not by a lack of data but by when the analyst sees it. Abnormal line movement is recorded after the fact — after bet settlement, when odds have been rewritten and suspicious bets have been closed with a payout.

By then, the only available artifact is historical exports, and all work turns into a retrospective reconstruction of the event.

The cause is not analyst skill but the fact that sources do not reconcile with each other. Exports from different systems diverge in time: in one, event time is given without adjusting for publication delay; in another, it is bet acceptance time rather than placement time.

Field schemas also differ, so manual review of exports begins with joining tables rather than searching for signals.

Data completeness completes the picture: some markets are provided truncated, some lines close before they reach the report. The analyst sees odds movement but not who created it — one player, a group of linked accounts, or the market's reaction to news. Testing a hypothesis on such a sample either does not add up or takes days.

Hence the reaction lag, which is the main cost of the manual loop: by the time the picture is assembled, the match has been played and it is too late to decide on the incident.

To break this link, you need a continuous stream of bets on a single timeline and features calculated automatically rather than reconstructed retroactively. Below we examine how this is addressed.

What automated analysis of matches and lines provides

Early warning instead of post-event review

The model compares the current line with the expected trajectory for each market and records deviation when it appears, not after event settlement.

The signal arrives hours before the start — while limits are not removed and there is time to ask the operator for explanations, suspend betting, or initiate manual review.

This changes the very logic of the service: reaction time drops from days to minutes, and the share of anomalies found before the event becomes the main one. Post-event review remains only for complex cases requiring human expertise.

A unified risk scale across all tournaments and markets

Each event is assigned a risk score on one scale — from low to high, regardless of tournament, sport, or market type: outcome, totals, handicaps, statistics bets.

This allows signals to be compared with each other and maintains one escalation threshold instead of a dozen local rules for each championship.

Coverage grows to tens of thousands of events per month, and false positives fall severalfold: the threshold is calibrated on confirmed historical cases rather than set intuitively.

The analyst receives not a stream of "suspicious matches" but a ranked list with an explanation — which market, at what point, and how much it deviated from expected behavior.

Analysis modes: batch processing, streaming, manual sampling

Different tasks require different modes: reviewing an archive for past seasons and catching an anomaly at the moment a bet is accepted are two different loops. Below is how they differ in latency, data completeness, and method limitations.

Historical export review

Batch processing runs on historical exports: odds, volumes, and line movement across all bookmakers for a period.

The model sees the closed picture as a whole, so it recalculates relationships between markets retroactively and finds coordinated shifts that are not visible in real time.

Streaming line monitoring at bet acceptance time

Streaming analysis computes on a short window: recalculation on every odds change and comparison with the expected profile. The signal arrives while bets are being accepted, but the narrow window produces more false positives on a thin market. Hybrid mode combines both loops: fast signal plus clarifying recalculation after the match.

How implementation is built: from data audit to rule handover

Developing a match-fixing detector is not model training but a reproducible loop: from raw odds and bets to the rules by which an analyst makes a decision. Each iteration ends with an artifact that can be validated on historical data.

Source and data quality audit

First we check the suitability of history: continuity of odds across lines, publication delays, discrepancies between sources, completeness of labeling for closed cases.

Gaps and shifted timestamps generate false anomalies more than model error, so we filter out some sources immediately.

Threshold and escalation rule alignment

The trigger threshold is a trade-off between missed cases and a stream of false signals for manual review. We select it using a curve on historical episodes and fix escalation: what goes to the analyst immediately and what accumulates in a report.

1. Source audit: completeness, update frequency, and consistency of odds and bets.
2. Feature schema: line movement before the match, deviation from expected range, anomalies in volumes.
3. Model assembly on historical episodes with known outcome.
4. Threshold calibration for an acceptable false-positive rate.
5. Historical validation: closed cases and a control sample of "clean" matches.
6. Rule handover and team training: feature documentation, review of disputed cases, retraining procedure.

What the client keeps: rules, labeling, policies

The system can be transferred along with model weights — and in a quarter you get a non-working black box that no one knows how to tune.

That is why we hand over a package with which your team independently reviews disputed signals, changes rules, and responds to regulator requests without our involvement.

Documentation package and feature description

Documentation describes not "how we did it" but "how to maintain it": where data comes from, what is considered an anomaly and why.

The key document is the feature description with an interpretation of each: sharp line movement against expected, synchronized bets on an unlikely outcome, abnormal volume in a narrow time window.

• Feature description with examples of triggers and analysis of false ones.
• Threshold rules: which values trigger a signal and how to change them without retraining.
• Historical data labeling — a reference sample for validating new versions of rules.
• Roles and access rights: who sees raw bets, who sees only aggregates.
• Escalation policy: signal levels and response time for each.
• Instructions for the monitoring service: what to do in the first hours after a trigger.
• Change log of rules with justification for each edit.

Escalation and incident review policy

Here we fix the signal path: automatic alert, duty officer review, review with context export, decision on the match. Separately, we describe how to document disputed cases so that accumulated labeling returns to the model and improves the accuracy of future versions.

Case study: divergence of line and bet volume before and after

Project — a betting operator on lower-tier football leagues.

Odds and bet volumes came from the data stream of provider Betradar, and the monitoring service worked manually: inspectors exported odds snapshots into tables and compared line movement with market turnover after the final whistle.

How it was — manual exports and post-event review

Export ran once a day, so an anomaly such as a drop in odds with growing bet volume on the underdog surfaced a day or two later, when the market had already been settled.

Review relied on inspector experience: deviations within a few percent from the expected model he did not notice at all, and a disputed episode had to be manually rechecked in logs — hours per match.

How it became — a unified list of suspicious events with risk scores

We brought odds and bets into one loop: the model calculates expected line movement, compares it with actual, and assigns the episode a risk score — from low to critical.

The inspector opens a list sorted by this score and sees context: magnitude of deviation, time to goal, nature of money movement.

Reaction time dropped from days to minutes — during the match. The share of anomalies detected increased about threefold, manual workload fell by two-thirds. A whole class of failures disappeared, where a suspicious event was found only after bet settlement.

How does streaming analysis differ from export review?

Streaming analysis reads odds and bets as an event stream: each quote and bet acceptance is a separate message, features are calculated on a sliding window. Reaction latency is seconds and minutes, so a line anomaly is visible while the market is still open and can be suspended.

Export review is structured differently: a file arrives per shift or per day, the report is assembled in batch, reaction takes hours.

Data quality requirements differ fundamentally. Streaming is critical for completeness and order: a missed packet breaks the time series; deduplication, timestamp reconciliation, and a buffer for late messages are needed.

Exports are tolerant of gaps — they can be recalculated again — but they will not show in-play line dynamics, only final values by market.

Incomplete and late data are handled differently. If source lag exceeds the window width, the streaming detector either stays silent or produces a false signal, so latency is monitored per source along with a data staleness marker. In batch mode, a late batch only shifts the report boundary and does not break the calculation.

Mode choice sets the volume of the bet stream. Dozens of matches per day and targeted checks are handled by exports; thousands of events per minute across several markets — only streaming, otherwise the line is settled before a signal appears.

More often a hybrid is chosen: streaming provides early warning, exports provide the evidence base for review. Industry organizations such as IBIA build their reports specifically on post-processing.

Concerns about data, labeling, and trigger thresholds

Five questions engineers ask at almost every meeting — and they are right. We answer without promises: where we hit data limitations and what we do instead of the perfect scenario.

There are no labels — who will confirm that a match is fixed?

Clean labels do not exist in this field for anyone: some cases are not officially confirmed. We collect two layers of labels — expert ones from analysts and weak ones from indirect signals. We train on agreement of the layers and send discrepancies to manual review.

Will there be a spike in false positives at launch?

There will be if the threshold is lowered immediately. That is why launch runs in observation mode: signals accumulate but block nothing, and thresholds are calibrated by the share of confirmed cases. After several cycles, the stream falls to dozens of signals per week.

Data from closed operators — how will you get it?

Where there is no operator line, we work with exchanges, public odds, and odds movement, plus the client's internal data: orders, limits, settlement history. If a source is fundamentally unavailable, we say directly which hypotheses we will not be able to test.

We already have monitoring running — will it have to be changed?

No. Detection connects alongside: it takes the same exports and sends signals to the familiar queue. For the first period it runs in parallel with the existing system — we compare where current rules miss anomalies and where our module is noisy.

Let's discuss your task and come back with an estimate and plan

The accuracy of match-fixing detection depends on data no less than on algorithms, so work starts with inputs.

The more complete the odds export and the more accurate the labeling of known incidents, the lower the false-positive rate and the faster the system reaches operating mode.

• Period and markets: export of odds and bet volumes for an agreed interval, plus known clean matches as a reference sample.
• Client bets: account aggregates with timestamps — the main signal comes from here, and the line confirms it.
• Incident labeling: a list of matches with a confirmed fixed nature; on it we test sensitivity and robustness.
• Policy: rules on markets, limits, and refunds to separate an anomaly from a legitimate line correction.
• Access: export from the platform or its API, a test environment, and a security service contact.
• Processing scope: how we handle personal data and who exactly receives alerts on triggers.

In response, we send an estimate and work plan: stages, data preparation scheme, a set of quality metrics, checkpoints, and report format — a list of matches with a confidence level and an indication of which features triggered.

Describe your task and state what from the list you already have — we will come back with an estimate and plan showing which hypotheses we test, on what sample, and at what trigger threshold.