Este artigo apresenta um método de compras e governança de projeto. Não constitui aconselhamento jurídico e não substitui a revisão profissional de conformidade para um mercado-alvo.

A resposta curta

“A API retorna o jogo”, “o produto oferece suporte a este idioma ou moeda” e “há um relatório de laboratório” não podem, individualmente, comprovar que um jogo pode ser lançado em um mercado-alvo. Uma unidade de verificação confiável inclui, no mínimo:

mercado × jogo × versão do jogo × versão do modelo matemático × objeto e escopo de certificação × moeda × idioma × versão da topologia de integração × escopo da entidade operadora

Quando o jogo, a versão, o modelo matemático, o RGS ou agregador, a plataforma, a entidade operadora, a marca ou o domínio mudam, uma conclusão anterior pode deixar de se aplicar. O objetivo da matriz mercado-jogo-versão-certificação não é rotular conteúdo como “legal no mundo inteiro”. É vincular cada decisão de lançamento de projeto a um objeto definido, escopo, evidência atual e responsável.

Por que as seis dimensões centrais não podem ser fundidas

Dimensão Pergunta a verificar Erro comum
Mercado Qual país ou escopo regulatório, entidade operadora, marca e domínio? Tratar “global” ou “América Latina” como escopo executável
Jogo Quais são o código do jogo do provedor e o ID estável de registro do catálogo? Corresponder somente pelo nome de exibição ou skin
Versão Quais são as versões do jogo, modelo matemático, RGS, agregador e plataforma? Tratar todas as versões do mesmo título como equivalentes
Certificação Quem testou qual objeto, requisitos e escopo, e a evidência está atual? Tratar um padrão de laboratório ou um relatório como aprovação mundial
Moeda Quais moedas e precisões se aplicam à exibição, apostas, liquidação e relatórios? Tratar suporte técnico de moeda como permissão de mercado
Idioma Quais idiomas se aplicam a regras do jogador, ajuda, interface e comunicação operacional? Tratar uma tradução como prova de prontidão para o mercado

Idioma, moeda e conectividade de API são dimensões necessárias de produto e técnica, mas não constituem legalidade de mercado. Em sentido inverso, a autorização de uma entidade operadora em um mercado não comprova que todo jogo, versão ou topologia de integração atenda aos requisitos.

Um processo de verificação em camadas

Camada 1: conectividade técnica

Confirme as versões de interface, identidades, modelo de carteira, callbacks, rodadas e caminho de transação entre provedor, RGS ou agregador e plataforma no ambiente especificado. A conectividade mostra que os componentes testados conseguem interagir. Por si só, ela não diz nada sobre direitos de conteúdo ou admissão no mercado.

Camada 2: identidade e versão do conteúdo

Identifique um jogo pelo código de jogo do provedor, e não pelo nome de exibição. Registre a versão do jogo, versão do modelo matemático, build do cliente, notas de alteração e data de verificação. Uma skin, clone ou jogo do mesmo tipo não pode herdar outra conclusão sem evidência.

Camada 3: idioma e moeda

Verifique separadamente o texto da interface, regras do jogo, conteúdo de ajuda, precisão de aposta e liquidação, relatórios e tratamento de exceções. Aprovar uma verificação de idioma ou moeda significa apenas que o escopo funcional testado foi aprovado — não a dimensão de mercado.

Camada 4: objeto e escopo da certificação

Registre o ID do relatório ou certificado, órgão emissor ou de testes, requisitos, objeto testado, versão, topologia de integração, status atual e gatilhos de novo teste. Confirme que o órgão escolhido é atualmente aceito no mercado-alvo e que seu escopo reconhecido abrange o objeto do projeto.

Camada 5: escopo operacional e de mercado

Os responsáveis adequados devem verificar regras do mercado-alvo, entidade operadora, marca, domínio, direitos de conteúdo, restrições e registros regulatórios atuais. Não substitua uma conclusão específica do projeto por declarações genéricas de um provedor, agregador ou laboratório.

Camada 6: decisão de produção do projeto

Os responsáveis técnicos, de conteúdo, certificação, comercial e conformidade assinam suas respectivas áreas. Somente quando cada camada exigida tiver evidência atual o registro do projeto poderá se tornar approved_for_project. Esse status não é permanente nem global.

Um modelo de matriz

