Melhores Plataformas de Decisão de Risco de Crédito: 5 Testes

Última atualização: setembro de 2026

As melhores plataformas de decisão de risco de crédito não podem ser escolhidas a partir de uma lista de classificação ou de uma tabela de funcionalidades, pois nenhuma delas mostra como uma plataforma decide sobre suas propostas. Para um credor, a melhor plataforma de decisão de risco de crédito é aquela que, ao rodar com as propostas passadas e em tempo real do próprio credor, corresponde às decisões atuais onde deve, explica cada diferença e permite que a equipe de crédito altere políticas mantendo o controle de exceções e explicações. Este guia apresenta cinco testes para realizar em uma lista de finalistas antes de assinar o contrato, os resultados fracos a que deve ficar atento em cada um e o registro que deve manter sobre como fez a escolha.

Resumo (TL;DR)

• Avalie cada plataforma finalista pela forma como ela decide suas próprias propostas, tendo as suas decisões atuais como referência.

• Execute cinco testes: um backtest em decisões históricas, um desafiante (challenger) em paralelo com sua política atual, uma leitura dos motivos de ações adversas em recusas reais, uma alteração de política real cronometrada desde a solicitação até o lançamento, e o monitoramento acordado antes do go-live.

• No backtest, analise o conjunto de troca (swap set - as aprovações que uma plataforma recusaria e as recusas que ela aprovaria) regra por regra. Os resultados de pagamento existem apenas para os proponentes que você aprovou.

• O motivo de uma recusa precisa ser específico o suficiente para ser enviado. O Regulamento B exige os motivos principais, e uma declaração de que o proponente não atingiu os padrões internos ou uma pontuação mínima é insuficiente.

• Mantenha o registro da avaliação. Os modelos de um provedor continuam sendo seus para compreender e monitorar.

O que torna uma plataforma de decisão de risco de crédito a melhor para a sua concessão de crédito?

A melhor plataforma de decisão de risco de crédito para a sua operação é aquela que se prova nas suas próprias propostas ao longo de cinco testes, porque a mesma plataforma pode se adequar à carteira de um credor e falhar na de outro. Uma plataforma de decisão de risco de crédito executa chamadas de dados, regras, modelos, políticas e o processo que transforma uma proposta de crédito em uma decisão, além de guardar a explicação e o registro por trás de cada decisão. Os cinco testes verificam essas partes em propostas que você já decidiu e, depois, em propostas em tempo real:

1. Backtest em suas decisões históricas. Rode novamente propostas passadas em cada plataforma com sua política atual reconstruída nelas, e explique cada decisão que apresentar um resultado diferente.

2. Rode um desafiante (challenger) ao lado de sua política atual. Permita que a plataforma candidata decida propostas em tempo real em paralelo, sem que nenhuma de suas decisões chegue ao proponente.

3. Avalie os motivos das ações adversas. Leia o que a plataforma gera para recusas reais e decida se você enviaria essa mensagem.

4. Cronometre uma mudança de política real, incluindo exceções. Faça uma alteração que sua equipe precise e cronometre-a desde a solicitação até o lançamento, incluindo testes, aprovação e reversão (rollback).

5. Acorde o que o monitoramento deve mostrar após o go-live. Defina as visualizações, as tolerâncias e seus responsáveis antes de assinar.

As suas decisões atuais são a referência para cada teste. O que você procura é a concordância onde sua política está correta e uma explicação rastreável onde quer que a plataforma divirja. Mantenha o registro de como fez a escolha à medida que avança, pois o risco de modelo, o comitê de crédito e um auditor podem solicitá-lo.

O local ideal para tornar esses testes uma condição para a lista de finalistas é na solicitação de proposta (RFP), e as perguntas a serem feitas a cada provedor devem constar em uma checklist de RFP para motor de decisão de crédito.

Por que uma lista de funcionalidades não pode escolher a plataforma por você

Uma lista de funcionalidades não pode escolher uma plataforma de decisão de risco de crédito porque as plataformas mais robustas costumam reivindicar os mesmos recursos, e uma promessa comercial não diz nada sobre como a plataforma lida com suas lacunas de dados, exceções e histórico. Os critérios de avaliação de fornecedores estruturados como uma tabela de funcionalidades mostram o que uma plataforma pode ser configurada para fazer. Uma demonstração de software de decisão de empréstimos roda com os dados e a política do provedor, mostrando a plataforma em seu melhor cenário com propostas que não são as suas.

