This article provides a procurement and project-governance method. It is not legal advice and does not replace professional compliance review for a target market.

The short answer

“The API returns the game,” “the product supports this language or currency,” and “there is a laboratory report” cannot individually prove that a game may launch in a target market. A reliable verification unit includes at least:

market × game × game version × math model version × certification object and scope × currency × language × integration topology version × operating-entity scope

When the game, version, math model, RGS or aggregator, platform, operating entity, brand or domain changes, an earlier conclusion may no longer apply. The purpose of the matrix is not to label content “legal worldwide.” It is to connect each project launch decision to a defined object, scope, current evidence and responsible owner.

Why the six core dimensions cannot be merged

Dimension Question to verify Common mistake
Market Which country or regulatory scope, operating entity, brand and domain? Treating “global” or “Latin America” as an executable scope
Game What are the provider game code and stable catalog record ID? Matching only by display name or skin
Version What are the game, math model, RGS, aggregator and platform versions? Treating every version of the same title as equivalent
Certification Who tested which object, requirements and scope, and is the evidence current? Treating a laboratory standard or one report as a worldwide pass
Currency Which currencies and precisions apply to display, wagering, settlement and reporting? Treating technical currency support as market permission
Language Which languages apply to player rules, help, interface and operational communication? Treating a translation as proof of market readiness

Language, currency and API connectivity are necessary product and technical dimensions, but they are not market legality. Conversely, an operating entity’s authorization in a market does not prove that every game, version or integration topology meets the requirements.

A layered verification process

Layer 1: technical connectivity

Confirm the interface versions, identities, wallet model, callbacks, rounds and transaction path among provider, RGS or aggregator, and platform in the specified environment. Connectivity shows that the tested components can interact. It says nothing by itself about content rights or market admission.

Layer 2: content identity and version

Identify a game through its provider game code rather than its display name. Record the game version, math model version, client build, change notes and verification date. A skin, clone or game of the same type cannot inherit another conclusion without evidence.

Layer 3: language and currency

Verify interface text, game rules, help content, wager and settlement precision, reports and exception handling separately. Passing a language or currency check means only that the tested functional scope passed—not the market dimension.

Layer 4: certification object and scope

Record the report or certificate ID, issuing or testing body, requirements, tested object, version, integration topology, current status and retest triggers. Confirm that the chosen body is currently accepted in the target market and that its recognized scope covers the project object.

Layer 5: operating and market scope

The appropriate owners must verify target-market rules, operating entity, brand, domain, content rights, restrictions and current regulatory records. Do not substitute generic statements from a provider, aggregator or laboratory for a project-specific conclusion.

Layer 6: project production decision

Technical, content, certification, commercial and compliance owners sign their respective areas. Only when every required layer has current evidence can the project record become approved_for_project. That status is neither permanent nor global.

A matrix template

Use one row for one precise combination. If a game has two math models or two RGS versions, use two rows.

Field group Suggested fields Entry rule
Project scope market_code, operator_entity, brand, domain_scope Name the specific object; never write “global”
Game identity provider_id, provider_game_code, catalog_record_id Link to the catalog through stable IDs
Versions game_version, math_model_version, rgs_version, aggregator_version, platform_version Reassess impact after every change
Certification certificate_or_report_id, test_body, requirements_ref, tested_object, scope, status Store coverage, not only a PDF
Localization currency_code, language_code, rules_language Record technical and content verification separately
Evidence evidence_ref, issued_at, last_verified_at, next_review_at Preserve source and time
Decision decision_status, conditions, owner, approved_at Applies only to this project combination

Use controlled decision states such as:

  • evidence_missing: a critical object or source is absent;
  • pending_review: material has arrived but the responsible owner has not completed review;
  • conditional: work may proceed only under stated conditions;
  • approved_for_project: approval applies only to the combination in this row;
  • expired_or_recheck: evidence expired or a change triggered renewed review;
  • withdrawn: a project decision was withdrawn, with its historical reason preserved.

Avoid a single unscoped Boolean such as legal, certified or available.

Brazil example: translating primary-source rules into matrix fields

