A lobby can carry a new market’s language in a week. Strings, currency symbols and a help page are the cheap half of localisation. The half that decides whether the title can be placed at all is a certificate that names the market, the build and the game set — and a localisation that moves any of the three turns a translation task into a certification task.
That distinction matters most to whoever decides whether a market-specific title enters a lobby: an aggregator’s or platform’s content lead, or an operator’s content manager placing a title into one regulated market. The question in front of them is not “is this game in Dutch?” It is “is this edition a certified artefact for this market, and what do I hold before I place it?”
A certificate names a jurisdiction, a version and a game set
The first thing a localised edition changes is the scope of the paperwork. Certification is not a global property that travels with a game. A certificate neither makes an operator licensed, nor covers changes made after the test, nor transfers between jurisdictions, and a certificate issued against one market’s requirements can need supplementary testing for another’s, as the certification guide published by iGamingHub in August 2026 sets out. Its worked example is ordinary rather than exotic: in July 2026 the platform supplier Bede Gaming announced GLI-19 and GLI-33 certification with the testing performed by eCOGRA — one accredited laboratory testing against another organisation’s published standards.
The standards themselves are not licences either. GLI-19 covers interactive gaming systems and GLI-33 covers event wagering; regulators adopt, adapt or ignore them independently, and the same source notes that a regulator may supplement or modify a standard’s provisions through its own licensing conditions. That is the mechanism by which a market’s localisation duties become build requirements rather than editorial preferences, and it is where the Netherlands is the clearest current example.
The market that regulates the interface itself
The Dutch gambling authority’s Assessment Scheme is a conformity-assessment document, and its localisation requirements are technical. As read in October 2026 against the scheme’s version 2.1 and the 2026 summary of the Dutch application process, every accessible part of the player interface must show the time in the Netherlands, the time elapsed since sign-in and the player’s balance, and the landing page must show the date and time of the player’s penultimate registration. Applications are filed in Dutch, with exceptions for ICT documents, contracts and audit reports, and the scheme is binding only in its Dutch text — the English version is a courtesy translation.
Read as a specification rather than as a language rule, that tells a studio and an aggregator something specific: the localised edition has to be able to display regulator-mandated session and account data inside the client, and it has to be built against a document whose authoritative language is not English. A language pack added after the build cannot satisfy either.
The same market ties the hosting layer to the localisation story. The control database must sit physically in the Netherlands and the gaming system inside the EU or EEA, with a control plan and an exit plan that are less than a year old, owned by the most senior responsible person, managed by a named officer and supplied to the regulator on each new version. That is the same question the data residency and cross-border transfer analysis addresses for platform teams generally, and here it is one of the conditions under which a market-specific title may be offered at all.
Game explanations have to be identical in every language offered
The sharpest requirement of the set is the one an aggregator can test directly. Standard KS.09.33_2.0 of the same scheme requires game explanations to be identical across all languages offered. A localised edition is therefore a set of coordinated variants, not one market’s rewritten text. If a translator, a copywriter or a market manager changes how the game explains a feature, a paytable row or a bonus condition in one language, the build breaks an identity rule rather than merely diverging in tone — and the check is a cross-language diff of the explanation set, not a proofread.
Two practical consequences follow. The first is that the localised edition needs its explanations held as structured source, so the identity check is mechanical. The second is a discipline the same source is explicit about: the Dutch authority does not publish its reasons for refusing applications, so any claim about the most common rejection causes is inference rather than published data. What the public record does show is inspection findings and enforcement against licence holders who already passed assessment. The honest reading for a supplier is to treat the scheme as a build specification and to expect the regulator to test live behaviour after grant, not only design documents at filing.
Which changes put the localised build back in the laboratory
The reason localisation is a certification decision and not a copy decision is the change model. Re-testing is triggered by a material change to a certified system, and the triggers listed in the August 2026 certification guide are concrete: core platform version upgrades, changes to the random-number generator or to game mathematics, new payment or wallet flows, and modifications to player-protection controls. Cosmetic and content-only changes usually do not trigger re-testing.
That line is where a commissioning brief earns its money, because the two sides of it pull in opposite directions commercially:
- Content-side localisation — interface strings, game names and descriptions, help and rules text, artwork, currency and denomination display, and locale-specific promotional surfaces. Usually content-only, usually outside a re-test.
- Maths-side localisation — changing the paytable or the return, converting a jackpot or a denomination set in a way that alters the outcome distribution, re-specifying a bonus mechanic for a market, or switching out the generator. That is a new certified artefact, and it lands on the laboratory queue.
Markets differ on how tightly they police the line. The United Kingdom runs approved test houses with a formal major/minor change classification, an annual games testing audit, and live monitoring of the return actually delivered; Brazil requires certification by a laboratory recognised by the regulator, with annual revalidation. Neither model lets a supplier decide unilaterally that its change was cosmetic.
Four certification jobs, and which one a localisation touches
It helps to know which of the four certification jobs a localised edition actually disturbs. The first is game and random-number-generator testing: does the generator produce sound output and does the game’s actual return match its declared mathematics under sustained simulation. The second is system or platform certification, which is the layer GLI-19 addresses. The third is independent information-security auditing, usually benchmarked to ISO/IEC 27001 where player funds and data are involved. The fourth, increasingly, is responsible-gambling and player-protection functionality — deposit limits, self-exclusion propagation, time-outs and reality checks — which is sometimes tested inside system certification and sometimes assessed in a compliance audit.
Market-specific technical references sit on top of those layers rather than replacing them. The United Kingdom’s Remote Gambling and Software Technical Standards place random outcome generation, account information and game information in their own requirements; Ontario’s Registrar’s Standards for Internet Gaming require certification for all games and generators under standard 4.08; Denmark’s certification programme carries separate requirements for generators and for online casino games; and Malta’s technical infrastructure guidance covers hosting and game certification for both business-to-business and business-to-consumer licensees.
The laboratory that issues the certificate is a separate variable. The recognised list is short — Gaming Laboratories International, BMM Testlabs, eCOGRA, iTech Labs, Quinel, Trisigma and Gaming Associates appear across the markets surveyed — and recognition is granted by a regulator for a scope, so a laboratory’s standing in one market says nothing about whether the target regulator will accept its report. The practical rule is to choose by accreditation scope that matches the roadmap, then by capacity in the window, because report reuse where the regulator permits it is the only significant saving available.
The evidence pack to require before a shelf decision
An aggregator, a platform or an operator placing a market-specific title can ask for a small set of documents and answers, and every one of them is obtainable before the title appears in a lobby:
- The certificate’s scope in writing — the regulator and market it was issued for, the system version, and the game set it covers.
- The laboratory and its accreditation for that regulator and that scope, not a general reputation.
- The localised build’s own identifier — a version and a digest — plus confirmation that the artefact certified is the artefact that will be served.
- The explanation inventory per locale, with the cross-language identity check where the market requires explanations to match across every language offered.
- The market-mandated interface data, evidenced in the build rather than described: the fields the market requires the client to surface, and where they render.
- The language of documentation, where the market requires filings or user-facing documents in its own language.
- The change record since certification — every change classified against the market’s major/minor model, with the laboratory’s re-test outcome where one was required.
- The responsible-gambling controls’ version, and whether the localised edition altered any control the current certification covers.
- The hosting and data-location claims where the market regulates them, including any in-country database requirement.
- The presence question — whether the market requires a local entity, a local register entry or a one-off authorisation before a title may be offered there, which in some frameworks is a condition of supply rather than of software.
The tenth item is easy to overlook because it is not a technical artefact. Peru’s framework, for example, rests on local incorporation and a live register of authorised operators, alongside a one-off authorisation fee and a guarantee; the software can be perfect and the placement still unlawful if the supplier’s route into the market is not in place.
What the evidence does not prove
A certificate is not a licence. A certified localised edition may still be unplaceable because the supplier’s authorisation route in that market is absent, incomplete or on a staged timetable — the position the Italian certification timetable records, where a game system has to hold its own verification result before the operators that carry it can demonstrate their integration, and where later modifications to critical components or verified functions have to go to the verification body in advance.
Nor does certification of a version survive the version. Italy’s framework is the clearest illustration of how far the duties extend past the certificate: authorisations run for 12 months and are renewed through an audit that compares the operating system with the certified version and checks the real prize pool or return against 12 months of game data, and game rules must state where an outcome can be influenced by automated decision-making. A market-specific edition that ships a live-ops change without a version bump is not an administrative shortcut; it is the state the change-control rule exists to prevent.
And the commercial claim stays where it belongs. A localised edition in the right market can be tested for a registration-to-first-deposit effect, or for session quality, against a controlled comparison; it does not follow from a certificate, and a certificate is not evidence that it holds. The certification submission work and the RGS integration requirements that sit either side of this decision are both cheaper to hold together from the design stage than to reconcile in a laboratory queue.
The decisions that belong on one page
- Scope. Which market is this edition certified for, and does the certificate name the build and the game set?
- Route. Which laboratory is recognised for that market, and does its accreditation cover this product type?
- Side of the line. Is the localisation content-only, or does it touch mathematics, the generator or a player-protection control?
- Identity. Where the market requires explanations to match across languages, is the explanation set held as source that can be diffed?
- Interface duties. Which regulated fields must the client surface, and in whose authoritative language is the specification written?
- Presence. Does the market require a local entity, register entry or authorisation before supply?
- Change record. Who owns the classification of every subsequent change, and what happens when live operations and the certification disagree?
A custom game built for one market and a localised variant of an existing title reach that list from different directions, and a title carried through an aggregator’s catalogue arrives with a third party’s evidence attached. In all three cases the shelf decision is the same decision: whether the market, the build and the game set are named on the same document. Wizards holds the certification and compliance and casino game development sides of that work together from the design stage, which is where the scope question is cheapest to answer.
Questions studios, platforms and operators ask
Does a localised version of a certified game need its own certification?
It depends on what the localisation changes. Re-testing is triggered by a material change to a certified system — core platform version upgrades, changes to the random-number generator or game mathematics, new payment or wallet flows, and modifications to player-protection controls — while cosmetic and content-only changes usually do not trigger re-testing. Interface strings, artwork and display conventions normally sit on the content side. A change to the paytable, the return, a denomination set that alters the outcome distribution or a bonus mechanic sits on the other side and produces a new certified artefact. A certificate also does not transfer between jurisdictions, so a build certified elsewhere may still need supplementary testing for the target market.
Is a translation enough when the market’s rules are about language?
Not where the language rule carries technical duties. The Dutch Assessment Scheme requires every accessible part of the player interface to show the time in the Netherlands, the time elapsed since sign-in and the balance, and the landing page to show the date and time of the player’s penultimate registration; applications are filed in Dutch with limited exceptions, and the scheme is binding only in its Dutch text. Those are build requirements. A language pack applied after the build cannot satisfy them.
Which regulator requires game explanations to be identical in every language offered?
The Dutch standard KS.09.33_2.0, as read in October 2026, requires game explanations to be identical across all languages offered. The consequence for a localised edition is that its explanations have to be treated as one coordinated set rather than as market-by-market copy, so that a change in one language can be checked against the others.
What interface data can a regulated market require inside the game client?
Session and account data, in the Dutch example: Netherlands time, elapsed session time and player balance on every accessible part of the interface, with the date and time of the player’s penultimate registration on the landing page. The point generalises — a market’s localisation duties can reach into what the client displays, not only into what it says.
How do we know which laboratory will be accepted?
By accreditation scope, not reputation. Recognition is granted by a regulator for a specific scope, so a laboratory’s standing in one market does not establish that the target regulator will accept its report. Choose the laboratory whose recognitions match the markets on the roadmap and that has capacity in the required window, since report reuse — where the regulator permits it — is the main saving available.
Does a certificate prove a game will perform in a market?
No. A certificate establishes that a system, a version and a game set met a regulator’s technical standard. It says nothing about retention, conversion or revenue. A market-specific edition can be tested for a registration-to-first-deposit effect or for session quality against a controlled comparison, but that is a measurement to run, not an outcome a certificate implies.