Quando duas plataformas parecem equivalentes no papel, a escolha costuma depender de quem gostou mais de quais telas. Um teste com suas próprias propostas oferece uma base para a escolha que uma lista de funcionalidades não consegue fornecer.

Os motivos da escolha também devem ser seus. Um diretor de risco (CRO) em um emissor de cartões comentou: "Preciso ser capaz de explicar por que escolhemos esses limites. E se a minha explicação for 'porque o fornecedor nos disse para fazer assim', não vai pegar nada bem". Os resultados das suas próprias propostas dão à sua equipe motivos que ela pode defender perante um comitê de crédito ou um auditor.

Os recursos em si são abordados em nosso guia sobre o que procurar em uma plataforma de decisão de crédito. Este guia vai um nível além, mostrando como testar esses recursos em suas próprias propostas e como distinguir um resultado forte de um fraco.

Teste 1: Realize um backtest de cada plataforma com suas próprias decisões históricas

Um backtest roda novamente um grupo de suas propostas passadas em cada plataforma finalista, com sua política de crédito atual reconstruída nela, e compara as decisões da plataforma com as que você tomou. Ele responde a duas perguntas: se a plataforma reproduz suas decisões onde sua política está correta e o que uma mudança nessa política teria gerado. Um diretor de estratégia de crédito em uma fintech de crédito utilizou os termos do mercado para essas duas partes: "...você fez uma simulação pró-forma? Então, dizemos que vamos aprimorar um modelo e realizamos testes retroativos e pró-forma em dados antigos". O teste retroativo roda novamente o que aconteceu, e o teste pró-forma simula o impacto que uma alteração teria causado.

Como rodar o backtest

1. Acorde o escopo por escrito primeiro. Documente o que o backtest deve responder, quais propostas estão incluídas e o que cada parte fornece, antes que qualquer pessoa construa algo. Um líder de risco em um banco, descrevendo um esforço de backtesting ainda em andamento, disse: "...acho que houve algumas falhas sobre qual é a capacidade do sistema e o que estamos tentando alcançar... ainda estamos no processo de realizar o esforço de backtesting. Ainda é manual e interno..." Um escopo acordado no início evita que o backtest retroceda para o trabalho manual.

2. Escolha o público-alvo. Selecione propostas que você aprovou, recusou e encaminhou para análise manual em seus segmentos e canais, incluindo históricos de crédito escassos (thin files), intervenções manuais, exceções e casos em que sua política teve dificuldade para decidir.

3. Reconstrua sua política atual em cada plataforma. Peça para sua própria equipe de crédito realizar a construção sempre que a plataforma disser que isso é possível, pois a criação faz parte do teste.

4. Rode novamente o público-alvo e compare decisão por decisão. Analise o conjunto de troca (swap set), ou seja, as aprovações que uma candidata recusaria e as recusas que ela aprovaria, bem como a taxa de concordância geral. Rastreie cada troca até a regra ou campo de dados que a causou.

5. Compare os resultados onde você os tiver. Os resultados de pagamento existem apenas para as propostas que você aprovou, portanto, uma comparação de resultados cobre suas aprovações. Avaliar uma candidata que aprovaria proponentes que você recusou exige inferência de rejeitados (reject inference) ou um teste em tempo real, já que esses proponentes não têm histórico de pagamento. Um credor de consumo que avalia ferramentas de modelagem listou o viés de amostra de decisões de políticas anteriores e a inferência de rejeitados entre os detalhes complexos que espera que uma plataforma compreenda.

6. Simule uma mudança. Adicione ou remova uma regra e veja o que ela teria feito com o mesmo grupo de propostas. Um diretor de estratégia de crédito em uma fintech de crédito descreveu como faz isso manualmente: "...se eu retirar esta regra ou se adicionar esta regra, isso aumenta ou diminui o modelo geral? Isso é algo que faço manualmente hoje e de forma mais regressiva". Rode a simulação (what-if) na plataforma que decidirá as propostas, para que a configuração testada seja a mesma que você colocará em produção.

