Como Criar uma Política de Crédito: Guia Prático para Estruturar Regras de Decisão

Toda operação de crédito depende de uma política. Mas quando essa política existe apenas na cabeça dos analistas, em planilhas desatualizadas ou em documentos de Word que ninguém lê, o risco não está apenas no cliente — está na própria organização. Este guia mostra como criar uma política de crédito estruturada, moderna e pronta para ser executada por um motor de decisão.

O que é uma política de crédito?

Uma política de crédito é o conjunto de regras, critérios e processos que definem como uma organização avalia, aprova, nega e gerencia a concessão de crédito. Ela responde a perguntas fundamentais: quem pode receber crédito? Sob quais condições? Com que limites? Quem pode aprovar exceções?

Mais do que um documento, a política de crédito é a tradução da estratégia de risco da organização em lógica executável. Ela equilibra dois objetivos que frequentemente entram em conflito: maximizar a concessão de crédito (receita) e minimizar perdas por inadimplência (risco).

Uma política bem estruturada garante consistência — cada proposta é avaliada pelos mesmos critérios, independentemente de quem analisa. Garante velocidade — decisões automatizáveis não dependem de filas humanas. E garante rastreabilidade — cada decisão pode ser explicada e auditada, como exigem reguladores e boas práticas de credit decisioning.

Por que políticas não deveriam viver em planilhas

A maioria das operações de crédito no Brasil ainda mantém suas políticas em planilhas Excel, documentos PDF ou, pior, na memória dos analistas seniores. Isso cria problemas profundos:

• Sem versionamento: ninguém sabe qual versão da política está em vigor. Alterações são feitas sem controle, sem aprovação formal e sem registro de quem mudou o quê.
• Sem consistência: analistas diferentes interpretam as mesmas regras de formas diferentes. Um analista pode aprovar o que outro negaria, gerando arbitrariedade.
• Sem auditoria: quando o regulador pergunta por que uma decisão foi tomada, a resposta depende da memória de quem decidiu — se essa pessoa ainda estiver na empresa.
• Sem teste: mudanças na política vão para produção sem backtesting, sem simulação, sem avaliação de impacto. A empresa descobre que a nova regra é ruim quando já perdeu dinheiro.
• Sem escala: à medida que o volume cresce, o processo manual se torna gargalo. Propostas acumulam em filas, clientes desistem, oportunidades são perdidas.

O custo de decisões ruins de crédito não é apenas financeiro — ele se manifesta em perda de clientes, deterioração da carteira e risco regulatório. Políticas em planilhas são a origem mais comum desses problemas.

Uma política que não pode ser versionada, testada e auditada não é uma política. É uma sugestão.

Os 5 componentes de uma política moderna

Uma política de crédito completa vai muito além de um conjunto de regras if/then. Ela é composta por cinco componentes distintos, cada um com uma função específica.

1. Critérios de elegibilidade

Os critérios de elegibilidade definem quem pode ser avaliado. São filtros binários que determinam se o proponente sequer entra na esteira de análise. Exemplos: idade mínima de 18 anos, CPF válido, sem restrições ativas no SPC/Serasa, empresa ativa há mais de 12 meses no CNPJ.

Esses critérios funcionam como uma primeira barreira. Propostas que não atendem são negadas automaticamente, sem consumir recursos de análise mais aprofundada. Em uma infraestrutura de decisão bem projetada, esses critérios são a primeira etapa do pipeline.

2. Regras de decisão

As regras de decisão traduzem a estratégia de risco em lógica condicional. Elas definem o que acontece quando determinadas condições são atendidas. Exemplos: se a renda declarada for inferior a R$ 2.000, negar; se o comprometimento de renda for superior a 40%, reduzir o limite em 50%; se o cliente for PEP, encaminhar para análise manual.

Regras de decisão podem ser organizadas em tabelas de decisão — matrizes que cruzam variáveis e condições para determinar a ação. Isso torna a lógica visual, auditável e fácil de modificar por times de negócio, sem necessidade de programação.

3. Scorecards

Scorecards são modelos estatísticos que atribuem pontuações a variáveis do proponente para calcular uma nota de risco. Cada variável recebe um peso, e a soma das pontuações resulta em um score final que indica a probabilidade de inadimplência.

