Como prever a inadimplência com análise de dados

Inadimplência não é surpresa, é sinal que a carteira já vinha dando#

Quem trabalha com crédito conhece a cena: o comitê aprova uma safra de contratos, o resultado parece bom nos primeiros meses e, quando a inadimplência aparece nos números, já é tarde para agir naquele grupo. O problema raramente é falta de dado. É que o dado de comportamento de pagamento, de cadastro e de bureau já estava lá, disperso entre o core de crédito, o CRM e as bases externas, e ninguém transformou isso em um sinal antes da decisão. Prever inadimplência é justamente isso: usar o histórico que a operação já gerou para estimar, contrato a contrato, a probabilidade de um cliente atrasar ou não pagar, e usar essa estimativa antes de conceder, provisionar ou cobrar.

Neste artigo eu trato o tema do ponto de vista de quem implementa dados e BI na plataforma Microsoft: técnicas que são padrão no setor, análise de safra e roll rate, construção do escore de crédito, variáveis que pesam, e como treinar um modelo no Azure Machine Learning ou na experiência de Data Science do Microsoft Fabric e servir o resultado no Power BI. E vou ser honesto sobre onde o modelo erra, porque em crédito o erro tem preço direto.

Análise de safra e roll rate vêm antes de qualquer modelo#

Antes de falar em machine learning, a operação precisa enxergar a própria carteira com duas lentes clássicas. Elas não dependem de ciência de dados sofisticada e são o alicerce sobre o qual qualquer modelo é construído.

A análise de safra, ou vintage, agrupa os contratos pela data de originação e acompanha cada grupo ao longo dos meses de vida. Isso separa o efeito do tempo de carteira do efeito da qualidade da concessão. Uma safra que atinge 4% de inadimplência com 6 meses de vida pode ser pior que outra que chega a 5% com 12 meses, e só a curva de safra mostra isso. Sem ela, você compara safras jovens com maduras e toma decisão errada.

O roll rate mede a probabilidade de um contrato migrar de uma faixa de atraso para a seguinte de um mês para o outro. Ele responde a uma pergunta operacional direta: dos contratos hoje com 30 dias de atraso, quantos rolam para 60, e destes, quantos rolam para 90. Essa matriz de transição é a base para estimar perda esperada e para calibrar em que faixa a cobrança ainda recupera valor.

Técnica	O que responde	Uso prático
Análise de safra (vintage)	Como cada grupo de originação se comporta ao longo do tempo	Comparar qualidade de concessão entre períodos e políticas
Roll rate	Qual a chance de rolar de uma faixa de atraso para a próxima	Estimar perda esperada e priorizar cobrança
Curva de maturação	Quando a inadimplência de uma safra estabiliza	Definir janela de observação e ponto de corte do modelo

O motivo de eu insistir nessas duas antes do modelo é simples: elas definem o alvo. Um modelo de classificação precisa de uma definição clara do que é "mau pagador", por exemplo, atingir 90 dias de atraso dentro de uma janela de 12 meses. Essa definição sai da análise de safra e de roll rate, não de um palpite. Errar o alvo é o erro mais caro e mais comum nesses projetos.

O escore de crédito é uma probabilidade, não uma sentença#

O escore de crédito nada mais é que a saída de um modelo que estima a probabilidade de inadimplência de um contrato ou cliente. No Brasil, o mais usual ainda é a regressão logística, porque ela é interpretável, auditável e aceita bem por áreas de risco e por reguladores. Modelos de árvore, como gradient boosting, costumam ganhar em poder preditivo, mas cobram esse ganho em explicabilidade. Em crédito, essa troca não é técnica, é de negócio e de conformidade, e precisa ser decidida com a área de risco na mesa.

Vale separar dois momentos onde o escore atua, porque eles usam variáveis diferentes:

• Escore de originação (application score): calculado no momento da concessão, usa dados de cadastro, renda declarada, bureau externo e a proposta em si. Serve para decidir aprovar, negar ou ajustar limite e taxa.
• Escore comportamental (behavior score): calculado ao longo da vida do contrato, usa o comportamento de pagamento observado. Serve para revisão de limite, oferta de renegociação e priorização de cobrança.

O ponto honesto aqui: o escore ordena bem o risco, ele não crava quem vai ou não pagar. Um cliente com escore ruim ainda pode honrar o contrato, e um bom pagador pode entrar em atraso por um evento que nenhum dado antecipava, como perda de emprego ou uma emergência de saúde. O valor do escore está em separar a carteira em faixas de risco para decidir melhor, não em prever o destino de um indivíduo com certeza. Quem promete o segundo está vendendo ilusão.

As variáveis que pesam já existem na sua operação#

Modelo não inventa informação, ele aprende o que os dados contêm. Em crédito, os sinais preditivos costumam estar espalhados por fontes que não conversam entre si, e um bom trabalho de engenharia de dados começa por mapear e consolidar essas origens.