7. Teste o que a plataforma oferece de nativo. Faça o backtest dos atributos de dados e pontuações da própria plataforma em suas propostas, além das regras que você configura. Um credor digital que compara fornecedores concorrentes de pontuação de fluxo de caixa mostrou-se aberto a testar atributos e pontuações nativos de uma plataforma antes de confiar neles.

A parte de resultados de um backtest é o que os órgãos reguladores chamam de análise de resultados. As diretrizes interinstitucionais revisadas sobre gestão de risco de modelos, emitidas em 17 de abril de 2026, afirmam que a análise de resultados "compara os resultados do modelo com os resultados correspondentes do mundo real para avaliar o desempenho do modelo em relação aos seus objetivos e uso comercial". As diretrizes listam "atividades autônomas, como backtesting ou análise de outliers" entre suas formas.

Defina os termos de uso de dados com a assessoria jurídica e sua equipe de privacidade antes que qualquer dado de propostas saia da empresa: quais dados, em qual formato e sob qual acordo. Pergunte a cada provedor como ele roda um backtest quando dados completos não podem ser compartilhados e inclua a resposta no escopo.

Como é um resultado fraco de backtest

• Os engenheiros do provedor reconstroem sua política, de modo que o teste mostra o trabalho deles e não o da sua equipe.

• Os resultados chegam como uma taxa de concordância agregada, sem o conjunto de troca (swap set) ou com diferenças que ninguém consegue rastrear até uma regra ou campo de dados.

• A simulação roda em um ambiente diferente da plataforma que decidirá as propostas reais.

• Afirmações sobre como os proponentes recusados teriam se comportado vêm sem nenhuma metodologia que as sustente.

Test 2: Rode um desafiante (challenger) ao lado de sua política atual durante a avaliação

Um desafiante rodando ao lado de sua política atual mostra o que uma plataforma decide com os proponentes e dados de hoje, algo que um backtest em propostas passadas não consegue mostrar. Em um teste de campeão-desafiante (champion-challenger), sua política atual (a campeã) continua tomando as decisões reais, enquanto a candidata (a desafiante) decide as mesmas propostas em tempo real em paralelo. Um diretor de produto em uma empresa de crédito ao consumidor, falando sobre mudanças de política, perguntou: "Por que não rodar várias delas em modo sombra (shadow) e ver o que faz mais sentido?"

Peça por um modo sombra real, no qual a candidata decida cada proposta em tempo real e nenhuma de suas decisões chegue ao proponente. Sem isso, os credores recorrem a soluções improvisadas, descritas por um líder de tecnologia de risco de crédito de um credor de consumo: "...o mais próximo que chegamos é lançar um modelo, calcular uma pontuação e não fazer nada com ela... ou ter um champion-challenger rodando com um volume baixo. E... se as coisas derem errado, podemos reverter muito rápido, mas isso não é uma pontuação em modo sombra real". Pergunte também se o modo sombra oferecido roda em propostas reais ou em um ambiente de teste onde você carrega os dados, pois um ambiente de teste roda novamente dados que você forneceu e equivale a um segundo backtest.

O lançamento gradual é um substituto comum para uma divisão real. Um diretor de estratégia de risco de crédito em um grande banco regional descreveu um caso: "Não era um champion-challenger, mas lançamos lentamente a nova política de cartões em uma parcela do nosso público apenas para garantir que tudo estava funcionando". O lançamento gradual protege a carteira enquanto uma mudança entra em vigor, mas não mostra como duas políticas decidem sobre os mesmos proponentes, portanto, saiba qual das duas opções está sendo oferecida.

O que verificar enquanto o desafiante roda

• Atribuição consistente. Um proponente que retorna ou faz uma nova proposta deve cair no mesmo grupo do teste, caso contrário a comparação será contaminada. Pergunte como a plataforma garante a consistência dessa atribuição.

• A versão e o grupo em cada proposta. A plataforma deve mostrar, para qualquer proposta, por qual versão de política e por qual grupo de teste ela passou, inclusive quando os testes se sobrepõem. Um credor digital cuja tomada de decisão havia se tornado muito personalizada identificou a sobreposição de experimentos como sua maior dor de cabeça: proponentes que se qualificavam para mais de um tratamento, randomização rodando em uma ferramenta separada e dificuldade crescente para confirmar se cada proponente passou pelas verificações corretas.

