UK Gambling Software and Casino Game-Host Licences

A supplier may describe its project as a “UK launch” while its regulatory analysis actually concerns Great Britain: England, Scotland and Wales. This article uses that narrower scope. It does not extend the Gambling Commission framework to Northern Ireland or attempt to determine the rules of another destination market.

Great Britain is the relevant licensing market

The practical starting point is a written description of the service. Does the business deliver software for an operator to deploy, or does it run games that players access through an operator’s website? Who maintains the live game environment? Which legal entity signs the operator agreement? These questions make the licence analysis concrete before a commercial label such as “platform provider” becomes a substitute for it.

Software supply and hosted gameplay use different permissions

The Commission describes a remote gambling software licence as covering manufacture, supply, installation or adaptation through remote communication. Downloading software from a supplier’s server is one example. The relevant activity is the software transaction, not simply the fact that a server exists. Remote gambling software licence.

Hosted gameplay introduces a further question. The Commission explains that a software business may also provide gambling facilities when it hosts casino games accessed through another operator’s platform. Its casino game-host route requires a gambling software operating licence and no direct contract with the players using those facilities. Players must access the games through the other operator’s website or app. Eligibility therefore depends on the actual operating arrangement, rather than a supplier’s preferred job title. Casino game-host operating licence.

For planning purposes, compare the contract with the production architecture. A statement that the operator owns the customer relationship should be consistent with the player terms and access route. A claim that the supplier merely delivers software should be consistent with how the live game is provided. An inconsistency is a reason to investigate the scope before launch, rather than to assume the narrower permission applies.

Licensing checks extend beyond the direct vendor

Licence condition 2.2.1 applies to remote casino, bingo and betting licences, subject to its stated exceptions for ancillary licences and trading-room-only remote betting intermediary licences. It addresses licensed manufacture, supply, installation and adaptation of the gambling software used by the operator. Checking the final supplier alone may therefore leave an incomplete picture. LCCP 2.2.1.

Map each activity to the responsible entity and its licensing basis. Do not assume every subcontracted developer needs a separate licence: the Commission distinguishes a supplier-controlled product from purchased time or skills under the commissioning company’s control. For a group IP holding arrangement, the Commission may consider an umbrella licence where the developer and IP holding company share ownership, management and control and the arrangement meets its umbrella-licensing requirements. If that arrangement is not appropriate, each company needs its own gambling software licence. Record control and contractual responsibilities before deciding whose licence is required. Treat unresolved classifications as open questions with a named reviewer. Gambling software guidance.

RTS evidence must follow the deployed software version

The Remote Gambling and Software Technical Standards, or RTS, and the Commission’s testing strategy form a separate part of the assessment. The RTS introduction explains that the testing strategy determines testing procedures and timing, including when independent testing is required. For gambling software, RTS applicability concerns software used in remote gambling conducted under a Commission operating licence. RTS introduction. Testing strategy.

Teams should translate that scope into a release record: product and version, intended deployment, applicable standards, required testing and the party responsible for the evidence. A certificate without a clear connection to the deployed version leaves an operational question unanswered. The same applies when responsibilities are split between a studio, aggregator, host and customer-facing operator.

Pre-launch records should connect entities, permissions and testing

Identify the market, customer operator and every relevant contracting entity.
Describe software delivery and live gameplay separately, including where each is operated.
Compare proposed host arrangements with the published eligibility conditions.
Map manufacture, supply, installation and adaptation to the responsible entities and applicable licensing arrangements.
Assign responsibility for RTS applicability, testing evidence and release changes.
Record unresolved scope questions and obtain advice before relying on an assumption.

This checklist is a preparation tool, not a substitute for the applicable rules or a legal conclusion. The useful outcome is a consistent account of what the business does, who does it and what permission supports it. That account should remain accurate when the product moves from a sales presentation into production.