Scorecards podem ser de diferentes tipos: application score (para novos clientes), behavioral score (para clientes existentes) e collection score (para gestão de cobrança). Em uma política moderna, o scorecard é integrado ao motor de decisão e seu resultado alimenta as regras de decisão automaticamente.

4. Limites e alçadas

Limites definem os tetos de exposição que a organização está disposta a aceitar. Limites por cliente, por segmento, por produto, por região. Alçadas definem quem pode aprovar o quê — um analista junior pode aprovar até R$ 10.000; acima disso, precisa de um gestor; acima de R$ 100.000, precisa de um comitê.

A combinação de limites e alçadas cria uma matriz de autoridade que garante que decisões de alto impacto recebam o nível adequado de escrutínio, sem criar gargalos desnecessários para decisões de baixo risco.

5. Exceções e escalações

Nenhuma política cobre 100% dos cenários. Sempre haverá casos que não se encaixam nas regras predefinidas. O componente de exceções define como lidar com esses casos: quem pode aprovar exceções, quais os limites para exceções, como documentar a justificativa e como monitorar o desempenho de propostas aprovadas por exceção.

Uma boa política de exceções não é permissiva — ela é estruturada. Cada exceção é registrada, justificada e monitorada. Se exceções em um determinado cenário se tornam frequentes, é sinal de que a política precisa ser ajustada.

Como desenhar uma política passo a passo

Passo 1: Definir objetivos e apetite de risco

Antes de escrever qualquer regra, a organização precisa definir o que quer alcançar. Qual é a taxa de aprovação desejada? Qual é o nível de inadimplência aceitável? Qual é o ticket médio alvo? Essas definições vêm da estratégia de negócio e orientam todas as decisões subsequentes.

Passo 2: Mapear variáveis e fontes de dados

Identifique todas as variáveis disponíveis para a decisão: dados cadastrais, score de bureau, renda, comprometimento, histórico interno, dados de Open Finance, consultas em bases públicas. Para cada variável, mapeie a fonte, a confiabilidade e o custo de consulta.

Passo 3: Construir critérios de elegibilidade

Defina os filtros binários que determinam quem entra na esteira. Comece com critérios regulatórios obrigatórios (idade, documentação) e adicione critérios de negócio (restrições, tempo de atividade). Mantenha os critérios simples e não-ambíguos.

Passo 4: Desenhar a lógica de decisão

Organize as regras em uma estrutura lógica: tabelas de decisão para regras matriciais, árvores de decisão para fluxos condicionais, scorecards para avaliação de risco. A maioria das políticas combina esses três instrumentos. Use ferramentas no-code para que times de negócio possam configurar e ajustar sem depender de TI.

Passo 5: Definir limites, alçadas e exceções

Configure a matriz de autoridade: quem aprova o quê, até qual valor, sob quais condições. Defina o processo para exceções: formulário de justificativa, fluxo de aprovação, registro automático para auditoria.

Passo 6: Implementar no motor de decisão

Transfira a política para o motor de decisão de crédito. Configure cada componente — elegibilidade, regras, scorecards, limites — como módulos no pipeline de decisão. Garanta que a política esteja versionada e que cada mudança passe por um fluxo de aprovação.

Passo 7: Testar antes de produzir

Nunca coloque uma política nova em produção sem testes rigorosos. Utilize backtesting com dados históricos e shadow mode para validação em tempo real. Esse passo é tão importante que merece uma seção própria (veja abaixo).

Tabelas de decisão vs árvores de decisão vs scorecards

Os três instrumentos mais comuns em políticas de crédito não são concorrentes — são complementares. Cada um é ideal para um tipo diferente de lógica.

Dimensão	Tabela de Decisão	Árvore de Decisão	Scorecard
Melhor para	Regras matriciais com múltiplas variáveis	Fluxos condicionais sequenciais	Avaliação de risco com pontuação
Complexidade	Baixa a média	Média a alta	Alta (requer modelagem estatística)
Legibilidade	Alta — visual e tabular	Média — requer diagramação	Baixa — requer interpretação estatística
Manutenção	Fácil — times de negócio podem editar	Moderada — pode se tornar complexa	Difícil — requer recalibração periódica
Explicabilidade	Alta — cada linha é uma regra explícita	Alta — cada caminho pode ser traçado	Média — depende das variáveis e pesos
Exemplo de uso	Definir limite por faixa de renda × score	Fluxo de KYC com múltiplas verificações	Calcular probabilidade de inadimplência