• Visualização dos resultados na plataforma. Verifique se o desafiante roda e pode ser analisado diretamente na própria plataforma, em vez de exigir a exportação para análise em outra ferramenta.

• Critérios de saída definidos com antecedência. Decida antes do início do desafiante quais métricas encerrarão o teste e por qual margem, em vez de fixar apenas uma duração de tempo.

Após a compra, essas mesmas práticas passam a fazer parte do controle de mudanças, e nosso guia sobre governança de implantação de modelos de crédito aborda testes em modo sombra, champion-challenger e lançamentos graduais em produção.

Como é um resultado fraco do desafiante

• As únicas opções são uma pontuação silenciosa ou uma divisão em tempo real com volume muito baixo.

• O modo sombra consiste apenas em carregar dados em um ambiente de teste separado.

• A plataforma não consegue mostrar por qual versão e grupo uma proposta passou, ou permite que um proponente que retorna mude de grupo.

• Os resultados existem apenas como exportações para análise externa.

Teste 3: Avalie os motivos das ações adversas, não apenas as aprovações

Uma plataforma que aprova bem, mas explica mal as recusas, falha onde as regras são mais específicas: na declaração de motivos em um aviso de ação adversa. O Regulamento B estabelece que a declaração de motivos "deve ser específica e indicar o principal motivo ou motivos para a ação adversa". O mesmo parágrafo acrescenta: "Declarações de que a ação adversa foi baseada nos padrões ou políticas internas do credor, ou de que o proponente não atingiu uma pontuação mínima no sistema de pontuação de crédito do credor, são insuficientes".

Quando um relatório de crédito do consumidor contribui para uma recusa, o aviso também deve conter as informações exigidas pela seção 615(a) do FCRA: os dados da agência de crédito, uma declaração de que a agência não tomou a decisão, os direitos do consumidor de obter um relatório gratuito e de contestá-lo, além da pontuação de crédito, se tiver sido utilizada. Uma recusa precisa sair da plataforma com informações suficientes para apoiar ambas as exigências. O CFPB retirou suas circulares sobre avisos de ações adversas em maio de 2025, mas a exigência do regulamento por motivos específicos continua de pé, e a norma do Regulamento B emitida em abril de 2026 não alterou os requisitos do aviso.

Como testar os motivos em recusas reais

1. Veja o que sai da plataforma em uma recusa. Um líder de sistemas de crédito em um banco regional fez a pergunta diretamente: "E a carta de ação adversa para o cliente, qual é o arquivo enviado se houver uma recusa?" Pegue uma amostra de recusas reais do seu backtest e analise o resultado gerado para cada uma.

2. Vincule cada motivo de volta à etapa que gerou a recusa. Um líder de crédito em um emissor de cartões, incerto sobre o nível de detalhe que os reguladores exigiriam nos motivos de recusa, disse: "Eu precisava garantir que... conseguia vincular o motivo diretamente à... decisão". O motivo em cada aviso deve apontar para a regra ou resultado do modelo que decidiu a proposta.

3. Confirme se os fatores do relatório de crédito chegam à carta. Um líder de operações de crédito em uma financeira para pequenas empresas precisava dessa confirmação: "...há certos códigos de fatores do relatório de crédito que precisam constar na carta. Nós enviamos isso... mas não temos certeza se esses códigos de fatores estão realmente sendo extraídos de forma correta. Precisamos de uma confirmação disso".

4. Analise a lista de códigos de motivo. Códigos duplicados ou vagos geram cartas genéricas, quer venham da plataforma ou de um provedor de dados integrado. Analise a lista completa como sua equipe de compliance faria.

5. Decide se você enviaria essa mensagem. Para cada recusa amostrada, verifique se os motivos, conforme redigidos, atendem à exigência de especificidade sem necessidade de edição manual.

Os códigos de motivo também determinam se uma equipe de crédito confia ou não em uma plataforma. Um diretor de risco de crédito de uma fintech de crédito lembrou que "...havia uma pressão forte interna na empresa dizendo: precisamos dos códigos de motivo".

