Skip to content
2,151 standards indexed across 19 jurisdictions View the Atlas
3 hubs live · 3 more in the pipeline See all compliance topics
Daily news + multi-week series Browse all insights
3 tools live · 4 interactive tools in development Roadmap
MGA · UKGC · AGCO · RGS 15 min read Aug 24, 2026

Disconnection and Game Resumption Logic: Meeting MGA, UKGC, and AGCO Requirements in a Single RGS Build

MGA, UKGC, and AGCO each impose divergent disconnection obligations. This guide gives RGS developers one reconciliation table to satisfy all three.

Matt Denney

By

Founder, gamingcompliance.io · 15 yrs in iGaming compliance

Published Aug 24, 2026 15 min read Filed Technical Standards

When a player’s connection drops mid-spin, three separate regulatory frameworks activate simultaneously. The Malta Gaming Authority (MGA), the UK Gambling Commission (UKGC), and the Alcohol and Gaming Commission of Ontario (AGCO) each impose distinct obligations on what the Remote Gaming Server (RGS) must do next, and none of those frameworks was designed with the other two in mind. For a supplier building a single RGS intended to serve all three markets, the divergence is not theoretical: it produces concrete engineering conflicts that must be resolved at the architecture stage, not during certification.

This article maps the disconnection and game resumption obligations under each framework, identifies where they conflict, and provides a reconciliation table so that RGS developers can build to the tightest compliant position across all three regulators. Qualified legal counsel should be consulted before finalising implementation decisions, particularly where a specific jurisdiction’s certification body interprets a requirement differently from the text as published.

How Each Regulator Defines a Disconnection Event

The UKGC does not use the term “disconnection” as a defined trigger. Remote Technical Standards (RTS) 10, titled “Interrupted Gambling” and last updated 7 May 2024 under the Remote Gambling and Software Technical Standards published under sections 89 and 97 of the Gambling Act 2005, frames the operative event as a “service interruption.” The aim of RTS 10 is to ensure that customers are treated fairly in the event of interrupted play or betting and that they are aware of how they will be treated if interruptions occur. The standard applies expressly to peer-to-peer betting and gaming, including bingo. Single-player casino products are covered by the implementation guidance, not by a standalone requirement labelled “disconnection,” and the UKGC’s approach turns on whether the outcome was already determined before the interruption occurred.

The MGA, operating under the Gaming Act 2018 (Cap. 583 of the Laws of Malta) and the directives issued thereunder, addresses the scenario through its Compliance Audit Manual (version 1, reference MGA/G/001, August 2018). Section 6.13.2 distinguishes between “Aborted Games” and “Miscarried Games.” An aborted game is one in which the player’s participation is interrupted, after wagering, by a failure of the telecommunications system or of another technical component, but where the game outcome has not yet been determined. A miscarried game is one in which the interruption occurs after the outcome has been determined but before it has been communicated to the player. Both categories trigger distinct compliance obligations, and MGA compliance auditors are directed to test both procedures with a sample of games available to players.

AGCO’s Registrar’s Standards for Internet Gaming, issued under the Gaming Control Act, 1992 and applicable to both registered operators and gaming-related suppliers, addresses disconnection under the “Speed and Interruption” section. Standard 4.20 requires that where speed of interaction has an effect on the player’s chances of winning, the operator must take reasonable steps to ensure the player is not unfairly disadvantaged due to gaming system related performance issues. Standard 4.21 states that service interruptions shall be responded to and dealt with in a way that does not disadvantage players, and this standard applies explicitly to gaming-related suppliers, meaning the obligation reaches the RGS layer directly, not only the operator above it.

Scope note: AGCO Standard 4.21 is marked “(Also applicable to Gaming-Related Suppliers)”, meaning the RGS developer itself carries direct regulatory exposure in Ontario, not just the operator deploying the game.

The Core Engineering Conflict: When Does the Wager Stand?

The fundamental question in any disconnection scenario is whether the wagered funds stay at risk or are returned to the player. The three regulators answer this question differently, and the difference creates the core engineering conflict.

Under UKGC RTS 10A, the outcome-contingency rule controls. Where an interruption occurs after the operator receives notification of the customer’s gamble and where the customer can have no further influence on the outcome of the event or gamble, the results of the gamble should stand. Conversely, where an interruption to a single-participant single-stage event occurs before an outcome has been generated, the customer should have any deducted stake returned to their balance. For stateful games, those with multiple stages or decision points, all reasonable steps should be taken to restore the game to its last known state to enable the customer to complete the game.

