RGS Certification Across Three Regulators: What MGA, UKGC, and AGCO Actually Require for Server-Side Game Logic

Remote gaming server (RGS) providers operating across the MGA, UKGC, and AGCO simultaneously face three distinct certification architectures: different licence classes, different approved-lab lists, different modification-classification frameworks, and different triggers for mandatory re-submission. What unites all three regulators is that they treat server-side game logic, including the RNG and outcome-determination layer, as the highest-risk component in the gambling supply chain. A game that runs faster than permitted, supplies content to unlicensed sites, or relies on an unapproved engine will expose the software supplier to direct regulatory sanction. Both the Stakelogic £122,835 settlement and the Evolution £4.75m settlement in 2026 confirm that the UKGC targets the software licence holder, not just the operator. The MGA and AGCO have built parallel accountability structures into their frameworks.

Which Licence Does an RGS Provider Actually Need?

The three regulators take structurally different positions on whether an RGS provider needs its own licence or operates under the operator’s authorisation umbrella.

The UKGC requires any business that manufactures, supplies, installs, or adapts gambling software to hold a gambling software operating licence issued under the Gambling Act 2005. This is not a registration or an exemption, it is a full operating licence with attendant Licence Conditions and Codes of Practice (LCCP) obligations. LCCP licence condition 2.3.1 mandates compliance with the Remote Gambling and Software Technical Standards (RTS), last updated 31 October 2025, and the Commission has signalled further RTS updates effective 30 June 2026. A certification obtained by an ITL does not substitute for the licence, it is one of the conditions attached to it.

The MGA operates a two-tier model under the Gaming Act 2018 (Cap. 583). An RGS provider supplying game outcomes, RNG functionality, or game engine infrastructure to MGA B2C licensees must hold a B2B Critical Gaming Supply licence. Directive 3 of 2018 (the Gaming Authorisations and Compliance Directive) defines “critical gaming supply” to include back-end services, including the components that determine game outcome. Supplying those services without a B2B licence is a regulatory breach traceable to the receiving B2C licensee, who must verify that all critical gaming suppliers are duly authorised before any game goes live. The MGA’s Compliance Audit Manual (MGA/G/001) makes this a standing audit point: auditors confirm that every critical gaming supply relationship maps to a current B2B licence or a recognition notice.

The AGCO’s framework under the Gaming Control Act, 1992 and the Registrar’s Standards for Internet Gaming defines RGS providers as gaming-related suppliers (GRSs) who run critical gaming systems. That classification creates a distinct set of go-live requirements separate from those applicable to operators. The key distinction the AGCO draws is that platforms, covering player account management, payments, and responsible gambling controls, do not require ITL certification. The game server, RNG, and outcome-determination layer do. An operator’s Technology Compliance Confirmation cannot substitute for the GRS’s own confirmation covering its critical gaming systems.

What Test Standards Actually Apply to Server-Side Game Logic

UKGC: RTS-Governed Principles, Test House Discretion on Method

The UKGC Remote Gambling and Software Technical Standards, published under section 89 and section 97 of the Gambling Act 2005, govern the technical obligations for gambling software licence holders. The RTS deliberately avoids prescribing the method by which requirements must be met, it sets the aim, the requirement, and implementation guidance. The testing strategy document, maintained separately, maps which RTS sections require independent testing and at what frequency.

For server-side game logic, the core RTS chapters are RTS 7 (RNG), RTS 14A through 14F (responsible product design including game cycle integrity and speed restrictions), and the Security Requirements, which the Commission has anchored to ISO/IEC 27001:2022 Annex A. RTS 7 requires that a software RNG produce outcomes such that it is computationally infeasible to predict the next number without complete knowledge of the algorithm and seed value, that the RNG does not reproduce the same output stream, that re-seeding does not introduce predictability, and that any scaling applied to the RNG output maintains those statistical properties. Mechanical RNGs face additional physical construction standards.

RTS 14E is the standard that caught Stakelogic. It prohibits any game design that permits a customer to reduce the time until the result is presented: turbo modes, quick spin, and slam stop features are expressly called out in the implementation guidance as non-compliant. The Stakelogic BV settlement, valued at £122,835 and confirmed via the UKGC’s published public statement, arose from slot games found to be running faster than the RTS permits. The Commission confirmed that the software licence holder is the accountable party for game timing compliance, not the operator deploying the game.

For live dealer content, RTS 17 imposes additional requirements: dealing procedures, staff supervision, video surveillance, and game logs to permit trend analysis. Live dealer RNG elements, including physical wheels, dice, and card shufflers with electronic components, fall within the RTS security requirements even where outcomes are generated mechanically.

MGA: Game Engine Approval as the Primary Gatekeeper

