Revenue leakage em comissões ocorre quando regras desatualizadas rodam em produção. Veja como a centralização eliminou o problema na Midway Riachuelo.
Comissões
# Revenue leakage em comissões: como a centralização de regras eliminou o problema
Comece pelo número que ninguém gosta de calcular.
Pega uma carteira de apólices ativas. Multiplica pelo prêmio médio. Aplica a alíquota de comissão que deveria estar vigente. Agora compara com o que foi efetivamente pago nos últimos seis meses. A diferença entre esses dois números tem um nome técnico: revenue leakage. A causa mais comum desse vazamento, em operações de seguro com volume relevante, não é fraude nem erro humano intencional. É regra desatualizada rodando em produção sem que ninguém tenha percebido.
O case da Midway Riachuelo ilustra o problema com uma clareza que vale examinar em detalhe, porque o que aconteceu ali não é exceção de seguradora grande. É o padrão de qualquer operação que cresceu rápido sem separar a lógica de comissionamento da camada de código.
Midway é a financeira do Grupo Riachuelo, com operações em crédito, seguros e meios de pagamento para uma base de clientes que alcança dezenas de milhões de portadores do cartão Riachuelo. Quando a operação de seguros escala nessa velocidade, a pressão sobre a engenharia de comissionamento cresce na mesma proporção: novos canais de distribuição, novas vigências, novas coberturas, ajustes de alíquota por produto, por ramo, por parceiro.
O problema central não era falta de sistema. As regras que determinavam quanto cada intermediário recebia estavam distribuídas em múltiplos pontos, com versões diferentes convivendo em produção ao mesmo tempo. Uma alteração de critério em um canal levava semanas para se propagar para todos os contextos onde aquela regra era aplicada. Em alguns casos, não se propagava.
Regra descentralizada tem dois custos. O imediato: o ticket de TI para cada mudança. O diferido: a divergência acumulada entre o que a política de comissões diz e o que o sistema executa. O custo diferido é mais caro porque aparece depois, quando a reconciliação financeira tenta fechar o período e os números não batem.
O time de tecnologia vive essa situação como problema de capacidade: não consigo atender todos os tickets. O time financeiro vive como problema de confiabilidade: não consigo fechar o mês sem discrepância. A causa raiz é a mesma: regra de negócio acoplada ao código, sem camada de controle dedicada.
Uma regra de comissionamento é alterada numa reunião de negócio. A nova alíquota entra numa planilha de configuração ou num documento interno. Um ticket é aberto para TI. O ticket entra no backlog. O backlog tem prioridade competindo com feature development, correções de produção e outros ajustes de regra também aguardando. A sprint fecha. O ticket pode ou não ter sido concluído. Se foi, o deploy acontece num subconjunto dos ambientes onde aquela regra opera. Se não foi, a regra antiga continua vigente.
Durante o intervalo entre a decisão de negócio e o deploy efetivo, toda transação processada com a regra antiga gera uma distorção. Para uma carteira processando 50 mil apólices por mês com prêmio médio de R$ 80 e comissão com divergência de 2 pontos percentuais, isso representa R$ 80.000 por mês em pagamento incorreto. Com um ciclo de ajuste que leva 45 dias da decisão ao deploy, o acúmulo passa de R$ 100 mil antes da correção chegar a produção.
Em operações maiores, com mais canais e mais variáveis de comissionamento, a divergência por linha de produto é proporcionalmente maior. O mecanismo, no entanto, é idêntico: tempo entre decisão e execução, multiplicado pelo volume, multiplicado pela diferença percentual.
O que torna esse leakage particularmente difícil de rastrear é que ele não aparece como erro. O sistema processa corretamente segundo a regra que tem em produção. A divergência só é detectável quando alguém compara o output do sistema com o que a política atual de negócio determina, colocando lado a lado a regra que está no código e a que está no documento de política.
Quando as regras vivem no código, esse exercício é manual, demorado e raramente acontece antes de o período fechar.
Esse ponto costuma ficar de fora das narrativas de case. É exatamente o que um Arquiteto ou Tech Lead precisa saber antes de entrar numa migração similar.
Centralizar regras de comissionamento num motor dedicado exige, primeiro, mapear o que existe. Em implementações que acompanhamos em operações de estrutura similar, essa etapa leva mais tempo do que a implementação em si. As regras estão em código, em planilhas, em e-mails de aprovação, em comentários de pull request, em tabelas de banco que ninguém documentou adequadamente. Entender qual versão é a vigente e qual é o histórico não-mais-utilizado exige entrevistar pessoas de diferentes áreas, cruzar datas de deploy com histórico de decisão de negócio e, em alguns casos, aceitar que a versão "certa" é aquela que o financeiro reconhece como correta, não necessariamente a que está no código.
O segundo ponto de atrito é a coexistência de ambientes durante a migração. A operação não para enquanto a centralização acontece. Por um período, o motor novo e a lógica antiga precisam produzir o mesmo output para o mesmo input. Qualquer divergência nessa fase paralela gera desconfiança, e desconfiança no sistema de comissionamento é politicamente custosa: os intermediários percebem antes da área técnica.
O terceiro ponto, que pega quase todo projeto desse tipo, é a granularidade das exceções. A regra geral é simples. As exceções acumuladas ao longo de anos de operação são complexas, específicas por canal, por parceiro, por produto, por vigência, e raramente estão documentadas num lugar só. Elas emergem durante o teste, quando alguém do time comercial olha um caso específico e diz "esse parceiro tem condição diferente desde 2023". Mapear as exceções é um trabalho que o cronograma original quase nunca contempla com a folga necessária.
Na operação Midway, a centralização envolveu exatamente esse trabalho de arqueologia: consolidar regras dispersas, resolver conflitos de versão, documentar as exceções que existiam mas nunca tinham sido formalizadas, e migrar tudo para uma camada onde o negócio passou a ter controle direto sobre alterações sem depender de TI para cada ajuste.
Após a centralização, o que muda não é só a velocidade de ajuste de regra. O que muda é a relação entre decisão de negócio e execução técnica.
Com regras na camada dedicada, a área de negócio altera um critério de comissionamento e a mudança entra em produção com controle de vigência, audit trail e versão rastreável. A engenharia não precisa ser envolvida para cada ajuste de parâmetro. O ciclo que antes levava semanas por ticket passa a ser medido em horas ou minutos, dependendo da complexidade da regra.
O impacto direto no revenue leakage é a eliminação do intervalo de divergência. A regra que o negócio quer vigente é a mesma que o sistema executa, porque não existe mais intermediação de sprint entre as duas. O ajuste de alíquota acontece na vigência correta, auditável, com registro de quem autorizou e quando.
Há um impacto secundário que os números de ticket raramente capturam: a confiabilidade do fechamento financeiro. Quando as regras são determinísticas, versionadas e rastreáveis, a reconciliação do período tem uma fonte única de verdade. A pergunta "qual regra estava em produção no dia X para o produto Y" tem resposta objetiva. Isso encurta o ciclo de fechamento e elimina o vai-e-vem entre financeiro e TI que consome horas de engenharia em ciclos de investigação que não geram nenhum valor de produto.
Separation of concerns aplicado a regras de negócio resolve o problema de acoplamento: a lógica de comissionamento para de ser responsabilidade operacional da engenharia no dia a dia. A engenharia mantém a infraestrutura do motor, a disponibilidade, os contratos de integração. O negócio mantém as regras dentro do motor.
O que a separação não resolve é a qualidade das regras em si. Um motor de regras executa com precisão o que está configurado. Se a configuração reflete política desatualizada, o motor executa a política desatualizada com perfeita rastreabilidade. A governança da regra, quem decide, quem aprova, quem tem autoridade para alterar qual parâmetro, precisa ser desenhada antes ou durante a implementação. Esse não é um problema técnico. É organizacional.
Regra muda. Sprint enche. Feature não sai. Esse ciclo só quebra quando a camada que governa a mudança de regra fica separada da camada que produz feature. O motor é o instrumento técnico dessa separação. Sem o processo de governança associado, ele reproduz o mesmo caos com mais velocidade.
Pega os últimos três ciclos de fechamento financeiro. Conta quantas discrepâncias de comissão foram abertas como tickets de investigação. Multiplica pelo tempo médio de resolução. Esse número, que aparece nos relatórios como "horas de suporte" ou "incidentes de conciliação", é o custo visível do problema de acoplamento.
O custo invisível é a diferença acumulada durante o intervalo entre decisão de negócio e deploy de regra, que só aparece quando alguém faz a comparação que o sistema não faz automaticamente.
Revenue leakage em comissões é um problema exclusivo de seguradoras?
O mecanismo é o mesmo em qualquer operação que paga comissão variável com base em regras complexas: fintechs, distribuidoras, marketplaces com modelo de comissionamento por categoria ou por canal. O que torna seguradoras um caso especialmente visível é a combinação de volume alto, variáveis múltiplas por produto e exigência regulatória de rastreabilidade. O problema de regra desatualizada em produção aparece em qualquer vertical onde o negócio cresce mais rápido do que a capacidade de TI de atender tickets de regra.
Por que centralizar regras é diferente de simplesmente documentar melhor as regras existentes?
Documentação resolve o problema de conhecimento. Centralização resolve o problema de execução. Uma regra bem documentada que continua acoplada ao código ainda exige ticket de TI para cada alteração e ainda produz o intervalo de divergência entre decisão e deploy. A centralização move a regra para uma camada onde o negócio pode alterar diretamente, com controle de versão e vigência, sem intermediação de sprint.
Quanto tempo leva uma migração de regras de comissionamento para motor dedicado?
Depende fundamentalmente do volume e da dispersão das regras existentes. O código em si raramente é o gargalo. O mapeamento das exceções acumuladas, a resolução de conflitos de versão e a validação paralela entre o motor novo e a lógica antiga são as etapas que consomem mais tempo. Em implementações que acompanhamos em operações de porte similar ao case descrito, o ciclo vai de 8 a 16 semanas da decisão ao go-live em produção, com a maior variação determinada pela disponibilidade de pessoas de negócio para validar as exceções durante a fase de homologação.
Como garantir que a regra no motor é a mesma que o time de negócio quer vigente?
Esse é o ponto de governança que precisa ser desenhado antes da implementação. A prática que reduz mais divergências é ter um fluxo de aprovação configurado dentro do próprio motor: alteração proposta, validação por perfil autorizado, ativação com data de vigência explícita. O motor executa o que foi aprovado e registrado. Qualquer dúvida sobre qual regra estava ativa em qual data tem resposta no histórico de versões, com autor e timestamp.
O que acontece com as regras que estão em planilhas fora do sistema?
Elas precisam ser mapeadas e migradas. O problema das planilhas é exatamente esse: são uma camada de regra paralela ao sistema, sem rastreabilidade de versão e sem garantia de que o sistema está executando o que a planilha diz. A migração envolve consolidar as planilhas, resolver conflitos de versão entre o que o sistema faz e o que a planilha define, e eliminar a planilha como fonte de autoridade após a validação do motor.
