Antes de colocar uma nova política de crédito em produção, existe uma pergunta que todo gestor de risco deveria fazer: "o que teria acontecido se essa política estivesse ativa nos últimos 12 meses?" Essa pergunta é a essência do backtesting — a prática de simular políticas contra dados históricos para antecipar seu impacto antes de expor a operação ao risco real.
O backtesting não substitui testes em produção como Champion/Challenger. Mas é o primeiro filtro: elimina políticas ruins antes que elas cheguem ao tráfego real, reduz o custo de experimentação e acelera o ciclo de iteração.
Neste artigo, vamos abordar como desenhar um backtest robusto, quais dados usar, quais armadilhas evitar e como integrar backtesting ao pipeline de decisão.
O que é backtesting de políticas de crédito?
Backtesting é a simulação retrospectiva de uma política de crédito. Você define as regras (score de corte, critérios de elegibilidade, limites) e as aplica contra um conjunto de dados históricos — tipicamente um coorte de solicitações que já foram decididas e cujo resultado (adimplência ou default) já é conhecido.
O output é um conjunto de métricas simuladas: quantas solicitações teriam sido aprovadas, quantas negadas, qual teria sido a taxa de default da carteira aprovada, e qual o impacto em receita. Isso permite comparar a política proposta contra a política que estava ativa no período.
Backtesting responde à pergunta "e se?" — e se tivéssemos usado esse score de corte? E se tivéssemos adicionado essa regra? E se tivéssemos removido essa restrição? Cada cenário gera uma projeção que informa a decisão de implementação.
Backtesting vs Shadow Mode vs Champion/Challenger
São três técnicas de validação complementares, cada uma com escopo e timing diferentes:
Backtesting — Dados históricos · Retrospectivo · Rápido (minutos/horas) · Sem risco · Limitado por survivorship bias
Shadow Mode — Tráfego real em paralelo · Prospectivo · Semanas · Sem risco (não impacta decisões) · Captura dinâmicas atuais
Champion/Challenger — Tráfego real com decisões reais · Prospectivo · Meses · Risco controlado · Mede impacto real
O fluxo recomendado é sequencial: backtesting → shadow mode → Champion/Challenger → promoção. Cada etapa reduz o risco da seguinte.
Dados históricos: o que usar e o que não usar
A qualidade do backtest depende inteiramente da qualidade dos dados. Duas armadilhas são fatais:
Survivorship bias
Você só tem dados de performance (default/adimplência) para solicitações que foram aprovadas. Os negados não geraram dados de resultado. Isso significa que qualquer política que aprove um grupo diferente do que foi aprovado no passado está operando parcialmente no escuro.
Mitigação: usar modelos de reject inference (como a técnica de parcelling ou augmented data) para estimar a performance provável dos rejeitados. Não é perfeito, mas é melhor do que ignorar.
Look-ahead bias
Usar informações que não estariam disponíveis no momento da decisão original. Exemplo: usar o score atualizado de hoje para simular uma decisão de 12 meses atrás, quando o score era diferente. O backtest deve usar as features point-in-time — exatamente como estavam no momento da solicitação.
Como desenhar um backtest
Um backtest robusto segue cinco etapas:
- Definir a política — especificar todas as regras, scores de corte, critérios de elegibilidade e limites que compõem a política de crédito
- Selecionar o coorte — definir o período histórico e a população (todas as solicitações recebidas, não apenas as aprovadas se possível)
- Aplicar as regras — executar a política contra cada solicitação do coorte, usando features point-in-time
- Medir resultados — calcular métricas de aprovação, rejeição e performance da carteira simulada
- Comparar com baseline — contrastar os resultados da política proposta com a política que estava ativa no período
Métricas de avaliação
As métricas de um backtest se dividem em volume e qualidade:
- Approval rate simulado — percentual de solicitações que a nova política teria aprovado
- Default rate estimado — taxa de inadimplência da carteira simulada (usando dados reais dos aprovados que se sobrepõem)
- Revenue impact — receita estimada da carteira aprovada vs. a carteira original
- Population Stability Index (PSI) — mede o quanto a distribuição da população aprovada muda entre a política original e a proposta; PSI > 0.25 indica instabilidade
- Swap-set analysis — identifica quem seria aprovado pela nova política mas não pela antiga (e vice-versa) para análise granular
Armadilhas comuns
Seis erros que invalidam backtests:
- Ignorar survivorship bias — testar apenas contra aprovados superestima a performance
- Look-ahead bias — usar features atualizadas em vez de point-in-time
- Overfitting temporal — otimizar para um período específico que não generaliza (ex: calibrar durante COVID)
- Ignorar mudanças macro — Selic em 2% e Selic em 13% produzem dinâmicas completamente diferentes
- Não documentar premissas — sem documentação, o backtest não é reproduzível nem auditável
- Tratar como validação definitiva — backtesting é necessário, não suficiente; sempre seguir com shadow mode ou Champion/Challenger
Backtesting no Decision Stack™
No modelo Decision Stack™, backtesting opera na interseção de duas camadas:
Observability Layer — Armazena os dados históricos de decisão com features point-in-time, permitindo reproduzir o contexto exato de cada decisão passada.
Policy Layer — Permite definir versões de políticas e executá-las contra datasets históricos sem afetar produção. Cada backtest é versionado e rastreável.
Organizações no Nível 3 (Decision Operations) ou acima do DIMM tipicamente automatizam backtesting como parte do pipeline de CI/CD de políticas — cada nova versão de política passa por backtest automatizado antes de ser promovida.
Automação: backtesting como pipeline
Em operações maduras, backtesting não é um exercício pontual em planilha. É um pipeline automatizado:
- Trigger automático — toda nova versão de política dispara um backtest contra os últimos N meses de dados
- Métricas padronizadas — approval rate, default rate, PSI, swap-set são calculados automaticamente
- Relatório comparativo — diff visual entre a política atual e a proposta
- Gate de qualidade — se as métricas não atingem thresholds mínimos, a política não avança para shadow mode
Isso transforma backtesting de uma atividade ad hoc de cientistas de dados em uma etapa operacional integrada ao fluxo de governança de decisão.
Como a Sinky implementa backtesting
Na Sinky, backtesting é integrado ao ciclo de vida da política. No Sinky Studio, cada versão de política pode ser testada contra datasets históricos com um clique. O sistema automaticamente aplica features point-in-time, calcula métricas padronizadas e gera um relatório comparativo com swap-set analysis. Políticas que passam no backtest podem ser promovidas para shadow mode ou Champion/Challenger diretamente pela interface.
Perguntas frequentes
O que é backtesting de políticas de crédito?
É a prática de aplicar uma política de crédito — nova ou modificada — contra dados históricos para simular qual teria sido seu impacto. Permite estimar approval rate, default rate e revenue impact antes de colocar a política em produção.
Qual a diferença entre backtesting e shadow mode?
Backtesting usa dados históricos (retrospectivo). Shadow mode executa a política em paralelo com tráfego real mas sem impactar decisões (prospectivo em tempo real). Backtesting é mais rápido e barato; shadow mode captura dinâmicas que o histórico não tem.
Quais são as armadilhas mais comuns do backtesting?
As principais são: survivorship bias (testar apenas contra aprovados), look-ahead bias (usar informações que não estariam disponíveis no momento da decisão), overfitting (otimizar para o passado sem generalizar), e ignorar mudanças macroeconômicas que invalidam o período histórico.