A revisão de concessão justa (fair lending) de uma nova política continua sendo responsabilidade do seu programa de compliance. Portanto, coloque-a no plano de avaliação como uma frente de trabalho da sua equipe, rodando com base nas decisões geradas pelo backtest e pelo desafiante. O crédito ao consumidor traz sua própria complexidade, que é abordada em nosso guia sobre motivos de ação adversa quando uma decisão de consumo é automatizada.

Como é um resultado fraco em recusas

• Os motivos aparecem como categorias genéricas, ou citam apenas padrões internos ou pontuação insuficiente.

• Não é possível rastrear o motivo até a regra ou modelo que recusou a proposta.

• Os fatores do relatório de crédito que o aviso exige não chegam ao documento final, ou os motivos precisam ser mapeados manualmente após a decisão.

• A lista de códigos de motivo contém duplicatas que ninguém consegue explicar.

Teste 4: Cronometre uma alteração de política real, incluindo exceções

A maneira mais rápida de aprender como uma plataforma lida com mudanças é fazer uma alteração real nela durante a avaliação e cronometrar o tempo decorrido desde a solicitação até a publicação. Escolha uma mudança que sua equipe realmente precise, como um novo limite de corte, uma nova fonte de dados ou um novo caminho de exceção, e acompanhe o fluxo em cada plataforma: quem faz a alteração, como ela é testada, quem a aprova, como é lançada e como é desfeita (rollback). Uma demonstração de edição rápida mostra apenas as habilidades do apresentador.

O teste costuma ser a etapa que mais consome tempo. Um executivo de crédito em um grande banco regional comentou que uma nova política de cartões levou meses do início ao fim, com grande parte do tempo gasta em testes, e descreveu o trabalho: "O grande esforço é sempre o teste, que considero manual... eles constroem casos de teste manualmente, mas depois acionam diferentes ramificações da política para garantir que ela seja implementada conforme o esperado". Peça a cada plataforma para gerar e simular casos de teste para sua alteração e cronometre essa etapa separadamente.

O caminho de lançamento é tão importante quanto a edição em si. Um diretor de estratégia de risco de crédito de um grande banco regional disse que o lançamento de política mais rápido que já viu "exigiu a intervenção do nosso diretor de operações" e que outras mudanças aguardavam as atualizações agendadas do sistema após a aprovação da governança. O mesmo diretor descreveu a economia gerada ao rodar novamente propostas anteriores em uma política editada: "Este é o tempo que minha equipe leva para dimensionar quais são as mudanças e qual será o impacto... queremos ajustar isso e rodar novamente, e basta que alguém... rode no motor de decisão e vemos os impactos em tudo. É muito mais rápido". Dimensionar o impacto faz parte da mudança, então cronometre isso também.

Pergunte quem pode fazer a mudança, além de quão rápido ela ocorre. Um líder de engenharia e dados de um credor automotivo descreveu uma mudança urgente de regra que passou do CEO para um gerente de produto e depois para um engenheiro, com um ticket aberto para compliance, e o engenheiro "alterou o JSON, sem precisar de uma nova implantação do serviço". Uma mudança rápida que ainda depende de um engenheiro editando configurações é uma mudança que sua equipe de crédito não consegue fazer de forma autônoma.

As evidências de mudanças são auditadas, por isso teste o que a plataforma registra. Um líder de implementação em um banco descreveu a mudança de cenário: "...agora eles querem... evidências de... uma solicitação de mudança porque querem auditar tudo para o nosso lançamento. Isso vai se tornar um atrito em nossa forma de trabalhar porque vínhamos... nos movendo rápido, mas cada nova mudança agora exige uma solicitação formal de mudança, que é um [ticket]". A plataforma deve registrar quem alterou o quê, quando e com a aprovação de quem, para que as evidências não fiquem perdidas em um sistema de tickets separado.

Exceções, intervenções e encaminhamentos

Crie uma exceção ou uma intervenção manual (override) durante o teste e observe como ela é capturada, aprovada e relatada. Um credor comercial sênior em um banco comunitário trouxe a pergunta ideal para fazer a todas as plataformas: "Existe uma maneira de fazer intervenções manuais aqui dentro? Ou você é obrigado a seguir estritamente a política de crédito depois de inseri-la?" Uma resposta robusta permite que a equipe de crédito faça intervenções dentro da própria plataforma, mantendo o registro de quem fez a alteração e por quê.