The MGA’s aborted/miscarried distinction maps onto a similar logic but with an important difference in terminology and audit emphasis. Where a game is aborted (outcome not yet determined), the MGA Compliance Audit Manual directs auditors to verify that the player’s stake is returned or that the game can be resumed. Where a game is miscarried (outcome determined but not communicated), the licensee must ensure the outcome is still delivered to the player and that any winnings are credited. The MGA framework is tested through compliance audit sampling, not through a prescriptive technical standard in the style of the UKGC RTS, which means the evidentiary requirement for the RGS is to produce auditable records that demonstrate compliant handling rather than to implement a named protocol.

AGCO Standard 4.21 takes the strictest position on player outcomes. The minimum requirements state that the gaming system must pay players the amount won up to that point, or return bets to players where a game cannot be continued after a service interruption, whichever is the better outcome for the player. This “better outcome for the player” rule is more protective than the UKGC’s outcome-contingency approach, because it applies regardless of whether the outcome was determined server-side before the disconnection. If the system cannot determine what the player won, the bet is returned. There is no equivalent of the UKGC’s “results stand” rule where the RGS cannot verify the outcome with certainty.

AGCO Standard 4.21 requires that where a game cannot be continued after a service interruption, the system must pay the player the amount won up to that point or return their bet, whichever is the better outcome for the player.

State Persistence and Logging Obligations

All three frameworks converge on one requirement: the RGS must maintain authoritative, recoverable game state at all times during a round. The divergence is in how prescriptively each regulator specifies the contents of that state record.

UKGC RTS 10B requires that systems must be capable of recovering from failures that cause interruptions to gambling, including where appropriate the capability to void gambles and taking all reasonable steps to retain sufficient information to be able to restore events to their pre-failure state. The implementation guidance for RTS 10B lists the specific data that should be restorable: the state of a deck of cards and any hands that have been dealt, number of tokens collected, any other predetermined information such as maps or prize layouts, the value of any progressive jackpots, the state of any gambles including who has staked what on what outcome, and bets placed or offered. This is a content-specific restoration list that maps directly to game types, including card games, token games, and prize-layout games, and RGS developers should map each supported game type against this list during certification preparation.

AGCO Standard 4.02 requires that accurate and complete records of transaction and game state and play information be kept and made available for purposes that include capturing information needed to continue a partially complete game within a reasonably defined time and resolving disputes in a fair and timely manner. Standard 4.01 requires that continuous logs be maintained for critical gaming systems, including the tracking of financial accounting and game state history. The AGCO framework is outcomes-oriented rather than prescriptive about data fields, but the “partially complete game” language creates a binding obligation: the log must contain enough information to reconstruct and continue the round, not merely to record that an interruption occurred.

The MGA’s audit testing under section 6.13.2 checks that the procedure for aborted and miscarried games is implemented and that players are notified of the game state and their bet status. MGA compliance auditors will examine whether aborted-game wagers appear separately in player account statements pending resolution, and whether the system provides a mechanism for the player to complete the game on reconnection where applicable.

Source: UKGC, Remote Gambling and Software Technical Standards, RTS 10B implementation guidance, last updated 7 May 2024, AGCO, Registrar’s Standards for Internet Gaming, Standards 4.01 and 4.02, MGA, Compliance Audit Manual (MGA/G/001), section 6.13.2.

What Must Happen on Reconnection

GLI-19, Standards for Interactive Gaming Systems v3.0, section 4.16, provides the most granular technical specification for reconnection behaviour and is accepted as a compliance reference by AGCO (which requires ITL certification of games and RGS components) and across MGA-licensed operations where GLI-19 certification is used to demonstrate technical conformity.

GLI-19 section 4.16.3 requires that an interrupted game must be resolved before a player is permitted to participate in another instance of the same game. On reconnection, the required behaviour splits by game type. Where no player input is required to complete the game, for example a slot spin that was committed before the disconnect, the game is acceptable to return to a game completion state, provided the game history and the credit meter or player account balance reflects a completed game. For single-player games where player input is required to complete the game, the game must return the player to the game state immediately prior to the interruption and allow the player to complete the game, unless any superseding game rules or terms and conditions for game recovery are disclosed to the player. For multi-player games where player input is required and the player cannot complete an action within the allotted time, the Gaming Platform must complete the game on behalf of the player in accordance with the game rules, update the game history and credit meters accordingly, and make the results available to the player indicating which decisions were made by the Gaming Platform on their behalf.

UKGC RTS 10A maps cleanly onto the GLI-19 single-player logic: restore and complete for stateful games, let standing outcomes stand for single-stage completed rounds. The AGCO framework is consistent with GLI-19’s reconnection model and adds the “better outcome for the player” floor for situations where the game genuinely cannot be continued. The MGA’s Compliance Audit Manual testing of aborted and miscarried games aligns with the GLI-19 taxonomy, though MGA auditors assess procedural compliance rather than certifying a specific technical implementation.

Live Dealer Interruptions: A Distinct Obligation Layer