Fonte	Exemplos de variáveis úteis	Cuidado principal
Core de crédito e cobrança	Histórico de atraso, dias em cada faixa, renegociações anteriores	Definir o alvo de forma consistente entre produtos
Bureau de crédito externo	Escore de mercado, consultas recentes, restritivos	Custo por consulta e defasagem da informação
Cadastro do cliente	Renda, tempo de relacionamento, região, ocupação	Dado pessoal sob a LGPD, Lei nº 13.709/2018
Transacional e conta	Fluxo de entrada, uso de limite, saldo médio	Só disponível para quem opera a conta do cliente
Proposta e contrato	Valor, prazo, taxa, tipo de garantia, canal	Viés de canal pode contaminar o modelo

Alguns padrões aparecem de forma recorrente e ajudam a priorizar a coleta: comportamento de pagamento passado é o preditor mais forte do comportamento futuro, o comprometimento de renda importa mais que a renda absoluta, e a quantidade de consultas recentes ao bureau tende a sinalizar procura por crédito sob pressão. Isso não substitui a modelagem, mas orienta onde vale investir em qualidade de dado.

Um cuidado que trato como requisito, não como detalhe: variáveis que funcionam como proxy de características protegidas podem introduzir viés e discriminação. Região e CEP, por exemplo, correlacionam com renda e podem penalizar grupos inteiros sem que isso apareça de forma óbvia. Revisar as variáveis sob a ótica de justiça e de conformidade faz parte do projeto, e conecta diretamente com governança de dados.

Onde treinar o modelo: Azure Machine Learning ou Fabric#

Do lado da plataforma, a Microsoft oferece dois caminhos que convivem bem, e a escolha é de arquitetura, não de marketing.

O Azure Machine Learning é o ambiente completo para o ciclo de vida do modelo: preparação de dados, treino, versionamento, registro, implantação como endpoint e monitoramento. É a opção natural quando existe um time de risco ou de ciência de dados que precisa de controle fino, rastreabilidade e MLOps maduro, coisa que a área de crédito costuma exigir para auditoria.

A experiência de Data Science do Microsoft Fabric, plataforma anunciada pela Microsoft em 2023, permite treinar modelos de classificação dentro do mesmo ambiente onde já estão os dados analíticos. Quando a operação vai concentrar a analítica no Fabric, treinar e servir ali reduz integrações, porque o resultado chega ao Power BI direto pelo OneLake, sem exportações intermediárias. Para saber se essa consolidação faz sentido no seu caso, vale ler nossa análise sobre o que é o Microsoft Fabric e quando vale a pena.

Nos dois caminhos, o modelo é de classificação: entra o contrato com suas variáveis, sai uma probabilidade de inadimplência. A diferença está no rigor operacional e em onde o resto da sua stack já mora. Não existe resposta única, existe a resposta certa para a sua arquitetura, e é isso que um projeto de analytics avançado precisa definir logo no começo.

O Power BI consome o escore, ele não é o modelo#

Uma confusão comum é achar que o Power BI treina o modelo. Não treina, e não deveria. O papel dele é consumir o escore já calculado e colocá-lo na frente de quem decide, com o contexto que a decisão exige. O escore vai para uma tabela do modelo semântico, e a partir dele o Power BI monta as visões que a operação usa no dia a dia: distribuição da carteira por faixa de risco, curvas de safra, matriz de roll rate, perda esperada e concentração por produto, canal e região.

O desenho desses relatórios não é cosmético. Um painel de risco bem construído mostra a incerteza, não a esconde: faixas de escore em vez de um número mágico, indicação de quando o dado de uma safra ainda é imaturo, e alertas quando a distribuição de risco começa a se deslocar em relação ao que o modelo viu no treino. Esse deslocamento, o drift, é o principal sinal de que o modelo precisa ser recalibrado, e aparece primeiro no acompanhamento visual da carteira. Construir esses painéis com o rigor que a área de risco exige é o foco do nosso serviço de Power BI.

Provisão e política de crédito são o retorno real do projeto#

Prever inadimplência só vira valor quando a previsão muda uma decisão. Na prática, o escore alimenta três frentes, e é bom deixar cada uma explícita.

1. Política de concessão. O escore de originação define aprovação, limite e precificação por risco. Faixas de maior risco recebem limite menor ou taxa maior, e o ponto de corte é uma decisão de negócio que equilibra volume e perda esperada.
2. Provisão e perda esperada. A combinação de probabilidade de inadimplência com roll rate e com a exposição alimenta o cálculo de perda esperada, que sustenta a provisão. Aqui o modelo entra em um terreno regulado, e o setor de crédito é supervisionado pelo Banco Central, então metodologia, documentação e validação independente deixam de ser boa prática e passam a ser exigência.
3. Estratégia de cobrança. O escore comportamental prioriza quem cobrar primeiro e como. Faz pouco sentido gastar o mesmo esforço com um atraso de baixo risco de rolagem e com um contrato prestes a virar perda.