O manual de gestão de risco de crédito do OCC descreve que o registro de empréstimos geralmente inclui "a captura de exceções à política e requisitos de monitoramento contínuo para fins de rastreamento e relatórios", e alerta que "quando agregadas, mesmo as exceções bem mitigadas podem aumentar significativamente o risco da carteira". Verifique se uma exceção feita na plataforma chega aos relatórios de forma consolidada com as demais, sem necessidade de planilhas paralelas.

O encaminhamento para análise manual (refer) também é um caminho de exceção. Um líder de sistemas de crédito em um banco regional descreveu o que deve acontecer quando o motor retorna um encaminhamento em vez de uma aprovação: "aquele analista que entra para analisar as coisas manualmente... e depois ter a trilha de auditoria de quem fez o quê". Encaminhe algumas propostas para análise manual durante o teste e analise a trilha que cada uma deixa.

Pergunte também o que acontece com as propostas que já estão em andamento quando uma nova versão de política entra em produção, e acompanhe isso durante o teste. Se essas propostas terminam na versão em que começaram ou se migram para a nova é uma decisão que deve ser tomada e registrada intencionalmente.

Como é um resultado fraco em uma mudança de política

• A mudança exige engenheiros do provedor ou uma edição de configuração por sua própria equipe de TI.

• Os casos de teste são construídos manualmente para cada alteração, e a cronometragem para antes dos testes, da aprovação ou do lançamento.

• As intervenções manuais e exceções ficam salvas em anotações ou planilhas fora da plataforma.

• Ninguém sabe dizer o que aconteceu com as propostas em andamento.

Teste 5: Acorde o que o monitoramento deve mostrar após o go-live

Decida antes de assinar o contrato o que a plataforma deve mostrar semanalmente após o go-live, e verifique durante a avaliação se ela consegue exibir essas informações com seus dados. Decisões que pareciam corretas nos testes podem sofrer desvios à medida que os proponentes, os dados e o mercado mudam, e você tem mais poder de exigência sobre o que a plataforma mostrará antes de fechar o contrato. No mínimo, acorde visualizações de:

• taxas de aprovação e recusa por segmento e canal;

• a distribuição dos motivos de recusa;

• taxas de intervenções manuais e exceções;

• o desempenho inicial das novas aprovações;

• desvio (drift) de dados, variáveis e conceitos, analisados juntamente com métricas de resultados por segmento.

Os órgãos reguladores trazem a questão nos mesmos termos. As diretrizes revisadas descrevem o monitoramento contínuo de modelos como "uma avaliação da medida em que um modelo está desempenhando conforme o esperado, dadas as mudanças potenciais em produtos, exposições, atividades, clientes, relevância dos dados ou condições de mercado". Elas acrescentam que um modelo que não apresenta mais o desempenho esperado "pode justificar ajustes ou o redesenvolvimento do modelo", portanto, defina com antecedência o que conta como baixo desempenho e quais serão as próximas etapas.

Os credores que operam por meio de bancos parceiros enfrentam a mesma exigência. Um executivo de risco em uma fintech de crédito ao consumidor afirmou que os modelos de originação "devem resistir ao escrutínio regulatório" e que seus bancos parceiros esperam um monitoramento contínuo para desvio de dados e desvio de conceitos nas variáveis e na pontuação.

Analise os resultados pela versão da política ou pelo processo que aprovou cada conta, e não apenas para a carteira como um todo. Um analista de risco em uma fintech de cartões corporativos descreveu a visualização que utiliza: "...temos um gráfico para monitorar a taxa de inadimplência... taxa de inadimplência para os clientes que foram aprovados a partir deste processo. Isso é algo que podemos usar para monitorar essa estratégia..."

A carteira continua sendo decidida após a aprovação, por meio de gestão de limites, alertas preventivos e cobranças, de modo que uma alteração na originação deve ser rastreável até o impacto que gera posteriormente. Um analista de risco de um credor automotivo queria esse vínculo entre as mudanças nas políticas de originação e os resultados de atendimento e cobrança, e nosso guia sobre monitoramento da carteira pós-originação aborda essa perspectiva em detalhes.

