Notícias do setor
Verificação de identidade e comprovação de idade em iGaming: requisitos de plataforma
Uma conta em uma plataforma regulada de iGaming é protegida por duas verificações que são constantemente confundidas entre si. A comprovação de idade responde se esta pessoa pode jogar. A verificação de identidade responde quem é esta pessoa, para que a conta, o dinheiro e o registro regulatório se vinculem ao mesmo ser humano. Nenhuma substitui a outra, e uma plataforma que implementa bem uma delas ainda pode falhar na outra, porque a evidência de que cada uma precisa não é a mesma evidência.
Para o responsável de conformidade, o arquiteto de plataforma ou o fornecedor de identidade de um operador, o artefato de entrega é um pacote de controle de verificação: a obrigação que dispara a verificação, o nível de garantia que ela deve alcançar, a classe de evidência que pode aceitar, a regra temporal que decide quando ela roda, o registro que prova que rodou e o comportamento definido para cada desfecho que não seja uma aprovação limpa.
A comprovação de idade e a verificação de identidade respondem a perguntas diferentes
O código de responsabilidade social 3.2.11 da Grã-Bretanha para operadores remotos exige que os titulares tenham e apliquem procedimentos que verifiquem a idade de um cliente antes que esse cliente possa depositar fundos, acessar versões gratuitas de jogos de azar ou jogar com dinheiro próprio ou com qualquer aposta ou bônus gratuito. Vale notar o que essa lista contém: uma versão gratuita de um jogo está dentro do limite. Uma superfície que os times de produto tratam como marketing fica atrás de uma barreira de idade do mesmo modo que uma carteira de dinheiro real.
A condição de licença 17.1.1 pede outra coisa. Os titulares devem obter e verificar informações para estabelecer a identidade de um cliente antes que ele seja autorizado a jogar, e essas informações devem incluir nome, endereço e data de nascimento. Uma obrigação é um predicado de limite sobre a idade; a outra é um registro de identidade com três componentes. Uma única “etapa de KYC” no fluxo de caixa costuma satisfazer a segunda e presumir silenciosamente a primeira.
As duas obrigações também têm escopo definido, e esse escopo faz parte do projeto. A 3.2.11 se aplica a todas as licenças remotas, exceto licenças de loteria, técnicas de máquinas de jogo, software de jogo, host e licenças acessórias de cassino e bingo remotos; a 17.1.1 tem suas próprias exceções declaradas, incluindo licenças de loteria que só oferecem loterias de baixa frequência ou por assinatura. A lógica de verificação precisa ser, portanto, uma decisão por licença e não um interruptor global. Um fornecedor que fixa “verificar sempre” para um cliente encontra a lista de exceções quando a classe de licença do segundo cliente é auditada.
Escolha um nível de garantia e depois o caminho de evidência
Marcos de comprovação de identidade descrevem níveis antes de descrever métodos. A SP 800-63A-4 do NIST, publicada em versão final em 31 de julho de 2025 e que substitui a SP 800-63A, define requisitos técnicos para três níveis de garantia de identidade e trata o nível como a decisão que a organização toma. O marco britânico de serviços de verificação digital tem o mesmo formato: a Data (Use and Access) Act 2025 criou um registro legal de prestadores de serviços de verificação digital, e o marco de confiança que o sustenta define níveis de confiança.
A consequência para a engenharia é que o nível de garantia decide quais caminhos de evidência são admissíveis. Um nome consultado em uma base de referência, uma imagem de documento conferida com uma prova de vivacidade e uma comparação supervisionada entre pessoa e documento são classes diferentes de evidência, e nenhuma pontuação de risco transforma uma classe mais fraca em uma mais forte. Escreva o nível pretendido por verificação, escolha em seguida a evidência e registre qual caminho realmente rodou. Quando um revisor pergunta por que uma conta foi verificada, “o fornecedor retornou aprovado” não é um registro de caminho de evidência.
Mantenha também as três perguntas separadas no modelo de dados: se esta pessoa tem idade suficiente, se esta pessoa é quem diz ser e se a sessão à nossa frente continua sendo essa pessoa. Elas carregam custos de falha diferentes e gatilhos de reverificação diferentes, e o guia de controle de acesso ao back office cobre o lado de privilégios da terceira pergunta.
Verifique antes que o valor se mova, não na tela de saque
O momento é onde um projeto defensável normalmente se perde. A condição 17.1.1 estabelece que um pedido de saque de um cliente não pode resultar na exigência de informações adicionais como condição para o saque se o titular poderia razoavelmente ter pedido essas informações antes. Essa frase é uma instrução de arquitetura: a verificação pertence ao ponto em que a conta adquire valor ou antes dele, não ao momento em que o jogador pede o dinheiro de volta.
O regulamento da UE diz o mesmo pelo outro lado. O Regulamento (UE) 2024/1624, a norma antilavagem de dinheiro do pacote de 2024 que se aplica diretamente a partir de 10 de julho de 2027, exige no artigo 23 que a verificação da identidade do cliente e do beneficiário efetivo ocorra antes do estabelecimento de uma relação de negócio ou da realização de uma transação ocasional. A derrogação do mesmo artigo permite concluí-la durante o estabelecimento apenas quando for necessário para não interromper o curso normal dos negócios e houver baixo risco de lavagem de dinheiro ou financiamento do terrorismo, e exige que esses procedimentos sejam concluídos o mais rápido possível após o contato inicial. É uma exceção estreita com uma condição documentada, não uma licença geral para terminar depois.
Um projeto que estaciona a verificação na etapa de saque, portanto, faz duas coisas ruins ao mesmo tempo. Enfraquece a própria evidência da plataforma, porque o histórico da conta foi construído por uma pessoa cuja identidade o operador nunca estabeleceu; e transforma uma etapa de cadastro em um incidente de experiência do cliente no momento mais sensível da relação.
Trate os limites como configuração versionada
Requisitos de idade e identidade raramente são regras de “sempre”. São regras de limite e gatilho que se movem em um calendário. Pelo regulamento antilavagem, os prestadores de serviços de jogo devem aplicar a diligência devida não só ao estabelecer uma relação, mas também no recebimento de ganhos, na aposta de um valor ou em ambos, ao realizar transações de pelo menos 2 000 EUR ou o equivalente, seja em uma única operação ou por meio de transações vinculadas. O artigo 19(9) exige então que a autoridade antilavagem da UE elabore projetos de normas técnicas de regulamentação que especifiquem valores menores para entidades e transações de maior risco, os valores de transação correspondentes, os critérios para identificar transações ocasionais e relações de negócio, e os critérios para identificar transações vinculadas. Esses critérios decidem se duas apostas de uma mesma pessoa são uma transação ou duas, o que é uma questão de modelagem de dados antes de ser uma questão de conformidade.
As normas técnicas da Grã-Bretanha se movem em calendário próprio. As normas técnicas de jogo remoto e software da Gambling Commission trazem uma mudança com efeito a partir de 30 de setembro de 2026 na RTS 12B, a norma de limites financeiros, incluindo o requisito de que o sistema de jogo impeça o cliente de continuar depositando quando um limite de depósito é atingido, até que o período definido reinicie ou o cliente tome a ação de aumentá-lo, sujeito ao período padrão de reflexão de 24 horas.
A lição de projeto não é qual número está certo neste mês. É que limites, eventos de disparo, janelas de vinculação e períodos de reflexão pertencem a uma configuração versionada com registro de qual versão estava ativa quando uma decisão específica foi tomada. Uma plataforma que publica limites como constantes relança software toda vez que um regulador move um valor, e não consegue dizer depois quais regras governaram uma decisão tomada três anos antes.
Aceite as credenciais que seus mercados vão exigir
A Europa está construindo uma camada de identidade baseada em carteiras, e a obrigação de aceitação tem data. O Regulamento (UE) 2024/1183 exige, no artigo 5a, que cada Estado-Membro forneça pelo menos uma Carteira Europeia de Identidade Digital nos 24 meses seguintes à entrada em vigor dos atos de execução, com nível de garantia alto e capacidade de divulgação seletiva, de modo que a carteira possa apresentar um fato sem apresentar o documento de onde ele veio. O artigo 5f(2) exige que as partes confiantes privadas, exceto microempresas e pequenas empresas conforme a recomendação citada, que sejam obrigadas pelo Direito da União ou nacional, ou por obrigação contratual, a usar autenticação forte de usuário para identificação on-line, aceitem também essas carteiras, no prazo máximo de 36 meses a partir da entrada em vigor desses atos de execução e apenas a pedido voluntário do usuário. As áreas que o artigo lista como exemplos são transporte, energia, serviços bancários, serviços financeiros, segurança social, saúde, água potável, serviços postais, infraestrutura digital, educação e telecomunicações. O jogo não está lá, então a posição de um operador depende de uma norma ou contrato que o vincule exigir autenticação forte de usuário, e essa é uma pergunta a responder por mercado, não por suposição.
Duas propriedades do marco moldam a integração mais do que a data. O artigo 5a(15) estabelece que o uso das carteiras é voluntário e que o acesso a serviços públicos e privados não deve ser restringido nem se tornar desvantajoso para quem não as usa, o que significa que o caminho documental existente não pode ser retirado como se fosse uma conveniência. E o artigo 5a(4) exige divulgação seletiva, então o pedido que a plataforma envia deve solicitar um predicado sobre a idade e não uma data de nascimento, e deve solicitar atributos de identidade apenas quando uma obrigação realmente precisar deles. Um caixa que exige um conjunto completo de atributos quando a obrigação é um limite de idade construiu uma integração de carteira mais difícil de defender em uma revisão de proteção de dados e pior para o jogador.
O Reino Unido seguiu outro caminho para o mesmo destino, e seu mecanismo é instrutivo porque é explicitamente condicional. A Licensing Act 2003 (Mandatory Licensing Conditions) (Amendment) Order 2026 permite que estabelecimentos licenciados na Inglaterra e no País de Gales aceitem identificação digital para verificações de idade, mas apenas quando a pessoa responsável estiver coberta por um acordo com um prestador registrado no registro legal de serviços de verificação digital, o prestador confirmar se o limite de idade foi atingido e a identificação entregue alcançar pelo menos um nível médio de confiança conforme a versão correspondente do marco de confiança. O material explicativo publicado é explícito ao afirmar que uma mera inspeção visual de um documento digital não é suficiente. Esse é o formato de uma verificação de idade apta para conformidade: um verificador registrado, um nível de confiança declarado e um serviço que responde diretamente à pergunta da idade em vez de entregar uma imagem.
Retenha a evidência, não apenas a decisão
Decisões de verificação envelhecem mal quando a evidência por trás delas não é retida. O artigo 77(1)(a) do regulamento antilavagem exige que as entidades obrigadas retenham uma cópia dos documentos e informações obtidos na aplicação da diligência devida, incluindo informações obtidas por meios de identificação eletrônica, e garantam que os registros retidos não estejam tarjados. O artigo 77(2) permite reter referências a essas informações em vez de cópias, mas apenas quando a natureza e o método de retenção permitam fornecer as informações imediatamente às autoridades competentes e as informações não possam ser modificadas ou alteradas, e apenas quando as categorias em que essa substituição se aplica estiverem definidas nos procedimentos internos da própria entidade. O artigo 77(3) fixa um período de retenção de cinco anos contado do encerramento da relação de negócio, da transação ocasional ou da recusa, exige a exclusão dos dados pessoais quando esse período expira e permite uma prorrogação caso a caso de até mais cinco anos quando uma autoridade competente precisar.
Isso é uma especificação, não uma instrução geral de guardar tudo. A plataforma precisa armazenar a evidência de verificação de uma forma que um revisor possa usar, provar que ela não foi alterada, fornecê-la imediatamente quando reteve uma referência em vez de uma cópia e excluí-la em um relógio definido sem apagar registros que outra obrigação exige. A retenção é também onde o sistema de identidade encontra o pacote de controle de registro de segurança e evidência de auditoria, porque uma regra de retenção que nada aplica é uma exposição de proteção de dados e não um controle.
Reverifique por mudança, não por calendário
A condição 17.1.1 exige que os titulares tomem medidas razoáveis para garantir que as informações que mantêm sobre a identidade de um cliente continuem precisas. O regulamento antilavagem dispara nova diligência devida quando há dúvidas sobre a veracidade ou a suficiência dos dados de identificação obtidos anteriormente, e quando há dúvidas sobre se a pessoa com quem a entidade interage é o cliente ou uma pessoa autorizada a agir por ele.
Três gatilhos práticos decorrem disso. Um evento de mudança relevante — mudança de nome, novo endereço, instrumento de pagamento em outro nome — deve abrir uma tarefa de reverificação em vez de sobrescrever silenciosamente o registro estabelecido. Uma sessão que se comporta como outra pessoa deve ser tratada como uma nova pergunta de autenticação, com o caminho de tomada de conta que o plano de resposta a incidentes define para comprometimentos confirmados. E a fraude de identidade deve ser presumida pelo menos tão bem equipada quanto a plataforma: a avaliação de 2026 da Gambling Commission sobre os riscos de lavagem de dinheiro e financiamento do terrorismo na indústria britânica de jogos, publicada em 30 de julho de 2026, observa que o rápido desenvolvimento da capacidade de inteligência artificial testa a eficácia dos controles de diligência devida, e classifica o setor de cassino como alto em relação a outros subsetores de jogos, embora a avaliação nacional de riscos classifique os cassinos como médio no conjunto dos setores regulados.
Teste as falhas, não apenas o caminho feliz
A aceitação de um sistema de idade e identidade deve ser uma lista de contradições, cada uma com um estado esperado da plataforma, um comportamento visível esperado para o jogador e um registro esperado. Comece por um solicitante cujo documento expira entre a captura e a verificação, e outro cujo endereço mudou desde a emissão do documento. Continue com um nome que não corresponde aos dados de referência e um nome que corresponde apenas aproximadamente. Depois os caminhos de credencial: uma carteira que retorna um predicado de idade sem nenhum atributo de identidade, um usuário de carteira que recusa o atributo e continua navegando, e um usuário que apresenta uma segunda carteira depois que a primeira foi revogada. Depois as contradições da própria plataforma: a mesma identidade apresentada contra uma segunda conta, um fornecedor de verificação que expira depois de aceitar a solicitação, um registro de identidade editado após a conclusão da verificação, um saque tentado em uma conta cuja verificação foi adiada e um relógio de retenção que expira enquanto uma revisão ainda está aberta.
Cada teste deve indicar o estado que a plataforma precisa alcançar, a evidência que deve deixar e a pessoa responsável pela classe de exceção. Um controle de verificação que nunca foi forçado a um estado contraditório não foi testado; apenas foi usado.
Para operadores e fornecedores que especificam comprovação de idade e verificação de identidade, o desenvolvimento de plataformas da Wizards transforma este pacote de controle em requisitos de plataforma, de fornecedor e de aceitação.
Perguntas frequentes
A comprovação de idade é o mesmo que a verificação de identidade em uma plataforma de iGaming?
Não. Na Grã-Bretanha, o código de responsabilidade social remoto 3.2.11 exige que a idade seja verificada antes que o cliente possa depositar, acessar uma versão gratuita de um jogo de azar ou jogar, enquanto a condição de licença 17.1.1 exige que nome, endereço e data de nascimento sejam obtidos e verificados antes de o cliente ser autorizado a jogar. Uma é um limite sobre a idade; a outra é um registro de identidade, e a evidência que satisfaz uma não satisfaz automaticamente a outra.
Quando um operador remoto deve verificar a identidade de um cliente?
Antes de permitir que ele jogue, pela condição de licença 17.1.1, e essa mesma condição afirma que um pedido de saque não pode se tornar a primeira vez em que informações adicionais são exigidas se elas poderiam razoavelmente ter sido pedidas antes. O Regulamento (UE) 2024/1624 adota a mesma posição nos mercados que cobre: a verificação ocorre antes de a relação de negócio ser estabelecida ou a transação ocasional ser realizada, com apenas uma derrogação estreita e condicionada para concluí-la durante o estabelecimento.
O regulamento europeu antilavagem se aplica a operadores de jogos on-line?
Sim, e acrescenta eventos que não são eventos de cadastro. O Regulamento (UE) 2024/1624 se aplica diretamente a partir de 10 de julho de 2027, define os serviços de jogo no nível da UE pela primeira vez e exige que seus prestadores apliquem a diligência devida no recebimento de ganhos, na aposta de um valor ou em ambos, quando as transações alcançarem 2 000 EUR, seja em uma única operação ou por meio de transações vinculadas. Os Estados-Membros podem isentar alguns prestadores por risco baixo comprovado, mas a isenção não pode ser usada para cassinos nem para prestadores cuja atividade principal seja jogos on-line ou apostas esportivas.
O que uma plataforma precisa reter para provar que houve uma verificação?
Pelo artigo 77 do Regulamento (UE) 2024/1624, uma cópia dos documentos e informações obtidos na aplicação da diligência devida — incluindo informações obtidas por meios de identificação eletrônica — mantida sem tarja, ou uma referência a ela quando as regras de retenção permitirem fornecimento imediato e as informações não puderem ser alteradas. O período de retenção é de cinco anos a partir do fim da relação, da transação ocasional ou da recusa, após o que os dados pessoais devem ser excluídos, com possível prorrogação caso a caso de até cinco anos adicionais.
Uma plataforma de jogos deve aceitar a Carteira Europeia de Identidade Digital?
Somente quando a obrigação realmente se aplicar, e então a pedido voluntário do usuário. O artigo 5f(2) do Regulamento (UE) 2024/1183 obriga certas partes confiantes privadas que precisam usar autenticação forte de usuário para identificação on-line a aceitar as carteiras; o jogo não é um dos setores citados na lista ilustrativa, então a resposta depende do Direito nacional ou do contrato que vincula o operador. Dois requisitos valem de todo modo: o uso de uma carteira é voluntário e quem não a usa não pode ser prejudicado, e a plataforma deve solicitar um atributo de divulgação seletiva, como um predicado de idade, em vez de um documento de identidade completo.