Na prática, uma política robusta utiliza os três: o scorecard calcula o risco; a tabela de decisão determina o limite com base no score e na renda; a árvore de decisão orquestra o fluxo completo, incluindo exceções e escalações.

Governança: versionamento, auditoria e rollback

Uma política de crédito sem governança é uma bomba-relógio. Governança não é burocracia — é a disciplina que protege a organização de erros, fraudes e descumprimento regulatório.

Os pilares de governança de uma política de crédito moderna:

• Versionamento: cada alteração na política gera uma nova versão. A versão anterior é preservada integralmente. É possível comparar versões e entender exatamente o que mudou, quando e por quem.
• Audit trail: cada decisão registra qual versão da política foi aplicada, quais dados foram consultados, quais regras dispararam e qual foi o resultado. Isso é indispensável para compliance com BACEN, LGPD e auditorias internas.
• Rollback: se uma nova versão da política apresentar resultados ruins (aumento de inadimplência, queda excessiva na aprovação), é possível reverter para a versão anterior em minutos — não em semanas.
• Controle de acesso: nem todos podem editar políticas. RBAC (controle de acesso baseado em papéis) garante que apenas pessoas autorizadas façam alterações, com fluxos de aprovação para mudanças críticas.

Testando antes de produzir: backtesting e shadow mode

Colocar uma política nova em produção sem testes é como lançar software sem QA. O resultado é previsível: bugs, perdas e retrabalho. Duas técnicas são fundamentais para validar políticas antes de ativá-las:

Backtesting

O backtesting aplica a nova política a dados históricos. Se você tem 12 meses de propostas já decididas, aplica a nova política a cada uma delas e compara: qual seria a taxa de aprovação? Quantas propostas que foram aprovadas e se tornaram inadimplentes teriam sido negadas? Quantas propostas boas que foram negadas teriam sido aprovadas?

O backtesting responde à pergunta: "se essa política estivesse ativa no passado, como teria performado?"

Shadow mode

O shadow mode é mais rigoroso. A nova política roda em paralelo com a política ativa, processando as mesmas propostas em tempo real. Mas suas decisões não são efetivadas — são apenas registradas para comparação. Após algumas semanas, a equipe analisa as divergências e decide se a nova política é superior.

O shadow mode responde à pergunta: "como essa política se comportaria no mundo real, agora?"

Ambas as técnicas devem ser recursos nativos da plataforma, não projetos ad-hoc de analytics. Em uma infraestrutura de decisão madura, backtesting e shadow mode são funcionalidades de self-service.

Onde a política vive no Decision Stack™ (Policy Layer)

No modelo do Decision Stack™, a política de crédito é implementada na Policy Layer — a terceira camada da infraestrutura de decisão.

A Policy Layer é onde a estratégia de negócio se transforma em lógica executável. Ela contém tabelas de decisão, árvores de decisão, scorecards, regras condicionais e toda a configuração de limites e alçadas. Ela fica acima da Data Layer (que fornece os dados) e da Orchestration Layer (que coordena o fluxo), e abaixo da Intelligence Layer (que adiciona IA), da Governance Layer (que garante auditoria) e da Observability Layer (que monitora resultados).

Quando a política está na Policy Layer de uma Decision Infrastructure, ela herda automaticamente todas as capacidades das outras camadas: versionamento, explicabilidade, backtesting, monitoramento e rollback. Isso é fundamentalmente diferente de uma política em planilha, que não herda nenhuma dessas capacidades.

Uma política na Policy Layer não é um documento. É um artefato vivo — versionado, testável, auditável e monitorado em tempo real.

Como a Sinky simplifica políticas

A plataforma da Sinky permite que times de negócio criem, testem e gerenciem políticas de crédito diretamente na Policy Layer do Decision Stack™ — sem escrever código e sem depender de ciclos longos de TI. Tabelas de decisão, scorecards e regras condicionais são configurados visualmente, com versionamento automático, backtesting integrado e shadow mode nativo.

Cada decisão executada pela política é registrada com explicabilidade completa: quais regras dispararam, quais dados foram consultados, qual score foi calculado e por que a decisão final foi aquela. Isso garante conformidade regulatória e permite ajustes contínuos baseados em dados reais de performance.