Defina quem estabelece os limites de tolerância, em quais métricas, e o que acontece quando um limite é ultrapassado. Um diretor de estratégia de crédito de uma fintech perguntou se o monitoramento permitiria que o credor definisse sua própria tolerância de desvio nas métricas de empréstimo "ou se vocês estão definindo as métricas de empréstimo para os clientes no monitoramento". Exija uma resposta em que sua equipe defina as tolerâncias e a plataforma envie alertas sobre elas.

Decida também o que a plataforma mostrará e o que ficará hospedado em outro lugar. Um credor de consumo realiza o monitoramento do portfólio pós-originação e todo o desenvolvimento de modelos fora de seu motor de decisão, já tendo migrado seu monitoramento entre ferramentas mais de uma vez. Onde quer que o monitoramento fique hospedado, defina isso durante a avaliação para evitar a reconstrução em ferramentas paralelas após o lançamento.

Como é um resultado fraco em monitoramento

• O monitoramento é prometido apenas para uma fase posterior.

• As visualizações cobrem a carteira como um todo, mas não conseguem separar por versão de política ou processo que aprovou cada conta.

• O provedor define as tolerâncias, ou ninguém as define.

• O desvio (drift) é relatado sem nenhum gatilho para ação.

Uma tabela de pontuação para comparar plataformas em suas próprias propostas

Atribua uma nota para cada plataforma finalista em relação às suas decisões atuais e às tolerâncias acordadas antes dos testes. A tabela apresenta o que medir em cada teste e como é um resultado fraco. Defina seus próprios pesos, pois eles dependem da sua carteira de clientes.

O que guardar da avaliação

Guarde o grupo de propostas utilizado, o método, os resultados, como cada diferença foi interpretada e por que você tomou a decisão. Esse registro atende ao risco de modelo, ao comitê de crédito e aos auditores, e é muito mais difícil de ser reconstruído após a assinatura do contrato.

A área de risco de modelo precisará do registro logo no início. Um líder de gestão de risco de modelo de um banco regional explicou a ordem claramente: "Precisamos validar o modelo antes que... a linha de frente o implemente e o coloque em funcionamento".

Qualquer decisão no teste deve ser passível de reconstrução a partir dos dados de entrada, da versão da política e dos motivos gerados. Um líder de risco de um banco descreveu o que aconteceu quando os reguladores pediram para verificar as decisões tomadas: "O que os reguladores nos disseram foi: vocês precisam validar o que está implementado... tudo o que consta na política de crédito de vocês, comecem a nos enviar cada proposta e cada ponto de dados que entra nessa decisão, para que possamos verificar o motor de decisão". Esse é o relato de um banco sobre o feedback de auditoria, e não uma regra geral, mas ilustra o tipo de evidência que um credor pode ser solicitado a fornecer.

Os modelos de um provedor continuam sendo sua responsabilidade para compreender e monitorar. As diretrizes revisadas afirmam: "As instituições financeiras podem não receber do fornecedor o código subjacente, os dados ou a metodologia que receberiam se o modelo fosse desenvolvido internamente. No entanto, os princípios de gestão de risco de modelo continuam aplicáveis". O documento acrescenta que uma prática recomendada envolve "conduzir monitoramento contínuo e análise de resultados para avaliar se os modelos dos fornecedores são precisos, permanecem adequados ao propósito e continuam confiáveis". O backtest, o desafiante e o plano de monitoramento são os pontos de partida para esse trabalho.

O que o registro deve conter

• O grupo de propostas: quais propostas, de qual período, abrangendo quais segmentos e canais.

• O método: o escopo documentado por escrito, como a versão da sua política foi construída em cada plataforma e o que cada parte forneceu.

• Os resultados: a concordância e o conjunto de troca (swap set), comparações de resultados, as análises do desafiante, as recusas amostradas e os tempos da mudança de política.

• A interpretação: como cada diferença foi explicada e por quem.

• O plano de monitoramento: as visualizações, limites de tolerância e responsáveis acordados para o go-live.

• A decisão: por que você escolheu essa plataforma e quais indicadores fariam você reavaliar a escolha no futuro.

Como a Oscilar aborda uma avaliação de crédito

