RTP Verification in Live Casino: What RGS Suppliers Must Prove to UKGC and MGA Auditors

Remote gaming server (RGS) suppliers holding a UKGC remote gambling software licence or an MGA B2B Critical Gaming Supply licence carry a direct, primary obligation to demonstrate that every live dealer title they supply operates within its certified return-to-player parameters. Game certification from an approved independent testing laboratory (ITL) establishes the theoretical model. What UKGC and MGA auditors examine is different: whether the RGS can prove that model is operating correctly in real time, for every session, across every table. The gap between those two things is where enforcement risk lives.

This article maps the specific obligations under each regime, the documentation auditors test against, and the practical differences in approach between the two regulators. It is addressed to compliance teams at RGS suppliers who hold, or are applying for, a remote gambling software licence from the UKGC or a B2B critical gaming supply licence from the MGA, and who are serving or intend to serve live dealer products into regulated markets.

Why live casino creates a distinct RTP verification problem

In a standard RNG-based slot, the entire game cycle runs on software. An ITL can verify the RNG output distribution, the paytable mathematics, and the game logic against a single certified build. RTP integrity is, in principle, a property of the software as certified.

Live dealer games break this model. The underlying outcome of a blackjack hand or a roulette spin is generated by physical randomness: the deal, the wheel, the ball. The RGS sits between that physical event and the player’s account, translating a camera feed and dealer actions into a settled bet. The certified mathematics still apply, but the chain from physical outcome to settled game record is longer, involves more components, and is not fully deterministic in the same way as a software RNG. Auditors who trained on slot certification know this. They will test the chain, not just the static theoretical model.

GLI-19 v3.0 section 4.18.1 addresses this directly, noting that where wagers are placed on live games conducted by a gaming attendant or other gaming equipment, the RGS must receive instructions from each player, record game results before posting to the gaming platform, and prevent anyone from accessing the live game outcome prior to a wager being finalised. Each of those requirements generates a distinct evidence obligation.

What does the UKGC require RGS suppliers to prove?

UKGC Licence Condition 2.3.1 states that licensees must comply with the Commission’s technical standards and with requirements set by the Commission relating to the timing and procedures for testing. The obligation sits on the remote gambling software licence holder, not on the operator deploying the content. This matters for RGS suppliers because the compliance duty is non-delegable: an operator’s own compliance does not satisfy the RGS supplier’s separate obligation.

The governing technical document is the Remote Gambling and Software Technical Standards (RTS), last updated effective 30 June 2026. Three RTS provisions bear most directly on live casino RTP verification.

RTS 3 requires that, for gaming (including live casino), the game rules must clearly state the average theoretical return to player percentage before a customer commits to gamble. RTS requirement 3C specifies that where a game involves an element of skill, the RTP should be calculated using either the auto-play strategy or a standard published strategy. For live blackjack this creates an obligation to state RTP based on basic strategy play, not a simplified or conservative assumption. The RTP figure must appear in accessible game rules, not only in a technical certificate held by the supplier.

RTS 7D governs changes to game rules, paytables, or other parameters that change the likelihood of winning. The RTS implementation guidance states that such changes should be conducted with the game taken offline or suspended, and that altered games should display a notice informing customers of the change. For live casino, this applies to structural changes to the side-bet paytable (for example, Perfect Pairs or 21+3 on blackjack) or changes to commission rates on Baccarat. An RGS supplier that pushes a paytable update without suspending the affected table and flagging the change to the operator is in breach of RTS 7D regardless of whether the operator also carries an independent obligation to manage this.

RTS 9A addresses progressive jackpot systems, requiring that the jackpot rules describe how the jackpot is funded, the seed and ceiling values, and the return to player percentage. The RTS implementation guidance for 9A states this could be one combined game and progressive jackpot RTP figure or broken down into the base game and jackpot component. Several live casino titles now carry live-network jackpot overlays managed at the RGS level. The supplier must ensure the composite RTP is disclosed, not just the base game’s certified figure.

The Evolution settlement: what it signals for RGS compliance

On 23 July 2026, the Gambling Commission published a public statement confirming that Evolution Malta Holding Limited had agreed to pay £4.75 million following a licence review. According to iGamingBusiness, the investigation found that two operators used six unlicensed websites to bypass technical restrictions and access Evolution’s games in the UK market. Evolution subsequently terminated relationships with the offending operators and strengthened internal controls.