The MGA’s approach to certifying server-side game logic differs from the UKGC’s in a critical respect: it ties approval to the game engine, not just the game title or the game’s statistical output. Directive 3 of 2018, article 19, establishes the following trigger structure for B2C licensees adding games, and article 22 makes clear that the same framework applies to B2B licensees reselling or otherwise providing games to other licensees.

“If the game uses a random number generator and, or is based on a game engine which has not already been approved by the Authority, the prior written approval of the Authority shall be required.”, MGA Directive 3 of 2018, article 19(1)(a)(ii)

Where a game uses an RNG or game engine already approved by the MGA, and the B2C licensee is adding games from a provider with which it has a pre-existing relationship, no prior notification is required. This exemption has a narrow scope. Any new game engine, any novel RNG implementation, and any game added by a provider not already in a pre-existing authorised relationship requires notification within five days of deployment at minimum, or prior written approval where the engine or RNG is unapproved.

The MGA does not maintain a single published list of approved game engines in the same manner that some jurisdictions publish approved game catalogues. The Authority assesses each application for game engine or RNG approval on a documentary basis, requiring the certification and documentation that the Authority specifies. The MGA’s Compliance Audit Manual confirms that auditors examine whether the Authority holds the latest copy of the Change Management Procedure, and whether changes, including software changes, were approved in accordance with that procedure. An RGS provider supplying to the MGA market must treat any modification to core RNG logic or game engine architecture as a potential trigger for re-approval.

AGCO: A Three-Tier Modification Framework

The AGCO’s Internet Gaming Go-Live Compliance Guide sets out the most granular modification-classification framework of the three regulators. Every change to certified gaming software must be classified before deployment, and the classification determines the certification requirement.

Modification Category	Definition	Certification Requirement
Non-Regulatory	Cosmetic or minor changes unrelated to the Standards (e.g., bug fixes, language updates)	No recertification required, confirm changes are non-regulatory
Regulatory	Changes affecting compliance or addressing regulatory concerns without urgency	Must be certified by an AGCO-registered ITL before deployment
Regulatory Fix (Emergency)	Urgent fixes for live issues materially impacting game integrity or the Standards	May deploy immediately, must submit for ITL certification within 5 business days of release

The gaming-related supplier is accountable for correct classification. The AGCO makes clear that a modification rendering the previous certification invalid does so automatically: the prior certificate no longer applies, and the game or system must not be treated as certified until a new ITL certification covers the updated version. The AGCO does not prescribe which entity requests the ITL certification, it can be the game provider, the operator, or another party in the supply chain. The AGCO anticipates it will most commonly be the game provider.

Conditional certifications, where an ITL attaches conditions requiring future modifications, are not recognised by the Registrar. A certification must stand on its own terms. An ITL may certify a version that requires specific features to be disabled for compliance, that is a valid instrument.

Which Labs Are Approved: Navigating the Registered ITL and ATF Lists

Each regulator maintains its own list of approved testing bodies, and cross-jurisdictional acceptance is not automatic.

The UKGC does not publish a prescriptive list of required test houses in the RTS itself. The Commission’s testing strategy document, maintained separately from the RTS, describes the categories of testing required and the frequency. Software licence holders may use any competent, independent test house capable of testing against the RTS, but the Commission’s expectation, confirmed through enforcement, is that the test methodology produces evidence sufficient to demonstrate compliance with each applicable RTS requirement. The security audit required under the RTS security requirements must be conducted by an independent auditor, a requirement anchored to ISO/IEC 27001:2022.

The MGA has not published a closed list of approved certification bodies for game engine approval, the Authority exercises direct approval authority over RNGs and game engines and may require audits at its discretion under article 23(2) of Directive 3 of 2018. In practice, MGA-licensed B2B suppliers typically engage certification from internationally recognised test laboratories such as GLI, BMM Testlabs, and iTech Labs, but the certification output must satisfy the MGA’s own documentation requirements, not simply carry a lab’s stamp.

The AGCO and AGLC both operate closed registered-lab models. The AGCO requires certification only from ITLs registered by the Registrar, a certification from an unregistered lab, regardless of that lab’s international accreditation standing, is not recognised. The AGLC uses the equivalent designation of Accredited Testing Facility (ATF). ATFs registered with the AGLC must add AGLC’s Standards and Requirements for Internet Gaming (SRIG) to their ISO accreditation scope within one year of registration as an iGaming Goods or Services Supplier in Alberta, specifically within the next scheduled accreditation audit cycle. An ATF may not issue a certification contingent on future changes to the technology under review.

What Certification Must Actually Cover: Scope Across All Three Jurisdictions

A recurring compliance failure among RGS providers is misunderstanding what the certification instrument must cover, particularly in multi-game platform contexts.

