Inside Chess Cheating Detection: Data, Signals and Models (Technical Guide)

Part 2: from “how platforms catch cheaters” to “how the signals work”

Our first article explained in plain terms how Chess.com, Lichess and over-the-board arbiters catch cheaters. This follow-up goes one level deeper: what data a platform actually receives during a game, which signals can be computed from it, how those signals can be combined, and why some cases stay hard.

Platforms keep their exact methods secret, so nobody outside can describe them precisely. This guide draws on what is public: the open-source Lichess models, Chess.com’s own statements, statistical research on over-the-board play, and an independent analysis of the traffic of a live Chess.com game by Ze3ter, published on Medium in October 2025. Where that analysis guesses at rules or thresholds, we say so.

What a live online game sends to the server

When you play online, your browser keeps a live connection open with the game server. Ze3ter’s analysis of Chess.com traffic describes a WebSocket connection to regional game servers. Each update of the game state carries the moves in a compact encoding, a clock value for every move, both players’ remaining time in milliseconds, timestamps and an indicator of each player’s connection quality. Alongside it, the page also polls the game state over HTTP about every half second.

The same analysis also shows a separate telemetry stream: batches of client events that include a persistent device identifier, the version of the site’s code, the screen size, the browser user agent and session identifiers. These are the kinds of data any large web application collects; the article does not show how, or whether, Chess.com uses them for fair play.

The practical consequence is simple. For every move the server knows what was played and how much clock time was used. For every session it knows something about the device. Everything else in cheating detection is computed from that.

Signal 1: move quality, measured against the rating

The core signal compares the moves with an engine’s. For each position, an engine ranks the candidate moves and gives an evaluation. Two numbers fall out naturally: how often the player picked one of the engine’s top moves (engine match rate, often counted on the top one or top three), and how much evaluation was lost on the other moves (average centipawn loss, or an accuracy score derived from it).

Those numbers mean nothing in isolation. Masters match the engine’s first choice very often, and so does anyone in a forced sequence of recaptures. What matters is the gap with the expected level: the same match rate is ordinary for a 2700 player and extraordinary for a 1200 player. Detection therefore compares each game, and above all each series of games, with the distribution of honest players of the same rating and time control.

Statistical research on over-the-board play, notably Ken Regan’s work with FIDE, goes further: it weights each move by the difficulty of the position, estimates the rating the moves correspond to, and turns the gap into a probability. The bigger the sample, the smaller the uncertainty, which is why a single brilliant game proves little and fifty of them can prove a lot.

Signal 2: accuracy where it matters, in critical positions

Most moves in a game are easy: recaptures, development, obvious threats. Cheaters who want to stay hidden often play those on their own and use help only at the decisive moment. Averages over the whole game dilute that pattern.

So systems look specifically at critical positions: moments where only one or two moves keep the evaluation, where the best move is not natural for a human (a quiet move, a long retreat, a sacrifice that only pays off much later), or where a mistake would swing the game. A player of modest rating who repeatedly finds the only move exactly there, while playing ordinary moves elsewhere, produces a much stronger signal than a high average accuracy.

Signal 3: time use

Because every move arrives with its clock value, a platform can reconstruct how long each decision took. Humans spend time unevenly: they move fast on obvious moves and think on hard ones, and they speed up when their clock runs low. Copying moves from another screen tends to flatten that pattern.

Useful timing features include the variance of thinking time, the time spent on complex moves compared with simple ones, and the share of instant replies in positions that should require thought. Ze3ter’s article sketches rules of this kind, for example comparing the time on complex and simple moves, or counting replies faster than two seconds. Those are the author’s illustrations with made-up thresholds, not Chess.com’s code, but they show the logic.

Timing is also where honest players produce false signals. Premoves, well-known opening lines and fast players all create instant replies, and bullet games leave almost no room for variation. That is why timing is a supporting signal, not a verdict.

Signal 4: the player’s own history

A player is the best reference for themselves. Comparing a game with the player’s recent games catches spikes: accuracy far above their usual level, a sudden run of wins against much stronger opponents, or a rating curve that climbs far faster than before. Ze3ter suggests comparing with the last 50 games and looking at consistency over 30 days; platforms do not publish their windows.

History also covers the account itself. Chess.com has said that nearly 40% of the accounts it closes are no more than two weeks old: a new account playing far above its starting rating is one of the clearest patterns. Juniors who improve quickly are the classic false positive here, which is one reason human review exists.

Combining signals into a decision

No platform bans on one number. Signals are combined, either by a model trained on confirmed cases or by a weighted score with review thresholds. Ze3ter proposes an illustrative weighting, not one used by any platform:

The idea that matters more than the exact weights is the rule that comes with them: flag an account for review only when at least two independent signals are strong. That keeps false positives down, because an honest player rarely looks inhuman on several unrelated measures at once.

Lichess publishes the machine learning side of this approach. Irwin, its first neural network, scores games for engine use; Kaladin, the newer model, works from the per-player statistics Lichess already computes. In both cases the model points moderators to accounts; humans confirm the hard cases. Chess.com says its system weighs over 100 factors and that most closures are automatic, for cases where the play or behaviour is clearly inhuman.

What human mistakes look like

Absence of mistakes is suspicious, but so is the wrong kind of mistake. Human errors cluster: under time pressure, in complex positions, after a long think, and in typical forms such as missed tactics or misjudged endgames. Engine-assisted play tends to show either no real mistakes or odd, random ones that do not match the position.

This is why the Ze3ter article suggests building a “human error profile” per rating band and measuring how far a player’s errors deviate from it. It is a research idea rather than a documented platform feature, but it captures what reviewers look at when they replay a suspicious game.

Where detection struggles

Every method has blind spots, and platforms openly treat these as ongoing work:

• Occasional help: a player who uses assistance on a handful of moves per game stays close to their normal level, so it takes many games to build evidence.
• Bullet and very fast games: there is little time data to work with and many moves are played on instinct or premove.
• Low ratings: honest play is noisy, so the expected range is wide and a moderate improvement is hard to separate from luck.
• Help that leaves no trace on the device, such as a second screen or another person, can only be caught through the moves and the timing.

The common answer to all of them is volume. Statistics on move quality accumulate over every game an account plays, and a player who cheats regularly cannot keep the pattern hidden forever. That is why bans often come weeks or months after the games.

False positives and why review matters

Any system that judges millions of games will flag some honest players: someone having the tournament of their life, a fast-improving junior, a strong player on a new account. Platforms reduce that risk by requiring several signals, by setting thresholds per rating and time control, and by sending borderline cases to human reviewers instead of closing them automatically.

For players, the lesson is the same as in part 1: an accuracy score or a single great game is not evidence. Report a suspicious game and let the platform, which sees far more data than any opponent, make the call.

Looking at your own games

You do not have access to a platform’s internal data, but you can see the outcome of its decisions. The ChessHunter cheater check looks up every opponent you played on Chess.com or Lichess, lists the accounts later closed for fair play or terms of service violations, and shows the rating recorded on those games and your rating curve without them.