Este artigo apresenta um método de avaliação e governança de projeto. Não constitui orientação jurídica nem substitui a revisão profissional do mercado-alvo.

Resposta direta

“A API retorna o jogo”, “a moeda ou o idioma é aceito” e “existe um relatório de laboratório” não comprovam, isoladamente, que um jogo possa entrar em operação em determinado mercado. A unidade mínima de análise é:

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

Uma mudança no jogo, modelo matemático, RGS, agregador, plataforma, entidade, marca ou domínio pode invalidar uma conclusão anterior. A matriz não cria um selo de “legal no mundo todo”; ela relaciona cada decisão a objetos, limites, evidências atuais e responsáveis.

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

Dimensão Pergunta obrigatória Erro frequente
Mercado Qual país ou âmbito regulatório, entidade, marca e domínio? Tratar “global” ou “América Latina” como escopo executável
Jogo Qual código do fornecedor e ID estável do catálogo? Relacionar apenas por nome ou skin
Versão Quais versões de jogo, modelo, RGS, agregador e plataforma? Considerar equivalentes todas as versões com o mesmo nome
Certificação Quem avaliou qual objeto, requisito e escopo, e qual é o estado atual? Tratar padrão ou relatório como passe global
Moeda Quais moedas e precisões são usadas na exibição, aposta, liquidação e relatório? Confundir suporte técnico com autorização de mercado
Idioma Quais idiomas cobrem regras, ajuda, interface e comunicação operacional? Concluir aptidão de mercado apenas pela tradução

Idioma, moeda e integração técnica são dimensões necessárias, mas não equivalem à aptidão de mercado. A autorização de uma entidade também não comprova automaticamente cada jogo, versão e topologia.

Processo de validação em camadas

1. Conectividade técnica

Confirme versões das interfaces entre provider, RGS ou agregador e plataforma; identidade, modelo de carteira, callbacks, rodadas e transações no ambiente definido. Isso comprova interação técnica do objeto testado, não direitos de conteúdo ou mercado.

2. Identidade e versão do conteúdo

Identifique o jogo pelo código do fornecedor, registrando versão, modelo matemático, build do cliente, nota de mudança e data. Não reutilize conclusões entre skin, clone ou jogo semelhante sem evidência.

3. Idioma e moeda

Valide separadamente interface, regras, ajuda, precisão da aposta e liquidação, relatórios e exceções. Aprovação funcional de idioma ou moeda não aprova a dimensão de mercado.

4. Objeto e escopo da certificação

Registre relatório ou certificado, instituição, requisito, objeto, versão, topologia, validade e gatilho de novo teste. Confirme se a instituição e o serviço específico são aceitos no mercado no momento da decisão.

5. Entidade e mercado

Os responsáveis adequados devem revisar regra aplicável, entidade operadora, marca, domínio, direitos de conteúdo, restrições e registros oficiais atuais. Marketing genérico não substitui avaliação por projeto.

6. Decisão do projeto

Tecnologia, conteúdo, certificação, negócio e conformidade aprovam seus próprios escopos. Somente com todas as evidências necessárias a linha recebe approved_for_project; ainda assim, a conclusão não é permanente nem global.

Modelo de matriz

Cada linha deve representar uma combinação. Dois modelos matemáticos ou versões de RGS exigem linhas separadas.

Grupo Campos recomendados Regra de preenchimento
Projeto market_code, operator_entity, brand, domain_scope Nomeie objetos concretos, não “global”
Jogo provider_id, provider_game_code, catalog_record_id Use IDs estáveis
Versões game_version, math_model_version, rgs_version, aggregator_version, platform_version Reavalie impacto a cada mudança
Certificação certificate_or_report_id, test_body, requirements_ref, tested_object, scope, status Registre cobertura, não só o PDF
Localização currency_code, language_code, rules_language Separe validação técnica e de conteúdo
Evidência evidence_ref, issued_at, last_verified_at, next_review_at Preserve fonte e data
Decisão decision_status, conditions, owner, approved_at Limite ao projeto da linha

Estados recomendados:

  • evidence_missing: falta objeto ou fonte crítica;
  • pending_review: material recebido, ainda sem aprovação do responsável;
  • conditional: avanço permitido somente sob condições registradas;
  • approved_for_project: aprovação limitada à combinação da linha;
  • expired_or_recheck: vencimento ou mudança exige nova análise;
  • withdrawn: decisão retirada, com histórico preservado.

Evite um booleano genérico legal, certified ou available.

Exemplo com fontes primárias do Brasil