Under the AGCO framework, the scope of certification covers the Standards relevant to games, RNGs, remote gaming servers, and sport and event betting systems. The AGCO’s Technology Regulation and iGaming Compliance Branch provides guidance to registered ITLs on which Standards are likely to apply, but that guidance is not determinative in advance of a substantive review. For live dealer games, the relevant Casino Electronic Gaming Devices and Gaming Systems Minimum Technical Standards also apply to the physical RNG elements, including wheels, dice tables, and card shufflers with electronic components. The AGLC mirrors this scope requirement: ATF certifications must cover all games, RNGs, and components of iGaming systems that accept, process, determine outcome, display, and log player bets, including live dealer physical equipment.

The MGA certification scope for game engine approval traces to the documentation requirements that the Authority specifies at the time of the application, under article 23(1) of Directive 3 of 2018. Where the Authority requires an audit of the applicant in connection with a new vertical or new game engine approval, that audit is conducted on the Authority’s terms. The practical implication for an RGS provider serving multiple MGA-licensed operators is that each operator’s use of a game from a provider not already in a pre-existing authorised relationship may trigger separate notification obligations at the B2C level, even where the B2B supplier’s engine is already approved.

The UKGC’s RTS applies to the gambling software licence holder. Where an RGS provider operates a multi-operator platform, the server-side logic of each game type must independently satisfy the applicable RTS chapter. A platform-level RNG that serves multiple game types does not produce a single certification covering all games, each game type’s outcome determination must be traceable to the RTS 7 requirements, and the game design elements, including cycle speed, celebration mechanics, and auto-play restrictions, are tested against the relevant RTS 14 sub-requirements.

When Does a Game Modification Require Re-Certification?

All three regulators define re-certification as mandatory when a modification impacts the integrity, fairness, or security of the game or system, but the operational frameworks for reaching that determination differ materially.

The AGCO’s three-tier model provides the most explicit structure. Any modification classified as Regulatory must go through ITL certification before deployment, there is no grace period. The Emergency Fix classification is the only exception, and it is narrow: it applies when an immediate live fix is required to address a regulatory concern or a material integrity risk. Even then, the five-business-day submission window is not a deferral of the obligation, it is a compressed timeline that runs from the moment the fix is deployed.

The AGLC’s SRIG adopts the same three-tier structure and the same five-business-day window for emergency fixes. The SRIG adds a further requirement: upon identification of any issue in a certified game or game system that materially impacts the certification, the ATF must suspend any issued certifications and notify the affected registered iGaming Supplier. That notification then triggers the supplier’s own obligation to assess whether re-deployment without an updated certificate is permissible.

The MGA does not publish a tiered modification classification in the same form. Re-approval is triggered by any change to an approved RNG or game engine. The Change Management Procedure required under the MGA framework, and audited against the Compliance Audit Manual, must document all changes to software and hardware. Auditors examine records of changes with sufficient evidence of approval. An RGS provider that modifies its RNG seeding algorithm, its shuffling logic, or its outcome-calculation layer without seeking fresh Authority approval risks a finding that it has been supplying games outside the scope of the approved engine. The MGA reserves the right to require an audit in connection with any such change under article 23(2) of Directive 3 of 2018.

The UKGC’s approach is principle-based: any modification that would affect compliance with the RTS must be re-tested before deployment. The Commission’s testing strategy document establishes the scope and timing of testing events, software licence holders must maintain a change management process that identifies which RTS requirements each modification could affect and triggers re-testing accordingly. The Stakelogic settlement is the clearest illustration of the consequence of a gap in this process: the slot spin-speed issue was a game design feature that should have been caught during RTS 14E testing, and the failure to identify and remediate it before deployment exposed the supplier to direct regulatory action.

“A certification that contains a limitation on the Registrar’s use of the certification, or purports to disclaim the Registrar’s use of the certification, will not be a recognised certification by the Registrar.”, AGCO, Internet Gaming Go-Live Compliance Guide

Annual Technology Compliance Confirmations

Both the AGCO and AGLC impose a recurring annual confirmation obligation that sits alongside, and is distinct from, ITL/ATF certification. GRSs running critical gaming systems must submit an annual Technology Compliance Confirmation: a letter signed by the CEO and Chief Compliance Officer confirming that the technology remains compliant with all applicable Standards. The AGCO requires this to be submitted in advance of going live and annually thereafter. The AGLC’s SRIG mirrors this structure: both operators and GRSs running critical gaming systems must provide the confirmation, and for the GRS, it covers exclusively that supplier’s own technology, not the integration points managed by the operator.