As páginas de subscrição de crédito da Oscilar descrevem a realização de backtests em dados históricos para validar novas políticas de crédito antes de sua implantação, testando o desempenho de modelos em várias versões e gerenciando taxas de aprovação, taxas de inadimplência e KPIs personalizados. Esses recursos são testados na prática pelo seu backtest, desafiante e monitoramento, portanto, execute-os com seus próprios dados.

Após o go-live, a Oscilar monitora desvios de dados, variáveis e conceitos, juntamente com KPIs de resultados por segmento. Para o registro que este guia sugere que você mantenha, a plataforma fornece uma trilha de auditoria completa por decisão com justificativas armazenadas, além do conceito de intervenção humana (human-in-the-loop) por design. A especificação técnica da plataforma entrega decisões em menos de 100 milissegundos.

A Chartis Research incluiu a Oscilar em sua lista FCC50 de 2026, que classifica os principais fornecedores de tecnologia de conformidade e crimes financeiros, com vitórias nas categorias de Personalização Low-Code/No-Code e Inovação em IA Agêntica. Essa classificação cobre tecnologia de conformidade e crimes financeiros em vez de decisão de crédito, de modo que o teste decisivo para uma plataforma de crédito continua sendo aquele que você mesmo realiza com suas propostas. Os clientes da Oscilar incluem a SoFi, Nuvei e Clara, cujos estudos de caso estão disponíveis nas páginas de soluções de crédito da Oscilar.

Perguntas frequentes

Devemos comparar as plataformas entre si ou com as nossas decisões atuais?

Compare cada plataforma com suas decisões atuais. Suas decisões atuais são a referência: a plataforma deve corresponder a elas onde sua política está correta e explicar cada ponto de divergência. Comparar as plataformas entre si favorece aquela que realizou a melhor apresentação comercial, o que diz muito pouco sobre como ela realmente decidiria suas propostas.

Um credor pode fazer o backtest de uma plataforma em suas próprias propostas antes de assinar o contrato?

Defina os termos de uso de dados com a assessoria jurídica e sua equipe de privacidade primeiro: quais dados de propostas podem ser compartilhados, em qual formato e sob qual acordo. Em seguida, pergunte a cada provedor como ele roda um backtest quando os dados completos não podem ser compartilhados e registre ambas as respostas no escopo do backtest. A possibilidade de realizar um backtest pré-contratual depende desses termos, por isso trate-os como o primeiro passo do teste.

Por quanto tempo um desafiante (challenger) deve rodar durante uma avaliação?

Um desafiante deve rodar até atingir os critérios de saída definidos antes do início do teste. Decida previamente quais métricas você comparará, por qual margem e em quais segmentos e canais. Com os critérios estabelecidos no início, o teste se encerra assim que o resultado se mostrar claro.

O que torna o motivo de uma ação adversa específico o suficiente para ser enviado?

O motivo de uma ação adversa é específico o suficiente quando descreve a razão principal da decisão e a vincula diretamente à regra ou ao resultado do modelo que a determinou. O Regulamento B exige motivos principais específicos e estabelece que declarar que a decisão se baseou nos padrões internos do credor ou que o proponente não atingiu uma pontuação mínima é insuficiente. Onde houver contribuição de um relatório de crédito do consumidor, o aviso também deve conter as informações exigidas pela seção 615(a) do FCRA.

Quantas plataformas um credor deve testar com seus próprios dados?

Teste apenas as plataformas que você realmente tem intenção de comprar, pois cada teste exige esforço real de suas equipes de crédito, dados e compliance. Uma lista longa de opções deve ser avaliada na fase anterior de seleção de finalistas; os testes deste guia são destinados aos concorrentes finais. Execute os mesmos testes com as mesmas propostas para cada plataforma avaliada, permitindo a comparação direta dos resultados.

A melhor plataforma de decisão de risco de crédito para a sua operação é aquela que passa nos cinco testes usando suas próprias propostas: ela corresponde às suas decisões onde deve, explica cada diferença, gera motivos de recusa que você enviaria sem receio, lida com mudanças de políticas reais e suas exceções, e demonstra após o go-live se continua se comportando como foi testada. Execute os cinco testes em cada finalista, compare cada uma com suas próprias decisões e guarde o registro do motivo de sua escolha. Para ver como a Oscilar apoia o crédito ao consumidor, leia sobre a subscrição de crédito ao consumidor da Oscilar.