Use uma linha para uma combinação precisa. Se um jogo tiver dois modelos matemáticos ou duas versões de RGS, use duas linhas.

Grupo de campos Campos sugeridos Regra de preenchimento
Escopo do projeto market_code, operator_entity, brand, domain_scope Nomeie o objeto específico; nunca escreva “global”
Identidade do jogo provider_id, provider_game_code, catalog_record_id Vincule ao catálogo por meio de IDs estáveis
Versões game_version, math_model_version, rgs_version, aggregator_version, platform_version Reavalie o impacto após cada mudança
Certificação certificate_or_report_id, test_body, requirements_ref, tested_object, scope, status Armazene a cobertura, não apenas um PDF
Localização currency_code, language_code, rules_language Registre separadamente a verificação técnica e de conteúdo
Evidência evidence_ref, issued_at, last_verified_at, next_review_at Preserve fonte e tempo
Decisão decision_status, conditions, owner, approved_at Aplica-se somente a esta combinação do projeto

Use estados de decisão controlados, como:

  • evidence_missing: um objeto ou fonte crítica está ausente;
  • pending_review: o material chegou, mas o responsável não concluiu a revisão;
  • conditional: o trabalho pode prosseguir somente sob as condições declaradas;
  • approved_for_project: a aprovação se aplica somente à combinação desta linha;
  • expired_or_recheck: a evidência expirou ou uma mudança acionou nova revisão;
  • withdrawn: uma decisão de projeto foi retirada, com sua razão histórica preservada.

Evite um único Boolean sem escopo, como legal, certified ou available.

Exemplo do Brasil: convertendo regras de fontes primárias em campos da matriz

Os pontos a seguir demonstram o método de verificação. Eles não constituem uma conclusão de admissão para qualquer projeto.

  • O FAQ técnico da Secretaria de Prêmios e Apostas (SPA) do Ministério da Fazenda do Brasil distingue objetos de evidência que podem incluir o sistema de apostas, RGS ou agregador, a integração entre a plataforma e RGS ou agregador e provedor de jogo, jogos individuais e estúdios ao vivo. Registre cada objeto e conexão, em vez de escrever apenas “plataforma certificada”.
  • O item 71 do FAQ da SPA trata de evidências de conformidade para jogos, skins ou jogos clone e certificados de integração. Ele também indica que a SPA não fornece uma única lista pública de jogos certificados que substitua a verificação de projeto. Armazene o relatório e sua cobertura em relação a cada jogo ou grupo aplicável.
  • O item 94 do FAQ inclui componentes críticos, como RGSs e agregadores, na discussão sobre certificação de integração. Quando um componente ou versão mudar, reavalie se a evidência existente cobre a nova topologia.
  • O item 84 do FAQ trata do idioma das informações fornecidas aos jogadores. O idioma pertence à matriz, mas texto em português sozinho ainda não estabelece a entidade operadora, versão do jogo ou topologia de integração.
  • Verifique tanto a lista atual de organismos de certificação reconhecidos pela SPA quanto o escopo de cada organismo. Aparecer na lista não significa que todo relatório emitido pelo organismo cubra todo objeto ou versão.

Exemplos do Reino Unido e GLI: padrão, testes e decisões de mercado são diferentes

Os padrões técnicos remotos da UK Gambling Commission identificam obrigações para licenciados aplicáveis, enquanto sua Estratégia de Testes organiza requisitos em torno de procedimentos de teste, teste anual de jogos, monitoramento de RTP e atualizações maiores e menores. Isso ilustra por que um novo teste após uma mudança de versão depende das regras atuais do mercado-alvo e da categoria real da mudança. A AG não pode fornecer uma resposta global universal.

O GLI-19 pode ser uma base de laboratório ou insumo para discussões de teste. Por si só, ele não é admissão em uma jurisdição e não substitui o escopo de reconhecimento de um regulador, a autorização da entidade operadora, a versão específica do jogo ou a evidência de integração do projeto. Armazene “padrão técnico utilizado” separadamente de “evidência aceita pelo mercado-alvo”.

Mudanças que acionam nova verificação

No mínimo, mova uma linha para expired_or_recheck quando qualquer um destes elementos mudar:

  • software do jogo, modelo matemático, uso de RNG ou regras do jogo;
  • RGS, agregador, plataforma ou versão de interface crítica;
  • modelo de carteira, fluxo de transação, precisão de moeda ou idioma das informações do jogador;
  • escopo do relatório, reconhecimento do organismo de testes ou validade da evidência;
  • entidade operadora, marca, domínio, direitos de conteúdo ou regras do mercado-alvo.