The distinction between the Technology Compliance Confirmation and the ITL/ATF certificate is operationally significant. The certification is a point-in-time document issued by the lab following a technical review. The annual confirmation is a CEO-level attestation that the deployed technology, as it stands at the date of the letter, is compliant. If a modification was deployed between certification cycles without re-certification, the confirmation cannot honestly be made. RGS providers must treat the annual confirmation exercise as a prompt to audit their modification log against their certification currency.

Enforcement Signals: What the 2026 Settlements Tell RGS Providers

Two UKGC enforcement actions in 2026 define the Commission’s current posture toward software licence holders. The Stakelogic BV settlement of £122,835 arose from slot games running in breach of RTS 14E, the spin-speed restriction. The case confirms that the Commission tests RTS compliance at the game level and holds the software supplier accountable when games fail product-design standards after deployment. The settlement was published as a formal public statement, which is the Commission’s standard format for enforcement actions that serve as a compliance signal to the wider industry.

The Evolution Malta Holding Limited settlement of £4.75m, published 23 July 2026, involved a different dimension of supply-chain compliance: two operators used six unlicensed websites to circumvent technical restrictions and access Evolution’s games in the GB market. The Commission found that Evolution’s supply-chain controls, specifically the technical measures designed to restrict its game content to licensed channels, were insufficient. Evolution terminated the operator relationships and strengthened its internal controls. The settlement’s significance for RGS providers is structural: the UKGC expects suppliers to implement positive controls over who receives their game content, not merely to rely on contractual terms with operators.

The MGA recorded 171 B2B Critical Supply Licences in 2025, up from 68 in 2018, according to the MGA’s 2025 Annual Report. That growth, combined with the Authority’s stated pivot toward AI-driven risk-based supervision, indicates that the MGA is scaling its oversight capacity in proportion to the B2B market it regulates. RGS providers operating under MGA authorisation should expect supervisory engagement to become more targeted as the Authority’s analytical tools develop.

Practical Implications for RGS Providers Managing Multi-Jurisdiction Portfolios

An RGS provider holding a UKGC gambling software licence, an MGA B2B Critical Gaming Supply licence, and AGCO GRS registration simultaneously must maintain three separate certification tracking systems, because the re-certification triggers are not aligned. A modification that the AGCO would classify as Non-Regulatory may still require MGA Change Management documentation, and may still touch an RTS chapter that requires evidence of testing under the UKGC framework.

The certification scope question is particularly acute for live dealer products. All three regulators impose requirements on the physical RNG elements, including wheels, dice, and card shufflers with electronic components. The AGCO and AGLC explicitly extend ATF/ITL certification scope to those physical elements. A live dealer studio serving all three markets must map its physical equipment certifications alongside its software certifications.

For the AGCO and AGLC markets, the registered ITL/ATF list is the starting constraint. An RGS provider that has historically used a test house not registered in Ontario or Alberta must either arrange registration for that house or engage an additional registered lab. The AGLC’s requirement that ATFs add AGLC’s SRIG to their ISO accreditation scope within one year creates a time-limited transition risk for Alberta-focused providers entering the market at the 13 July 2026 launch.

Readers looking for a broader comparison of AGCO and AGLC regulatory architecture, including the full scope of the Registrar’s Standards versus AGLC’s SRIG, will find additional context in our AGCO vs AGLC comparative analysis. For the full UKGC licensing and RTS framework, including the post-White-Paper enforcement context, the UKGC vs MGA 2026 licence cost analysis maps the broader regulatory cost architecture that surrounds these technical obligations. The AGCO’s three-year enforcement pattern in Ontario also provides useful context for how the Registrar applies Standards in practice. To ensure your certification approach aligns with all applicable regulatory requirements, consult the RGS certification checklist covering all three jurisdictions.

Key Resources

UKGC Remote Gambling and Software Technical Standards (RTS), published 2 February 2021, last updated 31 October 2025, updates effective 30 June 2026. Available at gamblingcommission.gov.uk.

UKGC Licence Conditions and Codes of Practice (LCCP), licence condition 2.3.1 governs technical standards obligations for gambling software licence holders. Version effective from 6 April 2026.

MGA Directive 3 of 2018, Gaming Authorisations and Compliance Directive (V2, October 2021), articles 19 to 23 govern game and game engine approval obligations for B2B and B2C licensees. Available at mga.org.mt.

MGA Compliance Audit Manual (MGA/G/001), August 2018 v1, defines audit procedures for critical gaming supply relationships and change management. Available at mga.org.mt.

AGCO Internet Gaming Go-Live Compliance Guide, defines the three-tier modification framework, ITL certification scope, and Technology Compliance Confirmation requirements for Ontario GRSs. Available at agco.ca.

AGLC Standards and Requirements for Internet Gaming (SRIG), version dated 17 March 2026, governs ATF certification, the AGLC-registered ATF requirement, and the ISO accreditation timeline for Alberta. Available at aglc.ca.