Integração KYC para Loteria: Estados, Dados e Revisão Manual
Uma integração KYC para loteria deve transformar as decisões de um fornecedor de verificação em permissões claras e controladas para a conta do jogador. Defina o modelo de estados, o processo de revisão manual, o tratamento de atualizações e os limites de dados antes de conectar a primeira tela de verificação. Concluir um envio de […]
Uma integração KYC para loteria deve transformar as decisões de um fornecedor de verificação em permissões claras e controladas para a conta do jogador. Defina o modelo de estados, o processo de revisão manual, o tratamento de atualizações e os limites de dados antes de conectar a primeira tela de verificação. Concluir um envio de documentos não é o mesmo que aprovar um solicitante.
Este guia aborda requisitos técnicos e operacionais, não orientações jurídicas específicas de uma jurisdição nem documentação real da API WhiteLotto. O operador responsável e seus assessores devem definir as verificações aplicáveis e as ações permitidas na conta. O guia da jornada KYC considera a experiência do jogador junto a esses controles.
Mapeie os estados do fornecedor para as decisões do operador
Mantenha separados o status do fluxo de trabalho do fornecedor, o resultado da decisão e as permissões internas da conta. “Concluído” pode descrever uma revisão encerrada com aprovação ou rejeição. “Requer ação” pode indicar a necessidade de outro documento, em vez de uma recusa definitiva.
| Estado interno | Significado a definir | Ação do operador |
|---|---|---|
| Não iniciado | Nenhuma jornada de verificação exigida foi iniciada. | Mostrar a próxima etapa aplicável e as restrições configuradas. |
| Aguardando o solicitante | São necessárias informações ou um novo envio. | Apresentar uma solicitação segura e clara, sem expor a lógica interna de risco. |
| Revisão pendente | O fornecedor ou revisor ainda não chegou a uma decisão utilizável. | Preservar o status pendente; não aprovar silenciosamente por tempo esgotado. |
| Revisão manual | É necessária uma decisão humana autorizada. | Definir responsável, limite de acesso e caminho de escalação. |
| Aprovado | As verificações acordadas foram aprovadas para o nível e momento pertinentes. | Aplicar somente as permissões autorizadas pela política do operador. |
| Rejeitado ou restrito | Um resultado definitivo ou uma restrição posterior exige ação. | Aplicar restrições controladas e a comunicação permitida ao cliente. |
A documentação de status de solicitantes da Sumsub ilustra a diferença entre uma revisão concluída, uma aprovação e uma rejeição que permite nova tentativa. Esse é o exemplo de um fornecedor, não uma afirmação de que a WhiteLotto utiliza a Sumsub ou tem estados idênticos.
Torne as atualizações seguras, inclusive as mudanças de decisão
Vincule a referência do solicitante ao jogador e ao nível de verificação corretos. Valide a origem do evento pelo mecanismo documentado do fornecedor. Armazene metadados suficientes do evento para detectar duplicidades e investigar horários, sem colocar documentos de identidade nos logs de rotina.
Um solicitante pode receber uma decisão posterior à primeira conclusão. O guia de resultados da Sumsub descreve eventos definitivos posteriores e a recuperação de entregas não recebidas. Acorde como a integração determina a decisão atual, trata atualizações antigas e reavalia permissões após uma mudança legítima. Uma aprovação mantida permanentemente em cache não constitui um modelo de estados completo.
Crie uma rota de recuperação suportada para notificações ausentes. Use uma consulta de status ou um reprocessamento do fornecedor como alternativa prevista no contrato real, em vez de consultar continuamente todos os solicitantes sem um motivo. Conecte esse desenho à arquitetura principal de integração.
Minimize os dados copiados para a plataforma
Identifique as informações necessárias a cada sistema: referência do fornecedor, decisão, nível de verificação, horários relevantes e códigos de motivo permitidos podem atender um fluxo sem copiar todos os documentos enviados. Defina quem pode acessar o painel do fornecedor, o que é retido localmente e como as instruções de exclusão ou retenção são propagadas.
Use solicitantes fictícios no desenvolvimento e nas demonstrações. Não peça que funcionários enviem passaportes reais para um ambiente de testes não aprovado. Aplique acesso baseado em funções à revisão manual e mantenha identificadores sensíveis fora de URLs, eventos de análise e ferramentas gerais de acompanhamento de erros. Resolva os direitos contratuais separadamente usando o guia de propriedade dos dados de jogadores.
Defina o tratamento manual antes do lançamento
Identifique o revisor, o responsável pela escalação e as ações permitidas para casos ambíguos. Especifique o tratamento de contas duplicadas, identificadores incompatíveis, fornecedores indisponíveis e verificações reabertas. Separe uma falha técnica de integração de uma decisão negativa de verificação, para não informar incorretamente ao cliente que ele foi reprovado.
A equipe de suporte precisa de mensagens seguras, referências de casos e um caminho até um revisor autorizado — não de acesso irrestrito a documentos. Acorde as expectativas operacionais e o tempo em aberto das exceções na checklist de suporte e SLA.
Casos de aceite da integração KYC
- Novo solicitante, aprovação, novo envio, rejeição definitiva e revisão manual.
- Eventos duplicados, atrasados e fora de ordem para o mesmo solicitante.
- Uma decisão posterior que altera as ações permitidas de uma conta existente.
- Indisponibilidade do fornecedor, notificação ausente e recuperação controlada.
- Referência de jogador incorreta, revisor não autorizado e acesso a dados restritos.
- Mensagens localizadas ao cliente e jornadas de verificação utilizáveis no celular.
Para cada caso, registre o resultado do fornecedor, o estado interno, a permissão da conta e a evidência de auditoria. Inclua a configuração exata nos testes UAT e acompanhe o tempo em aberto da fila com o modelo de KPIs do operador.
Perguntas frequentes sobre integração KYC
Um resultado aprovado do fornecedor estabelece conformidade completa?
Não. A verificação é um controle dentro das obrigações e da política operacional mais amplas do operador. A conexão técnica não pode determinar todos os requisitos jurídicos aplicáveis.
A equipe pode aprovar casos técnicos não resolvidos?
Somente pelo processo de revisão autorizado do operador. Uma resposta ausente não deve virar uma aprovação automática nem uma forma improvisada de contornar os controles.
Apresente suas jornadas de verificação, os responsáveis pelas decisões e os limites de dados à WhiteLotto. CONTATO.