Crédito com scoring alternativo por open finance

Crédito com scoring alternativo por open finance já saiu do campo experimental e entrou no radar de bancos, fintechs e originadores de crédito. O motivo é simples: dados transacionais autorizados pelo cliente oferecem sinais mais ricos do que cadastro e bureau sozinhos.

Este guia mostra um pipeline prático com Transformer para sair da teoria e montar uma primeira versão de score. Você vai ver arquitetura, features, validação, métricas e um caminho enxuto para colocar o modelo em produção com segurança e governança.

Por que open finance muda o jogo do risco

No crédito, o problema nunca foi falta de modelagem. O gargalo sempre foi a qualidade do sinal. Com open finance, o analista passa a observar entradas, saídas, recorrência de recebíveis, concentração de gastos e volatilidade de caixa. Isso ajuda a precificar risco em perfis com pouco histórico de bureau.

Um dado relevante: em mercados com consentimento financeiro, a leitura de transações pode aumentar a cobertura de análise para perfis thin file e near prime. Relatórios do BIS e de reguladores locais reforçam a tese de que dados alternativos melhoram decisão quando há governança e finalidade clara.

O que entra no score

Na prática, os sinais mais úteis são: saldo médio diário, variação de saldo, frequência de crédito em conta, regularidade de salário, pagamentos recorrentes, uso de limite e sazonalidade. Em muitos casos, 30 a 90 dias de transações já produzem features úteis para um primeiro modelo.

O ponto central é evitar feature “bonita” e sem poder preditivo. Se uma variável não melhora AUC, KS ou estabilidade por safra, ela vira ruído operacional.

Pipeline prático: do consentimento ao score

Um pipeline de crédito com scoring alternativo por open finance pode ser dividido em seis blocos. Primeiro, captura do consentimento e ingestão via APIs. Segundo, normalização e padronização de extratos, contas e eventos. Terceiro, engenharia de atributos. Quarto, treino do modelo. Quinto, explicabilidade e calibração. Sexto, monitoramento em produção.

Na camada de ingestão, o ideal é usar um orquestrador leve, como Airflow ou Dagster, e armazenar dados em um lakehouse com particionamento temporal. Para feature store, Feast ou Tecton ajudam quando há múltiplos times consumindo as mesmas variáveis. Em Python, Pandas e Polars resolvem o protótipo; em escala, Spark ou DuckDB podem entrar no fluxo.

Exemplo de arquitetura

Fluxo mínimo: API de open finance → fila Kafka ou Pub/Sub → processamento batch diário → feature store → treino semanal → endpoint de inferência. Em um piloto, esse desenho já permite reduzir latência e manter rastreabilidade de cada decisão.

Open finance não substitui o bureau; ele adiciona contexto que o modelo tradicional não enxerga.

Se houver necessidade regulatória, registre versão de dados, versão do modelo e motivo da decisão. Ferramentas de MLOps como MLflow e Evidently ajudam a documentar experimentos e monitorar drift.

Transformer para séries transacionais

O Transformer é útil porque lida bem com sequência longa, atenção entre eventos e padrões que mudam ao longo do tempo. Em scoring, isso é valioso quando o comportamento do cliente depende de ordem, intervalo e intensidade das transações, e não apenas de agregados simples.

Um baseline com regressão logística ainda deve ser o ponto de partida. Em muitos projetos, a melhora real vem quando o Transformer recebe sequências de eventos com embeddings de tipo de transação, valor normalizado, horário, canal e distância desde o evento anterior.

Estrutura de entrada

Monte uma sequência de até 256 eventos por cliente. Cada evento pode conter: tipo, valor log-transformado, saldo pós-evento, dia da semana, hora, merchant category e gap temporal. Use padding e máscara para lidar com séries curtas. Esse desenho é comum em modelos de comportamento transacional e já aparece em estudos acadêmicos e aplicações de risco em instituições financeiras.

Para treinamento, uma loss binária com class imbalance costuma funcionar bem. Se a inadimplência for baixa, teste focal loss ou pesos por classe. Uma AUC acima do baseline em 2 a 5 pontos já pode justificar o avanço para uma fase piloto, desde que a calibração permaneça estável.

Leituras úteis incluem a documentação do PyTorch Transformer e artigos sobre atenção em séries temporais no arXiv.

Código-base para um primeiro protótipo

Um protótipo enxuto pode ser montado em Python com PyTorch. A ideia não é fechar produção, e sim validar se o Transformer captura padrão melhor do que um modelo tabular tradicional. O treino deve ser temporal, nunca aleatório, para evitar vazamento.

Exemplo de esqueleto:

1. Gere features por janela de 30, 60 e 90 dias.
2. Construa sequências por cliente com máscara.
3. Treine baseline tabular.
4. Treine Transformer com embeddings e atenção.
5. Compare AUC, KS, Brier Score e calibração.

Um Transformer bem treinado aprende padrão de caixa, não só histórico de atraso.

Em termos práticos, um pipeline bem montado pode ser codificado em poucas centenas de linhas. O mais importante é a disciplina temporal: treino em meses antigos, validação em meses intermediários e teste em safra mais recente. Isso reduz a chance de um score “bom no notebook” e fraco em produção.

Para observabilidade, registre métricas por segmento: faixa de renda, tipo de produto, origem do cliente e profundidade de consentimento. Em crédito, um ganho médio pode esconder piora em subgrupos relevantes.

Validação, explicabilidade e compliance

Em crédito com scoring alternativo por open finance, a validação não termina na AUC. É preciso olhar estabilidade populacional, aprovação por faixa de score, inadimplência observada e fairness. Um modelo pode ser preciso e, ainda assim, concentrar risco em um grupo específico.

Para explicabilidade, SHAP funciona bem em features agregadas. Já em sequências, atenção visual e análise de eventos críticos ajudam mais do que explicações genéricas. Se o modelo usa Transformer, combine explicação global com análise local de transações mais relevantes.

Governança mínima

Documente base legal, consentimento, retenção e finalidade. O Banco Central do Brasil e a LGPD exigem clareza sobre uso de dados financeiros. Também vale manter trilha de auditoria para decisões automatizadas, especialmente em jornadas com contestação do cliente.

Na prática, um comitê de risco precisa ver três coisas: performance, estabilidade e justificativa. Sem isso, o modelo vira uma caixa-preta difícil de aprovar.

Erros comuns e um roadmap de 30 dias

O erro mais comum é tentar treinar Transformer antes de resolver a base. Se o dado está sujo, incompleto ou mal sincronizado, o modelo só aprende ruído em alta escala. Outro erro frequente é misturar eventos pós-venda com treino, gerando vazamento e falsa performance.

Um roadmap realista para 30 dias ajuda a sair da ideia e chegar ao piloto. Semana 1: mapear fontes e consentimento. Semana 2: construir dataset temporal. Semana 3: baseline e métricas. Semana 4: Transformer, calibração e relatório para risco.

Checklist de piloto

Inclua pelo menos 1.000 clientes com histórico suficiente, 3 janelas temporais, 1 baseline tabular, 1 modelo sequencial e 1 relatório de drift. Se houver ganho consistente em teste fora da amostra, avance para um piloto controlado com limites de crédito e monitoramento diário.

Esse é o ponto em que open finance deixa de ser promessa e vira ferramenta operacional para decisão de crédito.

Sobre o autor

pettrus

Editor IAIRON — Inteligência Artificial aplicada ao mercado brasileiro.