The settlement is significant beyond the headline figure. It establishes, in practice, that the Commission treats an RGS supplier’s software access controls as a compliance obligation under its gambling software licence, not merely a commercial decision. The supplier’s obligation to restrict game access to licensed operators is enforceable through licence review, and failure to maintain adequate technical controls that prevent unlicensed access is treated as a breach of the software licence holder’s own standards obligations. For live casino suppliers, the controls governing which operators can stream your tables, and the technical measures preventing access outside approved jurisdictions, are regulated outputs, not business preferences.

MGA obligations: what the Compliance Audit Manual tests

MGA B2B Critical Gaming Supply licence holders supplying live casino products are subject to audit under the Compliance Audit Manual (MGA/G/001, August 2018, v1), complemented by the Technical Infrastructure guidelines for Remote Gaming (December 2015, v1) and the Gaming Act (Cap. 583). The MGA’s four overarching technical principles from the Technical Infrastructure guidelines are integrity and security, availability and traceability, privacy and confidentiality, and accountability. On accountability, the document is explicit: “The responsibility for the attainment of the established and desired standards on these regulatory principles will remain that of the licensee at all times.”

The Compliance Audit Manual’s gaming operation section (section 5) defines what an approved auditor will examine on the gaming system. Section 5.3.2 requires auditors to observe that the Specification of the Gaming System has been implemented in practice, including game risk management for the relevant class of licence. Section 5.4.1 requires the gaming system to maintain, for each player’s activity, the logon and logoff times, gaming activity history, games played, the time the game began as recorded on the games server, the balance at the start of the bet, the time stakes were placed, the bet status, and the result of the bet or game.

Each of those data fields must be populated for live dealer hands. An auditor testing a live blackjack or live baccarat implementation will request transaction-level logs and cross-reference stake timing, game server timestamps, and settlement records. Missing or inconsistent timestamps between the physical game event and the game server record are the audit failure point that live casino suppliers most commonly encounter in MGA engagements.

Section 5.4.4 requires the back-office to maintain gaming activity history with reporting capability covering changes to game parameters, large wins, and financial statements of gaming transactions. For an RGS supplier, this means the back-office must be able to produce parameter-change history for each live title, showing what side-bet paytables, commission structures, or jackpot configurations were active at any given point. If an MGA auditor asks why the composite RTP on a live table differed in March from what was certified, the supplier must produce a dated record of every parameter that affected that figure.

GLI-19 v3.0: the operational audit standard for live game RTP monitoring

Both UKGC and MGA accept GLI-19 v3.0 as a basis for ITL certification of interactive gaming systems. For live casino, Appendix A of GLI-19 (Operational Audit for Gaming Procedures and Practices) contains the most operationally specific requirements on RTP monitoring, and auditors from both jurisdictions will test against it.

GLI-19 section A.6.1 requires operators and suppliers to maintain accurate and current documentation (for example, PAR sheets) indicating the theoretical RTP for each house-banked game, based on adequate levels of credits wagered. Records must be maintained showing the initial theoretical RTP, dates and types of changes that affected the theoretical RTP, and the recalculated theoretical RTP after each change. Each change to a game’s theoretical RTP, including additions or changes to progressive jackpot increments, causes the game to be treated as new for all reports and records.

Section A.6.2 requires the RGS to have documented procedures for periodically comparing theoretical and actual RTP to identify, investigate, and resolve large variances. Any abnormalities, defined as the actual RTP falling outside the expected range, must result in an error being logged and escalated for investigation. In the live casino context, the physical randomness of the game means short-run actual RTP will routinely differ from theoretical. The audit question is not whether variance exists, but whether the supplier has a defined threshold, a logging mechanism that captures it, and an escalation procedure that was followed when it was triggered.

“The operator shall have procedures in place to periodically compare the theoretical and actual RTP percentage to identify, investigate, and resolve large variances between these two values. Any abnormalities shall result in an error being logged and escalated for investigation.”

GLI-19 section 4.18 sets the baseline for live game technical requirements: the simulcast control servers must provide real-time audio and video access including date, time, game identification, and table number, they must prevent anyone from accessing the live game outcome before a wager is finalised, and they must record game results before posting to the gaming platform. Section C.6.3 requires a continuous surveillance recording that captures enough information to reconstruct each game, with date and time accurate to one second. That surveillance record is the ground truth against which RTP disputes are resolved: if the settled bet record and the surveillance record diverge, the physical outcome governs.

