RTP Pillar·Chapter 6

Audits and ongoing monitoring

A certificate is a snapshot; the game runs for years. This chapter covers the assurance layer most players never see — periodic re-audit and live monitoring that compares a game’s actual realized return against its certified theoretical RTP, and what that monitoring can and cannot catch.

By Vadym Zelinskyiverified 2026-09-18Current · 100%

A laboratory certificate is dated. It attests that, on the day it was issued, a game’s model met the standard’s requirements. But the game then runs for years — across millions of real sessions, on live operator infrastructure the certificate never saw. The interesting question is not what happens at sign-off; it is what happens for the rest of the game’s life. That is the ongoing-assurance layer, and most players never see it.

Certification is a snapshot; the game runs for years

Once a game is certified, assurance shifts from a one-time test to two continuing activities: a periodic re-audit and live monitoring. GLI-19 is explicit that the initial evaluation is not the whole story — it makes an operational audit “an essential addition to the testing and certification of an Interactive Gaming System,” to be “performed at a frequency specified by the regulatory body.” In other words, the standard anticipates that the production environment — configurations, procedures, the live deployment — needs checking on a cadence, not just once. The certificate says the model was sound; the audit and the monitoring keep asking whether the running game still matches it.

What ongoing monitoring actually watches

The core of it is a comparison you can state in one line: the game’s actual, realized RTP against its certified theoretical RTP. GLI-19 requires that the operator “have procedures in place to periodically compare the theoretical and actual RTP percentage to identify, investigate, and resolve large variances between these two values.” A companion clause covers live output: the operator must monitor game and RNG output “on a defined periodic or volume basis,” whose purpose is “early detection of abnormal behavior,” and where “the actual RTP percentage for the period falling outside the expected range” results in “an error being logged and escalated for investigation.”

That comparison is only possible because the system meters the raw material continuously. For each game theme and pay table, GLI-19 requires the platform to maintain and back up — among other fields — the “Theoretical return to player (RTP) percentage,” “The number of games played,” the “Total value of all wagers,” and the “Total value paid as a result of winning wagers.” Realized RTP is simply total paid over total wagered, accumulated from those meters, and significant configuration changes are separately logged with their before-and-after values. One important honesty note: the standard does not define “large” with a number. There is no statistical threshold in the text — how far is too far, and over how many rounds, is left to the operator and regulator to set. The procedure is mandated; the exact band is not.

Regulator-side reporting duties

Some regimes do not merely require internal procedures — they require the theoretical-versus-actual picture to be filed. West Virginia is a clean, primary example already in this pillar’s dataset. Rather than imposing a hard RTP floor, its Interactive Wagering Rule (W. Va. Code R. §179-10, at §179-10-11.10) requires the system to generate a monthly Performance Report comparing each game’s theoretical RTP to its actual RTP. It is a disclosure-and-monitoring model in place of a minimum: the state watches the gap between design and reality on a monthly cadence instead of legislating the design number. Which jurisdictions choose floors, which choose reporting, and which choose both is the subject of RTP rules by jurisdiction.

What triggers a re-audit

A change to the game generally requires re-evaluation — and a change to its return specifically does. GLI-19 states that each change to a game’s theoretical RTP percentage “shall result in that game being treated as new for all reports and records.” That is the same logic that makes every build of a configurable-RTP title its own certified object: alter the maths and you are, for assurance purposes, looking at a new game. Crucially, this happens offline. Under the UK’s remote technical standards, RTS 7D provides that the rules, payouts and outcome probabilities of a game “may not be changed while it is available for gambling, except as provided for in the rules.” The maths a player faces is frozen while the game is live; a return change means a fresh, re-certified build, not a silent edit mid-session.

What monitoring can and cannot catch

It is worth being precise about the reach of all this, because the assurance is real but bounded. Monitoring can catch a game that has drifted from its certified model over a large sample, and a misconfigured deployment — the wrong build switched on, a pay table serving different maths than the one that was certified. Those are exactly the discrepancies the theoretical-versus-actual comparison exists to surface, and they are fixable once flagged.

Monitoring cannot make a session’s realized return match the published RTP. That gap is ordinary variance, not a fault, and no monitoring regime narrows it. Nor does monitoring shorten the sample needed to observe the long-run figure: confirming a return empirically still takes the tens of millions of spins that how RTP is verified and its calculator make concrete. The honest summary is narrow and worth stating plainly: this layer protects the integrity of the certified maths — that the running game is the game that was signed off — and nothing more. It does not tilt a session in your favour, and it does not change the fact that, over enough play, the expected value for the player is negative.

Common questions

Does anyone check a slot after it has been certified?

Yes. Certification is a one-time snapshot of the game’s model, but assurance continues over the game’s life through a periodic operational audit and ongoing monitoring. GLI-19 requires operators to keep procedures that periodically compare each game’s theoretical and actual RTP to identify, investigate and resolve large variances, and to monitor game and RNG output on a periodic or volume basis so that abnormal behaviour is detected and escalated. Some regulators go further and require reports: West Virginia, for example, mandates a monthly theoretical-versus-actual RTP report.

What happens if a game’s realized return drifts from its certified figure?

Under GLI-19’s monitoring procedures, an actual RTP for the period that falls outside the expected range is logged as an error and escalated for investigation. Two things matter here. First, a short run of play diverging from the certified number is ordinary statistical variance, not drift — pinning a return to a tenth of a percent takes tens of millions of spins. Second, a genuine, sustained divergence over a large sample is exactly what the comparison is designed to surface, so it can be traced to a misconfiguration or a fault and fixed.

If a studio changes a game, does it have to be re-certified?

A change that affects the maths generally does. GLI-19 states that each change to a game’s theoretical RTP percentage “shall result in that game being treated as new for all reports and records,” which is the trigger for re-evaluation — the same logic that makes every configuration of a configurable-RTP title a separate certified build. And under UK rules (RTS 7D) the rules, payouts and outcome probabilities may not be changed while the game is live to players; changes happen offline, not silently mid-session.

Does monitoring make my session return match the advertised RTP?

No. Monitoring protects the integrity of the certified maths — it checks that the deployed game behaves like the model it was signed off against. It does nothing to your individual session. Over a session the realized return almost never equals the published RTP (that is variance), and no amount of monitoring shortens the enormous sample needed to observe the long-run figure. Monitoring does not change the fact that, over enough play, the expected value for the player is negative.

Sources (4)

Education, not advice. This chapter explains how return-to-player is defined, computed and checked so you can read the number honestly. It is not a system, and nothing here treats gambling as a way to make money — over enough play the mathematics favours the house. 18+.

Next in the pathRTP vs the returns you actually see