Data warehouse em iGaming: como não virar refém do PAM

Se amanhã o seu fornecedor de plataforma dobrar o preço, ou se a sua operação comprar uma concorrente, quem é dono do histórico de apostador, aposta e movimento de carteira? Esta é a pergunta que este texto responde, e ela é dirigida a quem decide orçamento de tecnologia e assina contrato de fornecedor em operador licenciado no Brasil — CTO, diretor de operações, head de dados e quem responde por compliance.

PAM não é data warehouse — e confundir os dois custa caro depois

O PAM (Player Account Management) é otimizado para escrever rápido e devolver saldo em milissegundos. Não foi desenhado para responder "qual a margem real por provedor de cassino, líquida de bônus e de taxa de transação, nos últimos 18 meses".

Quando o time de dados roda BI direto na réplica do PAM, a sequência é sempre a mesma: a consulta fica lenta, o fornecedor limita o acesso à réplica, e alguém começa a extrair CSV. A partir daí não existe mais fonte única — existem planilhas com números parecidos e ninguém consegue explicar a diferença na reunião de fechamento.

O ponto não é migrar de plataforma. Isso o portal já tratou em migrar de PAM é o projeto que mais subestimam no setor. O ponto é o que torna a migração barata ou cara: se o operador é dono do próprio histórico ou refém do schema de quem hospeda.

Três camadas, e uma decisão que define tudo

A arquitetura que sobrevive a troca de fornecedor separa o que entra, o que é padronizado e o que é consumido.

A linha do meio é a que decide o futuro. Enquanto o identificador do apostador no data warehouse for o identificador que o fornecedor gerou, trocar de plataforma significa reescrever a base inteira — e perder o encadeamento entre o comportamento de antes e o de depois. Com chave própria, o novo sistema entra como mais uma origem, mapeada contra o cadastro canônico.

Isso deixa de ser discussão teórica quando entra fusão na mesa. Operações de médio porte estão buscando escala para diluir custo de compliance, e toda fusão termina em unificação de base: dois PAMs, dois esquemas de identificação, dois ledgers de carteira, dois históricos de bônus. Quem não tem camada fora do PAM não consegue nem precificar o alvo antes de comprar.

O ledger de carteira é a fonte-verdade — não a tabela de apostas

Erro clássico de primeiro data warehouse: somar o valor apostado para achar o handle e o valor pago para achar o GGR. Não fecha com a contabilidade.

Estorno, aposta anulada, cash-out parcial, freebet, bônus com liberação parcial e ajuste manual de suporte passam pela carteira e não aparecem — ou aparecem distorcidos — na tabela de apostas. O número que reconcilia é o movimento de carteira classificado por tipo. A tabela de apostas serve para entender comportamento, alimentar a segmentação RFM da régua de CRM e medir produto. Não serve para fechar caixa.

Onde está o custo real de cada integração nova

O preço de integrar um provedor não é o revenue share. É a soma de cinco itens que raramente entram na planilha do contrato.

1. Divergência semântica. Cada servidor remoto de jogos define "rodada" à sua maneira: um evento por rodada, agregação por sessão, ou envio só no fechamento — o que quebra o cálculo de free spins que atravessam a meia-noite. Cada provedor novo é uma regra nova de normalização, escrita e mantida por alguém.
2. Fuso e fechamento. Provedor internacional reporta em UTC; o fechamento fiscal e regulatório brasileiro é local. Rodada iniciada às 20h55 e concluída às 21h05 cai em que dia? Se plataforma e data warehouse respondem diferente, existem duas verdades.
3. Idempotência. Callback duplicado é rotina, não exceção. Sem chave de idempotência na ingestão, o GGR infla em silêncio. Sem capacidade de reprocessar uma janela específica, todo bug vira incidente manual.
4. Reconciliação de bônus. É onde as verdades mais divergem: o que o CRM concedeu, o que a carteira debitou como custo e o que o fechamento reconheceu como despesa de marketing. Cada motor de bônus novo é mais um conjunto de regras.
5. Contrato de dados que ninguém escreveu. Quase nenhum contrato de integração define latência máxima do feed, versionamento do payload, aviso prévio de mudança de schema ou direito de exportação do histórico. O fornecedor muda um campo em release noturno, o pipeline quebra e não existe cláusula para acionar.

Não existe padrão de mercado para contrato de dados em iGaming — isso precisa ser dito com todas as letras. O que está descrito acima vem de prática operacional, não de norma. Justamente por isso, é o operador que precisa levar a minuta para a mesa.

A obrigação regulatória recai sobre quem tem a licença

A Portaria SPA/MF nº 722, de 2 de maio de 2024, estabelece regras gerais para o funcionamento dos sistemas de apostas e de fornecimento de dados para o Sigap na operação de apostas de quota fixa. O fornecimento de dados ao Sigap é condição de funcionamento contínua, e os operadores fornecem dados de suas operações por esse sistema desde 1º de janeiro de 2025, início do mercado regulado.

Na comunicação oficial da edição da portaria técnica, o Ministério da Fazenda registrou que o agente operador deverá, a qualquer tempo, conceder pleno acesso aos sistemas de apostas às unidades e agentes de fiscalização da Secretaria de Prêmios e Apostas. A obrigação é do operador autorizado. "O fornecedor envia por mim" não é cumprimento — é dependência.