Comparing the two regimes: key differences in audit scope

As of July 2026, the table below maps the principal audit dimensions across the two regulators.

Dimension	UKGC (RTS + LCCP 2.3.1)	MGA (Cap. 583 + Audit Manual MGA/G/001)
RTP disclosure obligation	Theoretical RTP must appear in accessible game rules pre-play (RTS 3C)	Game specification document must reflect approved game type and parameters, auditor verifies implementation against specification (section 5.3.2)
Parameter change controls	Game must be taken offline before paytable or parameter changes (RTS 7D)	Back-office must log and report changes to game parameters (section 5.4.4); change management processes are reviewed
Transaction-level game logging	Implicit in RTS system integrity requirements, game results must be recorded before posting	Explicit: game server timestamp, stake time, bet status, game result required per hand (section 5.4.1)
Theoretical vs actual RTP comparison	Required via GLI-19 A.6.2 (accepted standard); RTS 7 prohibits misleading game designs	Required via GLI-19 A.6.2, MGA auditors test back-office reporting on large wins and parameter changes (section 5.4.4)
Surveillance and reconstruction	Continuous recording requirement (GLI-19 C.6.3 accepted); accessible to Commission on demand	Gaming and financial transaction logs accessible at all times to MGA (Technical Infrastructure, section 2)
Licence holder responsible	Remote gambling software licence holder (LCCP 2.3.1)	B2B Critical Gaming Supply licence holder (Gaming Act Cap. 583, accountability principle)

The practical divergence is less in what is required than in how it is tested. The MGA Compliance Audit Manual provides explicit checklists: an auditor will pull a sample of thirty servers, cross-check IP addresses against the declared network schematic, and request transaction logs at hand level. The UKGC approach is principles-based through the RTS, with auditors exercising greater discretion in how they test. In practice, UKGC enforcement tends to surface through the licensing review process, as the Evolution settlement illustrates, rather than through a structured audit visit.

What RGS documentation must be maintained continuously

Across both regimes, the following documentation must exist, be current, and be producible on demand.

PAR sheets (probability accounting reports) covering each live casino title, including any side-bet or jackpot overlay. Each PAR sheet must show the initial certified theoretical RTP, any amendments with dates and descriptions, and the recalculated RTP following each amendment. Under GLI-19 A.6.1, each amendment causes the game to be treated as new for reporting purposes.

A parameter change log showing every modification to paytable structures, commission rates, jackpot seed values, or contribution rates, with timestamps and evidence that the change was made while the relevant table was offline. Under UKGC RTS 7D, making this change without suspension is a breach. Under MGA section 5.4.4, failing to log and report it is an audit failure.

Transaction-level game records at the hand or spin level, populated with game server timestamps, stake times, bet status, and settlement amounts. MGA section 5.4.1 specifies these fields explicitly. UKGC-facing suppliers must maintain equivalent records both to demonstrate continuous compliance with RTS and because they form the evidential basis for any RTP variance investigation.

Variance monitoring reports, produced on a defined periodic or volume basis, showing the comparison between theoretical and actual RTP over rolling windows. The reports must show that the supplier’s escalation threshold was defined, that it was applied, and where it was triggered, that the investigation procedure was followed. GLI-19 A.6.2 requires this procedure to be documented, auditors will ask for the procedure and for instances where it was invoked.

Surveillance records in compliance with GLI-19 C.6.3, continuous and with timestamp accuracy to one second, retained for the recall period required by the relevant regulatory body. These records must be accessible to the regulator, not simply stored at the supplier’s studio.

An RGS supplier cannot demonstrate RTP integrity in a live casino environment through a certification report alone. The report proves the model was correct at the moment of testing. The audit obligation requires proof that the model has been monitored, and any deviation investigated, across every table in continuous operation.

How does RTP verification differ for live casino versus RNG games?

For RNG-based games, ITL certification of the game software and RNG output is the primary verification mechanism, and ongoing monitoring focuses on software version control and change management. For live casino, physical randomness means actual RTP will diverge from theoretical across short windows. The verification obligation therefore centres on the quality of monitoring procedures and the audit trail those procedures generate, not on whether actual RTP matches theoretical exactly at any point.

Are RGS suppliers directly liable under UKGC rules, or does liability sit with the operator?

