Suppliers list certifications the way people list qualifications, and buyers rarely ask what each one tested. Most of them are narrow, specific and dated — and that is exactly what makes them useful, once you know which is which.
- A certification is a test house's finding. A licence is a regulator's permission.
- Every certificate names a version and a date. Both matter.
- Certification is usually per product or per system, never company-wide.
- Certification can speed up licensing. It cannot replace it.
Certification is not licensing
A regulator grants permission to operate in its jurisdiction. A test laboratory — GLI, eCOGRA, BMM, iTech Labs and others — examines a system against a published standard and reports whether it conforms.
They interact: many regulators accept a recognised certificate instead of running their own technical assessment, so a certified supplier enters a market faster. But a certified, unlicensed supplier cannot serve you, and a licensed, uncertified one often can.
The standards you will actually see
| Standard | Covers | Does not cover |
|---|---|---|
| GLI-19 | Interactive gaming systems: player accounts, platform security, operational controls, game integration | Sportsbook, individual game maths |
| GLI-33 | Event wagering systems: sportsbook and betting operations | Casino platform, game content |
| GLI-11 / GLI-12 | Gaming devices and game maths in many regimes | The platform serving them |
| RNG certification | Randomness and unpredictability of a specific generator | Whether a game using it pays as advertised |
| ISO 27001 | Information security management as a process | Anything gambling-specific |
| WLA-SCS | Lottery security control standard | Non-lottery products |
Two things follow. A platform running casino and sportsbook needs both GLI-19 and GLI-33 to claim full coverage — one alone leaves half the product untested. And ISO 27001 is a genuine, valuable certification that says nothing whatever about game fairness; it is about how the company manages security, not about what it built.
Read the date and the version
This is the part that gets skipped. A certificate names the exact build that was tested. Software ships continuously; a certificate from two major releases ago describes a system that no longer exists in that form.
Ask for the certificate itself rather than the claim. It will show the standard, the version tested, the issuing laboratory and the date. A supplier reluctant to send it is telling you something.
Certification is per thing, not per company
“We are GLI certified” is not a meaningful sentence on its own. Certified to which standard, for which system, in which version, and accepted by which regulator?
The same applies to games. A studio's catalogue is certified title by title for each market, so a supplier certified in your market may have twenty of its three hundred games available to you. That list is the thing to ask for.
Who accredits the laboratories
A layer most people never see: regulators accredit which test houses they will accept. A certificate from a laboratory your regulator does not recognise may need redoing.
In newer markets this matters a great deal. Until a regulator names accredited laboratories, “certified” means whatever the supplier wants it to mean — and building that accreditation layer is one of the things a maturing regime does early.
How to use certifications in a decision
- Ask for certificates, not claims. The document carries the scope and the date.
- Match the standard to the product. GLI-33 is irrelevant if you are buying slots.
- Check your regulator accepts the laboratory. Cheap to ask, expensive to discover late.
- Treat a recent certificate as a speed advantage, not a quality verdict. It means market entry is faster. It does not mean the games perform.
The question that cuts through
“Which certificate, for which system, tested when, and does my regulator accept that laboratory?” Four clauses. Almost nobody asks all four, and a supplier that answers all four quickly is a supplier with its documentation in order.