Live dealer products introduce a separate disconnection obligation set that sits above the standard RGS interruption framework. GLI-19 section 4.18.2 requires that the Gaming Platform provide information to the player that describes procedures in place to deal with live game interruptions caused by the discontinuity of data flow, video, and voice from the network server during a game, including internet connection outage and simulcast control server malfunction. This disclosure must be available before and during the session. GLI-19 section 4.16 separately requires that procedures be in place to deal with player disconnection or any video, voice, or data stream disruptions during a live game.

The UKGC’s treatment of multi-participant games under RTS 10A notes that games with multiple participants, whether equal chance or otherwise, should be dealt with fairly on a case-by-case basis. This is a deliberately flexible formulation that requires documented operator procedures rather than a fixed technical outcome. For live dealer tables, operators and their RGS suppliers must have written resolution procedures that address the scenario where only some participants disconnect, where the dealer stream fails, and where the game outcome is partially communicated before an interruption.

MGA B2C licensees offering live dealer content produced by a B2B critical gaming supply licensee under the Gaming Authorisations Regulations must ensure that the technical procedures for live game interruptions are covered in their contractual arrangements with the studio supplier and that their own Compliance Audit readiness extends to the live dealer stack. The MGA’s Compliance Audit Manual tests aborted and miscarried games across the licensee’s full game portfolio, which includes live products.

Reconciliation Table: Three Regulators, One Build

The table below maps each disconnection scenario across all three frameworks. The “build target” column identifies the implementation that satisfies all three simultaneously.

Scenario UKGC RTS 10 MGA (CAM 6.13.2) AGCO Standard 4.21 Build Target
Single-stage game: disconnect before outcome generated Return stake to player Aborted game: return stake or resume Return bet (better outcome rule) Void the round, credit stake immediately, log event with timestamp
Single-stage game: outcome determined but not conveyed Results stand, restore and notify Miscarried game: deliver outcome and credit winnings Pay amount won (better outcome rule) Store outcome server-side, deliver on reconnection, credit winnings before allowing new game
Stateful/multi-stage game: disconnect mid-round Restore to last known state, player completes Resume or settle, player notified of status Restore state, player completes, if irrecoverable, return bet Persist full game state server-side, restore on reconnection, fallback to stake return if state irrecoverable
Multi-player game: one player disconnects Fair case-by-case, documented policy required Aborted/miscarried per game rules, audit-ready procedure required Must not disadvantage remaining or disconnected players Platform auto-completes disconnected player’s action per game rules, document policy, surface result to player on reconnection
Progressive jackpot: disconnect during jackpot trigger Restore jackpot value to pre-failure state Miscarried game treatment, credit jackpot if triggered Pay amount won, treat jackpot as won if trigger confirmed server-side Log jackpot trigger atomically before conveying to client, restore confirmed wins unconditionally
Live dealer: video/data stream loss Case-by-case, documented procedure required Full portfolio audit scope, procedure required Service interruption must not disadvantage players Pre-session disclosure of reconnection policy, documented resolution procedure, outcome delivery on reconnect

What This Means for RGS Architecture

The reconciliation table produces four non-negotiable architectural requirements for any RGS targeting all three markets.

Game state must be persisted server-side atomically at the point of wager commitment. The client is the display layer only. Outcome determination, state transitions, and credit updates must occur and be logged on the server before any result is communicated to the player device. This eliminates the class of bug where a disconnection between outcome determination and client notification produces an irrecoverable state, because the server already holds the resolved record.

The better-outcome-for-the-player rule under AGCO Standard 4.21 must be the default fallback for any state that cannot be reconstructed. This is the strictest of the three frameworks on this point. Building to AGCO’s floor automatically satisfies the UKGC’s stake-return requirement for pre-outcome interruptions and the MGA’s aborted-game stake-return requirement. It does not eliminate the UKGC’s “results stand” provision for post-outcome interruptions, which is handled by the atomic logging requirement above.

Every interruption event must be logged with sufficient granularity to support both regulatory audit and player dispute resolution. AGCO Standard 4.02 requires that records capture information needed to continue a partially complete game within a reasonably defined time. UKGC RTS 10B requires retention of sufficient information to restore events to their pre-failure state. The MGA’s compliance auditors will sample game logs to verify aborted and miscarried game handling. A single structured event log covering wager amount, game state at time of interruption, outcome status, resolution action taken, and credit update applied satisfies all three.

Players must be notified of the interruption and its resolution. UKGC RTS 10C requires that operators make available to customers information about their interrupted gambling policy. AGCO Standard 4.21 requires that the gaming system inform players that the speed of connection or processor may have, or appear to have, an effect on the game. For live dealer products, GLI-19 section 4.18.2 requires advance disclosure of reconnection procedures. Consolidating this into a single, jurisdiction-aware disclosure module, surfaced on first login and accessible from game help screens, satisfies all three in one component.