The following points demonstrate the verification method. They are not an admission conclusion for any project.

  • The Brazilian Ministry of Finance’s Secretariat of Prizes and Betting (SPA) technical FAQ distinguishes evidence objects that may include the betting system, RGS or aggregator, integration between the platform and RGS or aggregator and game provider, individual games and live studios. Record each object and connection rather than writing only “platform certified.”
  • SPA FAQ item 71 discusses conformity evidence for games, skins or clone games and integration certificates. It also indicates that SPA does not provide a single public certified-game list that replaces project verification. Store the report and its coverage against each game or applicable group.
  • FAQ item 94 includes critical components such as RGSs and aggregators in the integration-certification discussion. When a component or version changes, reassess whether existing evidence covers the new topology.
  • FAQ item 84 concerns the language of information provided to players. Language belongs in the matrix, but Portuguese text alone still does not establish the operating entity, game version or integration topology.
  • Check both SPA’s current recognized-certification-body list and each body’s scope. Appearance on the list does not mean every report issued by the body covers every object or version.

UK and GLI examples: standard, testing and market decisions differ

The UK Gambling Commission’s remote technical standards identify obligations for applicable licensees, while its Testing Strategy organizes requirements around test procedures, annual game testing, RTP monitoring, and major and minor updates. This illustrates why retesting after a version change depends on the target market’s current rules and the actual change category. AG cannot provide one universal global answer.

GLI-19 can be a laboratory baseline or input to testing discussions. It is not, by itself, admission to a jurisdiction and does not replace a regulator’s recognition scope, operating-entity authorization, the specific game version or project integration evidence. Store “technical standard used” separately from “evidence accepted by the target market.”

Changes that trigger renewed verification

At minimum, move a row to expired_or_recheck when any of these change:

  • game software, math model, use of RNG or game rules;
  • RGS, aggregator, platform or a critical interface version;
  • wallet model, transaction flow, currency precision or player-information language;
  • report scope, testing body’s recognition or evidence validity;
  • operating entity, brand, domain, content rights or target-market rules.

Terms such as “major update,” “minor update” and “critical component change” must follow current target-market rules, testing-body scope and change records. Do not classify solely from a version number.

Unverified scope note for RTP 0–1000 This numeric range needs definitions for its unit and meaning, math model version, access permissions, testing and certification material, target market and presentation. It must not be treated as a verified RTP conclusion for a game or market version, or as a promise about an individual result or player return.

What can currently be evaluated on this site

  • This article provides a layered method across market, game, version, certification, currency and language.
  • The current game catalog is a name-level snapshot and cannot populate the matrix by itself.
  • Public API material helps define integration topology, but production protocols, permissions and project versions still require confirmation.
  • The Brazil SPA, UKGC and GLI examples—and the RTP 0–1000 scope note—do not establish certification or market admission for a project.
  • Primary sources are cited only to explain matrix fields and verification steps.

Boundaries to keep in mind

  • This page does not promise that AG, a provider, a game or a version is authorized or certified for a market.
  • A laboratory standard, certificate, language, currency, connected API or provider catalog is not proof of worldwide admission.
  • This is not legal advice for Brazil, the UK or another jurisdiction; current rules and recognition scopes must be rechecked at the point of decision.
  • No real-time availability, fixed launch date, performance, SLA or commercial supply scope is promised.

FAQ

Why review the integration path if the provider has a game certificate?

A game certificate may cover only a specified game object and version, while delivery also involves an RGS, aggregator and platform. A target market may require evidence for system or component integration, so compare the report object with the actual topology.

Does support for local currency and language mean the market can be served?

No. They are technical and content dimensions. The operating entity, brand or domain scope, content rights, game version, certification and market rules require separate confirmation.

Can one GLI-19 report be used in every market?

That cannot be assumed. GLI-19 is one laboratory standard baseline. Whether a market accepts the evidence, what object and version it covers, and whether additional evidence is required depend on current rules and project scope.

Does a game upgrade invalidate an old certificate?

The version number alone cannot answer. Record the actual changes, then use target-market rules, report scope and testing-body requirements to decide whether impact assessment, supplementary testing, reissue or new approval is needed.

Before using the “Contact us” section, prepare the target market, operating entity or brand scope, candidate games and versions, integration topology, currencies and languages. AG can then organize project-specific evidence still requiring verification. Supplying material or completing a technical test does not constitute a promise of market admission.

Sources and scope

Related pages:

Primary regulatory and standards sources:

The UKGC RTS page showed an update date of 29 January 2026, its Testing Strategy 31 October 2025, and the SPA FAQ index 21 May 2026. The cited material was accessible on 9 August 2026. Rules, recognized bodies and scopes change; recheck primary sources before a project decision.

Need to turn this guidance into a project plan?

This article supports project evaluation and does not replace technical, contractual, certification or local-law confirmation.

Contact us