Termos como “atualização maior”, “atualização menor” e “mudança de componente crítico” devem seguir as regras atuais do mercado-alvo, o escopo do organismo de testes e os registros de mudança. Não classifique apenas por um número de versão.

Nota de escopo não verificado para RTP 0–1000 Este intervalo numérico precisa de definições de sua unidade e significado, versão do modelo matemático, permissões de acesso, material de testes e certificação, mercado-alvo e apresentação. Ele não deve ser tratado como uma conclusão de RTP verificada para uma versão de jogo ou mercado, nem como promessa sobre resultado individual ou retorno ao jogador.

O que pode ser avaliado atualmente neste site

  • Este artigo fornece um método em camadas para mercado, jogo, versão, certificação, moeda e idioma.
  • O catálogo de jogos atual é um retrato no nível de nomes e não pode preencher a matriz por si só.
  • O material público de API ajuda a definir a topologia de integração, mas protocolos de produção, permissões e versões de projeto ainda exigem confirmação.
  • Os exemplos da SPA do Brasil, UKGC e GLI — e a nota de escopo RTP 0–1000 — não estabelecem certificação nem admissão de mercado para um projeto.
  • Fontes primárias são citadas apenas para explicar os campos da matriz e as etapas de verificação.

Limites a considerar

  • Esta página não promete que a AG, um provedor, um jogo ou uma versão esteja autorizado ou certificado para um mercado.
  • Um padrão de laboratório, certificado, idioma, moeda, API conectada ou catálogo de provedor não é prova de admissão mundial.
  • Isto não constitui aconselhamento jurídico para o Brasil, Reino Unido ou outra jurisdição; regras atuais e escopos de reconhecimento devem ser verificados novamente no momento da decisão.
  • Não há promessa de disponibilidade em tempo real, data fixa de lançamento, desempenho, SLA ou escopo de fornecimento comercial.

FAQ

Por que revisar o caminho de integração se o provedor possui um certificado de jogo?

Um certificado de jogo pode abranger apenas um objeto e versão de jogo especificados, enquanto a entrega também envolve um RGS, agregador e plataforma. Um mercado-alvo pode exigir evidência de integração de sistema ou componente; portanto, compare o objeto do relatório com a topologia real.

O suporte a moeda e idioma locais significa que o mercado pode ser atendido?

Não. Eles são dimensões técnicas e de conteúdo. O escopo da entidade operadora, marca ou domínio, os direitos de conteúdo, a versão do jogo, a certificação e as regras de mercado exigem confirmação separada.

Um relatório GLI-19 pode ser usado em todos os mercados?

Isso não pode ser presumido. O GLI-19 é uma base de padrão de laboratório. Se um mercado aceita a evidência, qual objeto e versão ela abrange e se é necessária evidência adicional dependem das regras atuais e do escopo do projeto.

Uma atualização de jogo invalida um certificado antigo?

O número da versão, sozinho, não pode responder. Registre as mudanças reais e, então, use as regras do mercado-alvo, o escopo do relatório e os requisitos do organismo de testes para decidir se são necessários avaliação de impacto, testes suplementares, reemissão ou nova aprovação.

Leituras relacionadas e próximos passos

Antes de usar a seção “Fale conosco”, prepare o mercado-alvo, o escopo da entidade operadora ou da marca, jogos e versões candidatos, topologia de integração, moedas e idiomas. A AG poderá então organizar as evidências específicas do projeto que ainda exigem verificação. Fornecer material ou concluir um teste técnico não constitui promessa de admissão de mercado.

Fontes e escopo

Páginas relacionadas:

Fontes regulatórias primárias e de padrões:

A página UKGC RTS indicava data de atualização de 29 de janeiro de 2026, sua Estratégia de Testes 31 de outubro de 2025 e o índice do FAQ da SPA 21 de maio de 2026. O material citado estava acessível em 9 de agosto de 2026. Regras, organismos reconhecidos e escopos mudam; verifique novamente as fontes primárias antes de uma decisão de projeto.

Precisa transformar estas orientações em um plano de projeto?

Este artigo apoia a avaliação do projeto e não substitui a validação técnica, contratual, de certificação ou da legislação local.

Fale conosco