Os pontos abaixo ilustram o método; não aprovam nenhum projeto:

  • As questões técnicas da SPA distinguem objetos de evidência como sistema de apostas, RGS ou agregador, integrações entre plataforma, RGS/agregador e fornecedor, jogos e estúdios ao vivo. Registre cada objeto e cadeia separadamente.
  • A questão 71 trata evidências de conformidade para jogos, skins ou clones e certificados de integração; a mesma fonte explica que não há uma lista pública única da SPA que substitua a validação do projeto. Preserve relatório e escopo para cada jogo ou agrupamento aplicável.
  • A questão 94 inclui componentes como RGS e agregador na discussão de certificação da integração. Trocar componente ou versão exige reavaliar a cobertura.
  • A questão 84 aborda o idioma das informações ao apostador. A existência de português deve entrar na matriz, mas não comprova entidade, versão ou topologia.
  • A instituição certificadora e seu escopo específico devem ser verificados na lista atual da SPA. Estar na lista não torna todos os relatórios da instituição aplicáveis a qualquer objeto.

Fontes específicas: questão 71, questão 84, questão 94 e entidades certificadoras.

UKGC e GLI: padrão, teste e decisão de mercado são diferentes

A UK Gambling Commission publica padrões técnicos remotos e uma estratégia de testes que organiza procedimentos, testes anuais, monitoramento de RTP e atualizações. O tratamento de mudanças depende da regra atual do mercado e do tipo de alteração; a AG não pode fornecer uma regra global única.

O GLI-19 pode servir como referência técnica de laboratório, mas não equivale automaticamente à aceitação em uma jurisdição. Separe “padrão utilizado” de “evidência aceita no mercado-alvo”.

Mudanças que exigem nova análise

Mova a linha para expired_or_recheck quando mudar:

  • programa, modelo matemático, RNG ou regra do jogo;
  • RGS, agregador, plataforma ou interface crítica;
  • modelo de carteira, fluxo de transação, precisão da moeda ou idioma do jogador;
  • objeto do relatório, reconhecimento da instituição ou validade da evidência;
  • entidade, marca, domínio, direitos de conteúdo ou regra do mercado.

Classificações como “mudança principal” ou “secundária” devem vir da regra atual, do escopo da instituição e dos materiais da alteração — não apenas do número de versão.

Nota não verificada sobre RTP 0–1000 A faixa precisa ser interpretada com unidade, significado numérico, versão do modelo matemático, permissões, evidências de teste e certificação, mercado e forma de apresentação. Ela não comprova o RTP de um jogo ou versão de mercado e não promete resultado por sessão ou para qualquer jogador.

Escopo atual e limites

O artigo oferece um método de validação. O catálogo atual é um snapshot nominal e não preenche a matriz. A referência pública ajuda a delimitar a cadeia técnica, mas protocolo, acesso e versões de production ainda precisam de confirmação. Os exemplos SPA, UKGC, GLI e a nota de RTP 0–1000 não significam certificação ou acesso a mercado.

Não se promete autorização, certificação, disponibilidade em tempo real, prazo, desempenho, SLA ou escopo comercial de nenhum fornecedor, jogo ou versão. Regras e reconhecimentos devem ser verificados novamente na decisão do projeto.

Perguntas frequentes

Por que verificar a integração se existe certificado do jogo?

O certificado pode cobrir apenas objeto e versão específicos, enquanto a entrega passa por RGS, agregador e plataforma. O mercado pode exigir evidência da combinação.

Idioma e moeda locais comprovam aptidão para o mercado?

Não. Entidade, marca, domínio, direitos, versão, certificação e regras continuam separados.

Um relatório GLI-19 vale em qualquer mercado?

Não se pode presumir. Aceitação, objeto, versão e evidências adicionais dependem da regra atual e do projeto.

Um upgrade preserva automaticamente o certificado anterior?

Não. Registre a mudança e confronte-a com a regra do mercado, o escopo do relatório e a orientação da instituição de teste.

Leituras relacionadas e próximo passo

Ao usar “Fale conosco”, informe mercado, entidade ou marca, jogos e versões, topologia, moeda e idioma. A organização das evidências não representa aprovação de mercado.

Fontes e datas

As fontes primárias são as questões técnicas da SPA, a lista de entidades certificadoras da SPA, os padrões técnicos e a estratégia de testes da UKGC e os padrões da GLI. As páginas foram consultadas no contexto da revisão de 2026-08-09. Regras e escopos mudam; verifique-os novamente antes de decidir.

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