The UKGC’s RTS 10B restoration list, covering card state, token count, prize layouts, jackpot values, and all wager states, functions as a checklist for what the RGS state machine must be able to serialise and restore per game type, any game type not covered by that list requires a documented fallback procedure.

Certification Implications

RGS components deployed in Ontario must be certified by an independent testing laboratory (ITL) registered by the AGCO before use on the gaming site. The AGCO’s ITL Certification Policy governs the scope and timing of that certification. GLI-19 v3.0 section 4.16 is the primary technical reference for interrupted game handling during ITL review, and certification evidence must include test cases covering each disconnection scenario in the reconciliation table above. Amendments to interruption-handling logic after initial certification are subject to the AGCO’s change notification requirements.

MGA B2B critical gaming supply licensees supplying RGS technology to B2C licensees in Malta must ensure their technical architecture aligns with the Gaming Authorisations Regulations and the Player Protection Directive 2018 (Directive 2 of 2018). While the MGA does not mandate a specific ITL standard for RGS interruption handling, MGA compliance audits conducted under the Compliance Audit Manual will test aborted and miscarried game procedures against the licensee’s own published game rules. RGS suppliers providing technology to MGA B2C licensees should ensure their interruption-handling documentation is incorporated into the B2C licensee’s compliance audit readiness file. For a full overview of MGA licence structure and B2B obligations, see the MGA licence requirements profile.

UKGC remote casino licensees are responsible for procuring games testing and must submit a games testing annual audit. The RTS applies to the licensee, but where a licensee relies on third-party RGS software under RTS 16, the licensee must take reasonable steps to ensure that the third-party software meets the applicable RTS requirements. In practice, this means UKGC licensees deploying an external RGS should obtain written confirmation from the RGS provider, and where available ITL certification evidence, that RTS 10 requirements are met. A full reference to UKGC technical obligations is available in the UKGC Remote Technical Standards explorer.

Ontario-registered operators and gaming-related suppliers should also note that AGCO Standards 4.20 and 4.21 sit within the same “Speed and Interruption” section that covers latency fairness obligations. The AGCO’s standards-based approach, as set out in the introduction to the Registrar’s Standards, gives operators and suppliers flexibility in how they meet the outcome: the obligation is not to implement a specific protocol but to achieve the stated regulatory outcome. This means alternative technical implementations of interruption handling are permissible provided they can be demonstrated to meet the Standard. Compliance officers managing AGCO registration requirements should document their interruption-handling rationale as part of their Control Activity Matrix (CAM) submissions.

Key Resources

UKGC Remote Technical Standards, RTS 10, Interrupted Gambling. Published 2 February 2021, last updated 7 May 2024. Available at gamblingcommission.gov.uk. Governs interrupted gambling obligations for all UKGC remote gaming and peer-to-peer betting licensees.

AGCO Registrar’s Standards for Internet Gaming, Standards 4.01, 4.02, 4.20, 4.21. Issued under the Gaming Control Act, 1992. Available at agco.ca. Standards 4.20 and 4.21 apply to both operators and gaming-related suppliers.

MGA Compliance Audit Manual (MGA/G/001), Section 6.13.2, Aborted and Miscarried Games. Version 1, August 2018. Available at mga.org.mt. Defines audit testing criteria for interrupted game handling under MGA licensees.

GLI-19, Standards for Interactive Gaming Systems, Version 3.0, Section 4.16, Interrupted Games. Gaming Laboratories International. The primary technical reference for ITL certification of RGS interruption logic across AGCO, MGA, and UKGC markets.

Source: UKGC, Remote Gambling and Software Technical Standards (RTS 10), gamblingcommission.gov.uk, last updated 7 May 2024, AGCO, Registrar’s Standards for Internet Gaming, sections 4.01, 4.02, 4.20, 4.21, MGA, Compliance Audit Manual MGA/G/001 v1, section 6.13.2, GLI-19 v3.0, section 4.16.

Matt Denney

Matt Denney

Editorial · gamingcompliance.io

Reads the primary source so you don't have to. Fifteen years inside iGaming compliance: operator, supplier, and crown-corporation lottery.

Related coverage · also tagged Technical Standards

Browse all →

Technical Standards

Self-Exclusion Register Integration: The Technical Architecture Required for Multi-Jurisdiction Compliance

Aug 22 · 16 min read

Technical Standards

Alberta iGaming: Geolocation, IP Blocking, and Cross-Provincial Player Rules Under the SRIG

Aug 4 · 16 min read

Technical Standards

Geofencing vs IP Blocking vs Device Fingerprinting: Which Technical Controls Satisfy Regulators

Aug 3 · 15 min read

The Tuesday brief, every week.

One email. Every regulator change we surface, every standard we re-index, every enforcement decision we read. No marketing, no fluff.

Unsubscribe with one click. We'll never share your address.