Champion/Challenger: Como Testar Políticas de Crédito em Produção

Toda política de crédito nasce com uma hipótese: "essa combinação de regras vai aprovar os bons e negar os ruins." Mas hipóteses, por definição, precisam ser validadas. Champion/Challenger é a técnica que transforma a gestão de políticas de crédito de um exercício de intuição em um processo experimental, mensurável e controlado — testando novas regras em produção, com tráfego real, sem comprometer a operação.

Na prática, é o equivalente a um teste A/B aplicado a decisões financeiras. Mas com uma diferença crítica: em crédito, o resultado final (default ou adimplência) pode levar meses para se materializar. Isso exige uma disciplina de experimentação muito mais sofisticada do que simplesmente comparar taxas de conversão.

Neste artigo, vamos dissecar o que é Champion/Challenger, como projetar um teste robusto, quais métricas usar, como evitar vieses estatísticos e quando promover o Challenger a Champion.

O que é Champion/Challenger?

Champion/Challenger é uma técnica de experimentação controlada onde a política de decisão em produção (o Champion) é comparada simultaneamente com uma ou mais alternativas (os Challengers). Um percentual do tráfego é roteado para cada versão, e os resultados são medidos ao longo do tempo para determinar qual política performa melhor.

O conceito vem da estatística experimental, mas sua aplicação em crédito tem particularidades importantes:

• Decisões têm consequências financeiras reais — diferente de testar cores de botão, cada decisão do Challenger pode gerar uma perda ou um ganho concreto
• O feedback é assíncrono — a inadimplência pode levar 30, 60, 90+ dias para aparecer
• O custo de erro é assimétrico — aprovar um mau pagador custa mais do que negar um bom
• Regulação exige rastreabilidade — cada decisão precisa ser auditável, inclusive as do Challenger

Champion/Challenger não é sobre descobrir a "melhor" política. É sobre criar um processo contínuo de melhoria — onde cada ciclo de teste torna a operação mais precisa, mais eficiente e mais resiliente.

Por que não basta backtesting

O backtesting é indispensável — mas insuficiente. Ele responde "o que teria acontecido se essa política estivesse ativa no passado." O problema é que o passado não é o futuro.

Limitações estruturais do backtesting isolado:

• Survivorship bias — você só tem dados de quem foi aprovado no passado; não sabe como teria sido a performance de quem foi negado
• Mudanças de contexto — inflação, taxa de juros, sazonalidade e comportamento do consumidor mudam continuamente
• Feature drift — as variáveis que alimentam a política podem mudar de distribuição ao longo do tempo
• Efeitos de segunda ordem — uma política mais agressiva pode atrair um perfil de cliente diferente (adverse selection)

O backtesting valida a lógica. O Champion/Challenger valida o impacto. São complementares, não substitutos. Na prática, o fluxo ideal é: desenhar → backtesting → shadow mode → Champion/Challenger → promoção.

Arquitetura de um teste Champion/Challenger

Um teste bem projetado tem seis componentes:

1. Definição das políticas

O Champion é a política atual em produção. O Challenger é a alternativa que você quer testar — pode ser uma mudança de score de corte, uma nova regra de elegibilidade, a adição de uma variável de Open Finance, ou uma política completamente redesenhada.

2. Split de tráfego

Cada solicitação que entra na esteira é roteada para o Champion ou o Challenger com base em uma regra de distribuição (tipicamente aleatória). O split mais comum é 90/10 — 90% para o Champion, 10% para o Challenger.

3. Execução independente

Cada braço do teste executa sua política de forma independente. O solicitante roteado para o Challenger recebe uma decisão real baseada na política alternativa. Não é uma simulação — é produção.

4. Coleta de métricas

Ambos os braços registram as mesmas métricas: approval rate, condições oferecidas (limite, taxa), tempo de decisão, e marcam cada decisão com um identificador de safra para acompanhamento futuro.

5. Acompanhamento de safra

As safras geradas pelo Champion e pelo Challenger são acompanhadas ao longo do tempo para medir performance real: inadimplência, first payment default, roll rate, recuperação.

6. Decisão de promoção

Com dados suficientes e significância estatística, decide-se: promover o Challenger a Champion, descartar o Challenger, ou refinar e testar novamente.

Métricas de comparação

As métricas de um teste Champion/Challenger se dividem em duas categorias:

Métricas de curto prazo (disponíveis imediatamente)

• Approval rate — percentual de aprovações em cada braço
• Time-to-decision — tempo médio da decisão (latência da política)
• Cost per decision — custo de consultas a bureaus e APIs por decisão
• Manual review rate — percentual de decisões que caem para análise manual
• Revenue per decision — receita potencial por decisão aprovada

Métricas de performance (requerem maturação da safra)

• First payment default (FPD) — inadimplência no primeiro pagamento (proxy rápida, 30-60 dias)
• Default rate por safra — taxa de inadimplência da coorte (3-6 meses para maturar)
• Expected loss — perda esperada por decisão
• Risk-adjusted return — retorno ajustado ao risco por unidade monetária concedida

