A gaming licence is issued to an operator, and the obligations attach to the operator. Regulators do not accept a vendor’s shortcomings as a defence.
Yet most licence conditions are met — or missed — inside the platform. This is an uncomfortable arrangement, and it is why platform selection and licensing strategy need to be the same conversation rather than sequential ones.
Two different certifications
The distinction confuses operators constantly.
Platform or supplier certification means the software has been tested against a jurisdiction’s technical standards by an accredited laboratory. Games are certified separately, title by title, against RNG and return-to-player requirements.
Operator licensing is a separate process assessing the company, its owners, its funding, its policies and its people.
Neither substitutes for the other. A platform certified in a market does not shorten your licence application meaningfully — but an uncertified platform can make the application impossible, because you cannot demonstrate compliance with technical standards using software that has never been tested against them.
The practical consequence: verify certification status per jurisdiction before applying, and treat “certification in progress” as what it is, which is an unfunded promise with no date attached.
Technical standards vary more than expected
Jurisdictions differ on specifics that reach deep into platform behaviour.
Session limits and mandatory reality check intervals. Whether autoplay is permitted and under what constraints. Minimum spin durations. How balances must be displayed, and in what currency. What must appear on screen during play. Rules on bonus presentation and wagering requirement disclosure.
These are not configuration preferences. They are conditions, and they need to be enforceable per market on the same platform instance. An operator running three jurisdictions needs three different behaviour profiles running simultaneously, applied by player jurisdiction rather than by brand.
Platforms that treat market configuration as a per-deployment setting rather than a per-player attribute create a structural problem the moment a second market arrives.
Reporting is where the ongoing burden sits
Licence conditions include continuing reporting obligations, and the formats are prescribed rather than negotiable.
Several regulators require regular submissions in specified schemas, some near real-time. Others require data to be available for inspection on demand within a defined window.
The question for a vendor is how much of this is automated. Where regulatory reporting is generated natively in the required format, it is a scheduled job. Where it is produced by exporting raw data and reformatting it manually, it is a permanent staffing cost and an error surface — and errors in regulatory submissions are treated considerably more seriously than errors in management reporting.
Data residency and retention
Some jurisdictions require player and transaction data to be held within specific geographic boundaries, and a few require a copy on infrastructure the regulator can access directly.
Retention periods are typically long — multiple years — and apply to transaction records, verification documents, communications and, increasingly, evidence of responsible gaming interventions.
Ask where data is physically stored, whether that can be configured per market, and how retention and eventual deletion are handled. Cloud-hosted platforms sometimes cannot satisfy residency requirements in particular markets, which is worth discovering before an application rather than during one.
Change control matters to regulators
An underappreciated point: in several jurisdictions, how software changes are deployed is itself regulated.
Certified builds cannot be modified arbitrarily. Material changes may require recertification. Regulators may require evidence of change control — what was deployed, when, who approved it, and how it was tested.
Platforms with disciplined release processes can produce this. Platforms that deploy continuously without documented approval trails cannot, and the operator carries the consequence.
Audit support is a real capability
When a regulator asks a question, the response window is short and the question is usually specific: produce everything relating to this player, or explain this transaction, or evidence that this control was operating on this date.
Assessing a casino software provider on audit readiness means asking to see it done. Request a full player history export, an intervention log, a verification decision trail. Platforms holding player management, payments and compliance data in one system can generally assemble this quickly. Stacks combining several vendors frequently cannot produce a coherent single view at all, which becomes apparent at the worst possible moment.
The platform does not carry your obligation
The point worth ending on, because operators do occasionally misunderstand it.
Choosing a well-certified platform with strong compliance tooling reduces the work substantially. It does not transfer the obligation. If a control fails, the regulator’s action is against the licensee.
Contracts should reflect that asymmetry — with warranties on certification status, notice obligations when certification changes, and defined support commitments during regulatory enquiries. Operators who assume the vendor’s compliance is their compliance find out otherwise during an investigation, which is the most expensive way to learn it.