Both. UKGC LCCP 2.3.1 binds the remote gambling software licence holder directly. An operator also carries its own compliance obligations. The Evolution settlement confirmed that the Commission will pursue the software licence holder independently where its technical controls fail, regardless of operator-level compliance. Compliance teams must not assume that operator due diligence on their content absolves the RGS supplier of its primary regulatory obligation.

Practical compliance implications for RGS suppliers

The compliance architecture that satisfies both regulators rests on three capabilities. A live parameter management system must enforce offline suspension before any paytable or jackpot configuration change is applied. An automated variance monitoring system must compare theoretical and actual RTP on a defined schedule and log all escalations. A transaction logging layer must populate game server timestamps, stake times, and settlement amounts at hand level for every live table.

Suppliers operating across both the UKGC and MGA markets should maintain a unified evidence pack covering PAR sheets, parameter change history, variance reports, and surveillance retention schedules, structured so that either regulator can be served from the same underlying system. The MGA’s explicit checklist approach means the evidence pack must be capable of answering specific section 5.4 fields by name. The UKGC’s more principles-based testing means the evidence pack must demonstrate, for any time window the Commission selects, that the RTS obligations were met continuously.

Compliance teams should also note that the RTS updates effective 30 June 2026 include changes to the RTS 12 deposit limit framework. Suppliers must verify that their platform-level session and financial controls remain compliant with the revised provisions, particularly where live casino sessions interact with session net position displays required under RTS 2E.

Qualified legal counsel should be consulted before submitting technical compliance documentation to either regulator, particularly where a supplier is managing multi-jurisdictional content delivery from a single RGS and the scope of what is presented to each auditor must be carefully delineated. For a detailed roadmap of implementation steps tailored to your RGS infrastructure, read our guide on live casino RGS implementation and compliance.

For a broader comparison of the UKGC and MGA licensing frameworks, including fee structures and enforcement track records, see our UKGC vs MGA licence cost comparison. For a detailed account of what MGA system audits test beyond the gaming layer, see our article on MGA system audit requirements.

Frequently asked questions

Does a UKGC-certified live casino game automatically comply with MGA requirements? No. ITL certification from a UKGC-accepted laboratory establishes the theoretical model but does not address MGA-specific audit obligations such as transaction-level game logging under section 5.4.1 of the Compliance Audit Manual or back-office parameter change reporting under section 5.4.4. Separate compliance work is required for each regime.

What is the minimum logging granularity required for live casino transactions under MGA rules? The MGA Compliance Audit Manual section 5.4.1 requires the gaming system to record, at minimum, logon and logoff times, the time the game began as recorded on the games server, the balance at the start of the bet, the time stakes were placed, the bet status, and the result of the bet or game. Each of these fields must be populated for every live dealer hand, not aggregated at session level.

How often must theoretical versus actual RTP be compared? GLI-19 v3.0 section A.6.2 requires comparison on a defined periodic or volume basis as required by the regulatory body. Neither UKGC nor MGA prescribes a fixed frequency in primary regulation, but suppliers must set an internal threshold documented in their compliance procedures, with escalation triggered automatically when actual RTP falls outside the defined range for that threshold window.

Does UKGC RTS 7D apply to live casino side-bet paytable changes? Yes. RTS 7D applies to any changes to game rules, paytables, or other parameters that change the likelihood of winning. A change to a Perfect Pairs or 21+3 side-bet paytable on a live blackjack title qualifies. The table must be taken offline before the change is applied, and the updated game should display a notice that the rules have changed.

What triggered the Evolution £4.75m UKGC settlement? On 23 July 2026, the Gambling Commission published a statement confirming that Evolution Malta Holding Limited agreed to pay £4.75m following a licence review. The investigation found that two operators used six unlicensed websites to bypass technical restrictions and access Evolution’s games in the UK market, establishing that an RGS supplier’s technical access controls are a direct regulatory obligation under its gambling software licence.

Key Resources

UKGC Remote Gambling and Software Technical Standards (RTS): gamblingcommission.gov.uk

UKGC LCCP Licence Condition 2.3.1: gamblingcommission.gov.uk/licensees-and-businesses/lccp

MGA Compliance Audit Manual (MGA/G/001): mga.org.mt

MGA Technical Infrastructure guidelines for Remote Gaming (December 2015, v1): available via mga.org.mt guidance notes section

GLI-19 Standards for Interactive Gaming Systems v3.0: gaminglabs.com

Evolution Malta Holding Limited, UKGC public statement (23 July 2026): gamblingcommission.gov.uk