O segredo é usar métricas proxy de curto prazo para decisões rápidas (nas primeiras semanas) enquanto aguarda a maturação das métricas definitivas. FPD, por exemplo, é um preditor forte de default futuro em muitos produtos.

Split de tráfego e bias estatístico

O split de tráfego parece trivial — basta randomizar. Mas em crédito, existem armadilhas que invalidam o teste:

Viés de seleção

Se o roteamento não for verdadeiramente aleatório (ex: por horário, por canal, por região), os braços terão populações diferentes e os resultados serão incomparáveis. A randomização deve ser no nível do solicitante, não do lote.

Tamanho amostral

Com um split 90/10 e 1.000 decisões/mês, o Challenger recebe apenas 100 decisões. Se a taxa de default é 5%, você terá ~5 defaults no Challenger. Isso é estatisticamente insuficiente para qualquer conclusão. Regra prática: cada braço precisa de pelo menos 30 eventos (defaults) para significância mínima.

Significância estatística

Antes de declarar um vencedor, aplique testes estatísticos adequados (teste de proporções para approval rate, teste de sobrevivência para default rate). Um p-valor < 0.05 é o mínimo. Em operações de alto volume, use intervalos de confiança bayesianos para decisões mais informadas.

Champion/Challenger no Decision Stack™

No modelo Decision Stack™ da Sinky, Champion/Challenger opera na interseção de duas camadas:

Organizações no Nível 4 (Decision Intelligence) ou acima do DIMM tipicamente têm Champion/Challenger como prática operacional contínua, não como projeto pontual.

Shadow Mode vs Champion/Challenger

São técnicas complementares, mas fundamentalmente diferentes:

• Shadow Mode — a política alternativa roda em paralelo mas não afeta decisões reais. Útil para validar que a lógica funciona sem risco. Não gera dados de performance real porque os clientes não são efetivamente expostos à política.
• Champion/Challenger — a política alternativa toma decisões reais para um percentual do tráfego. Gera dados de performance real. Implica risco controlado.

O fluxo recomendado é: Shadow Mode primeiro (para validar que a política não quebra, que as regras estão corretas, que o tempo de resposta é aceitável) → depois Champion/Challenger (para medir impacto real).

Quando promover o Challenger

A promoção do Challenger a Champion é uma decisão de governança, não apenas uma decisão técnica. Critérios recomendados:

1. Significância estatística — o resultado deve ser estatisticamente significativo, não anedótico
2. Consistência temporal — a vantagem deve persistir ao longo de múltiplas semanas, não apenas em um pico
3. Análise de subgrupos — verificar que o Challenger não melhora no agregado mas piora em segmentos críticos
4. Aprovação de governança — um comitê ou responsável deve aprovar a promoção, com registro em audit trail
5. Plano de rollback — sempre manter a capacidade de reverter para o Champion anterior se a performance degradar

Nunca promova com base em métricas de curto prazo se o produto tem ciclo de maturação longo. Esperar pela FPD (30-60 dias) é o mínimo para crédito pessoal.

Como a Sinky implementa Champion/Challenger

Na Sinky, Champion/Challenger é nativo da plataforma. No Sinky Studio, políticas são versionadas como código — cada versão pode ser promovida a Champion ou configurada como Challenger com um split de tráfego definido visualmente. O Sinky Analytics monitora a performance de cada braço em tempo real, calcula significância estatística automaticamente e gera alertas quando um Challenger apresenta degradação.

O ciclo completo — criar política → backtesting → shadow mode → Champion/Challenger → promoção — é gerenciado dentro da mesma interface, com governança integrada e audit trail completo.

Perguntas frequentes

Qual a diferença entre Champion/Challenger e teste A/B?

O teste A/B é uma técnica genérica de experimentação. Champion/Challenger é a aplicação específica em políticas de decisão financeira. A diferença principal é o feedback assíncrono: em crédito, o resultado (default ou adimplência) pode levar meses para se materializar, exigindo métricas proxy e acompanhamento de safra — algo que um teste A/B tradicional de marketing não precisa considerar.

Quanto tráfego enviar para o Challenger?

Comece com 5-10%. Volumes menores exigem mais tempo para significância. Volumes maiores aceleram o aprendizado mas aumentam a exposição ao risco. O dimensionamento ideal depende do volume total de decisões, da taxa base de default e do tamanho do efeito que você espera detectar. Use calculadoras de poder estatístico para dimensionar corretamente.

Quanto tempo manter um teste?

Para métricas de curto prazo (approval rate, custo), 2-4 semanas bastam. Para métricas de performance real (default rate), aguarde pelo menos um ciclo de safra — 3 a 6 meses em crédito pessoal. Use FPD (first payment default, 30-60 dias) como proxy rápida para decisões preliminares.