O agente operador deverá, a qualquer tempo, conceder pleno acesso aos sistemas de apostas para as unidades e agentes de fiscalização da Secretaria de Prêmios e Apostas do Ministério da Fazenda.

Ministério da Fazenda, comunicado sobre o regramento técnico dos sistemas de jogos on-line, maio de 2024

Há ainda a camada de prevenção à lavagem de dinheiro: a Portaria SPA/MF nº 1.143, de 11 de julho de 2024, dispõe sobre políticas, procedimentos e controles internos de PLD/FTP. Monitoramento de PLD sem base histórica consolidada e rastreável não se sustenta em inspeção — e o primeiro ciclo de fiscalização da SPA já indicou que a cobrança não é apenas documental.

O perímetro de certificação limita o desenho

A estrutura brasileira separa certificados por componente, com tratamento distinto para sistema de apostas, sportsbook e servidor remoto de jogos — a redação exata das hipóteses de dispensa deve ser lida na fonte primária, porque muda com portaria nova. A consequência de arquitetura, essa sim, é estável: o data warehouse analítico precisa ser desenhado como consumidor fora do perímetro certificado, lendo de réplica e sem devolver escrita ao sistema de apostas. Data warehouse que escreve de volta no transacional arrasta todo o stack de dados para dentro do escopo de certificação — e cada troca de ferramenta reabre a conversa com a certificadora. Os prazos desse tipo de obrigação estão mapeados no calendário que sustenta sua licença.

Nove passos, na ordem em que funcionam

1. Inventariar fontes antes de escolher ferramenta. PAM, cada agregador de cassino, sportsbook, PSP, motor de bônus, CRM, atendimento e KYC. Para cada um: dono do dado, método de acesso, granularidade e latência real medida — não a prometida.
2. Definir o modelo canônico. Apostador, conta, sessão, rodada, movimento de carteira, evento de bônus, transação. Chaves próprias, documentadas em dicionário de dados versionado.
3. Ingerir por CDC no transacional crítico. Batch por data de atualização perde deleção física e alteração retroativa — é ali que nasce a diferença que ninguém consegue explicar no fechamento.
4. Tornar a reconciliação obrigatória e diária. Fechar contra o PAM em três eixos: saldo agregado de carteira, GGR por produto e total de depósito e saque. Divergência acima da tolerância vira alerta, não relatório mensal.
5. Congelar calendário e fuso. Data de referência do negócio em horário de Brasília, carimbo original preservado em UTC na camada bruta, regra documentada para a rodada que atravessa a virada.
6. Padronizar o onboarding de provedor. Contrato de dados assinado, ambiente de homologação com massa de teste, teste de callback duplicado, teste de estorno e validação do primeiro fechamento em paralelo antes de declarar a integração concluída.
7. Negociar a saída na entrada. Exportação completa em formato aberto, dicionário incluso, janela de acesso após rescisão e custo teto definido.
8. Isolar o data warehouse do perímetro certificado. Consumo por réplica, sem escrita de volta, separação documentada.
9. Só então escolher a stack. O critério prático é quem opera o ambiente às três da manhã do dia do fechamento.

Os erros que aparecem sempre tarde demais

• Usar o identificador do fornecedor como chave primária — o erro que encarece a migração e só é descoberto quando ela começa.
• Chamar réplica de produção com BI em cima de data warehouse.
• Não guardar a camada bruta: quando surge dúvida sobre uma rodada específica, só existe o dado já transformado, e transformação tem bug.
• Tratar bônus como desconto. Bônus tem ciclo de vida — concessão, retenção, liberação, expiração, conversão. Modelado como campo único, destrói o cálculo de custo de aquisição e de margem.
• Importar apenas os últimos meses na migração. Economiza semanas no projeto e elimina análise de coorte e de valor de longo prazo, de forma irreversível.
• Colocar o jogo no lobby sem homologar o fechamento — a receita entra e, três meses depois, alguém descobre que a rodada nunca fechou direito.

O que medir a partir da semana que vem

Uma nota de campo que evita retrabalho: a orientação técnica da SPA registra que campos sem valor aplicável devem ser informados inicialmente como zero para fins de Sigap. Detalhe pequeno, rejeição de arquivo garantida quando ignorado.

Este texto não traz faixa de preço de licença de plataforma nem duração média de migração porque não há fonte pública confiável para esses números no mercado brasileiro. Preencher com estimativa seria mais confortável e menos útil. O que se sustenta com fonte é o regime de obrigação e a lógica de arquitetura — e é sobre isso que a decisão de orçamento precisa ser tomada. A mesma disciplina de medição vale para outras camadas da operação, como mostra o caso da latência de feed de odds, que virou vantagem competitiva e quase ninguém mede.

A pergunta com que este artigo abriu tem uma versão curta para levar à diretoria: se o contrato com o fornecedor de plataforma terminasse em noventa dias, quanto do histórico da operação sairia de lá em formato utilizável? Se ninguém souber responder com precisão, o projeto de camada de dados própria já está atrasado.