A tabela abaixo resume como cada uso conecta a técnica ao retorno.

Uso do escore	Técnica que sustenta	Retorno esperado
Concessão e limite	Escore de originação, ponto de corte	Menos perda na entrada da safra
Provisão	Perda esperada, roll rate, safra	Provisão mais aderente e auditável
Cobrança	Escore comportamental, roll rate	Recuperação maior com o mesmo custo

Prever inadimplência tem limites, e assumi-los protege o projeto#

Concentro aqui o que separa projeto sério de promessa vazia.

O modelo aprende do passado. Quando a economia muda, entra um produto novo ou o perfil de cliente se desloca, o que ele viu no treino deixa de valer e a performance cai. Por isso monitoramento e recalibração não são opcionais, são custo de manter o modelo vivo. Além disso, todo escore erra em duas direções: nega crédito a bom pagador, o falso positivo que custa receita, e aprova mau pagador, o falso negativo que custa perda. Onde colocar o ponto de corte é escolher qual erro dói menos para o seu negócio, e isso é decisão de risco, não de algoritmo. Por fim, há o limite ético e legal: dado pessoal sob a LGPD exige finalidade, base legal, minimização e controle de acesso, e decisões automatizadas de crédito precisam poder ser explicadas e revistas. Um modelo que ninguém explica é um passivo, por mais preditivo que seja.

Perguntas frequentes#

Preciso de um time de ciência de dados para começar a prever inadimplência?

Para o primeiro passo, não necessariamente. Uma regressão logística sobre uma base bem organizada, com o alvo definido a partir de análise de safra e roll rate, já entrega uma linha de base útil e auditável. Um time dedicado passa a fazer diferença quando a operação quer iterar com frequência, comparar algoritmos e manter o modelo em produção com rigor de MLOps. No início, a qualidade do dado pesa mais que a sofisticação do algoritmo.

Qual a diferença entre escore de originação e escore comportamental?

O de originação é calculado na hora da concessão e usa cadastro, bureau e a proposta, para decidir aprovar e precificar. O comportamental é calculado ao longo da vida do contrato e usa o histórico de pagamento observado, para revisar limite e priorizar cobrança. São modelos diferentes, com variáveis diferentes, e muitas operações mantêm os dois.

Azure Machine Learning ou Microsoft Fabric, qual escolher?

Depende de onde está a sua analítica e do seu apetite por controle. Se você já vai concentrar tudo no Fabric, treinar e servir ali leva o escore direto ao Power BI pelo OneLake e reduz integrações. Se há um time de risco que precisa de controle total do ciclo de vida, versionamento e monitoramento formal, o Azure Machine Learning é mais adequado. As duas são Microsoft e convivem bem, então a decisão é de arquitetura.

O modelo vai me dizer com certeza quem vai dar calote?

Não, e desconfie de quem prometer isso. O escore é uma probabilidade que ordena o risco da carteira em faixas. Ele melhora a decisão ao concentrar atenção nos casos de maior risco, mas convive com falsos positivos e falsos negativos, e não antecipa eventos que os dados não registram. O valor está em decidir melhor, não em prever o indivíduo com certeza.

Como fica a regulação e a LGPD nesse tipo de projeto?

O setor de crédito é supervisionado pelo Banco Central, o que exige metodologia documentada, validação e capacidade de explicar o modelo, sobretudo quando ele sustenta provisão. Em paralelo, dado pessoal está sob a Lei nº 13.709/2018, que exige finalidade, base legal, minimização e controle de acesso, além do direito de revisão de decisões automatizadas. Tratamos isso como requisito de arquitetura desde o desenho, não como etapa final.

Quanto tempo até ver resultado?

O primeiro escore útil no Power BI costuma vir antes do modelo estar perfeito, porque a maior parte do esforço é organizar e definir o dado. O impacto real, menos perda na safra e cobrança mais eficiente, só é mensurável observando as safras ao longo de meses, já que a inadimplência amadurece com o tempo do contrato. Prometer redução de perda em semanas é sinal de alerta.

Onde isso te leva#

Prever inadimplência não é comprar uma ferramenta, é organizar o dado que a operação já gera, definir o alvo com análise de safra e roll rate, treinar um modelo honesto no Azure Machine Learning ou no Fabric e colocar o escore na frente de quem concede, provisiona e cobra. A parte técnica é resolvível. O que separa um projeto que muda resultado de um dashboard esquecido é seriedade com o dado, com a regulação e com os limites da previsão.

Se você quer avaliar a viabilidade desse tipo de projeto na sua carteira, fale com a gente e a gente monta o caminho a partir do que você já tem.