Motor de Decisão de Crédito: Um Checklist de RFP para Credores

Última atualização: Setembro de 2026

Um RFP para motor de decisão de crédito deve descrever o que a equipe de crédito precisa ser capaz de fazer após a migração, pois um RFP escrito com base nas integrações, campos de dados e contagens de regras atuais apenas garante uma cópia mais rápida do sistema atual. Escreva cada requisito como um resultado esperado, peça para cada fornecedor demonstrar isso usando seus próprios dados em vez de apenas descrever, e defina os pesos antes que as propostas comecem a chegar. Faça de um teste real em suas próprias propostas de crédito uma condição para a seleção dos finalistas. Defina os termos para propostas em andamento, decisões históricas e execução em paralelo no próprio RFP, enquanto você ainda tem poder de negociação.

Resumo Direto

• Um RFP copiado das integrações, campos e contagem de regras do sistema atual carrega os limites desse sistema para o novo contrato. Escreva os requisitos como resultados que a equipe de crédito deve alcançar após a migração, e liste os limites de integração separadamente.

• Peça para cada fornecedor mostrar cada funcionalidade usando seus dados ou em uma sessão prática de trabalho. Uma funcionalidade demonstrada pontua mais do que uma apenas descrita.

• Defina os pesos com as equipes de compliance, crédito, risco e tecnologia antes que qualquer proposta chegue, e avalie os requisitos obrigatórios como "aprovado" ou "reprovado".

• Defina uma prova em suas próprias propostas de crédito como condição para a lista de finalistas: um backtest em propostas passadas e um teste em paralelo real nas propostas ativas, com critérios de sucesso assinados por ambos os lados antes do início.

• Resolva no próprio RFP como as propostas em andamento serão tratadas, onde as decisões históricas ficarão armazenadas, como a execução em paralelo será encerrada e qual será a estratégia de saída.

• O RFP é onde começa a auditoria de terceiros. As diretrizes interagências de junho de 2023 sobre relacionamentos com terceiros estão em vigor desde 28 de setembro de 2026, mas as agências propuseram uma substituição em 11 de setembro de 2026, por isso verifique qual versão se aplica quando seu RFP for lançado.

O que um RFP de motor de decisão de crédito precisa acertar?

Um RFP de motor de decisão de crédito precisa descrever o modelo operacional que a instituição financeira deseja após a migração, pois requisitos copiados do sistema atual apenas compram uma versão mais rápida dele. O RFP deve conter seis partes: requisitos escritos como resultados esperados, perguntas que façam cada fornecedor demonstrar esses resultados, pesos definidos antes do recebimento das respostas, uma prova em propostas reais da própria instituição como condição para a lista de finalistas, checagem de referências e os termos de migração e transição.

Um motor de decisão de crédito é o sistema que executa as chamadas de dados, regras, modelos e políticas que transformam cada proposta de crédito em uma decisão e justificativa. O funcionamento de um motor é detalhado em o que é e o que faz um motor de decisão; este guia foca em como comprar um.

O RFP costuma ser uma de três frentes de trabalho executadas ao mesmo tempo. Um gerente de projetos e risco de fornecedores em um banco descreveu essas frentes como "linhas paralelas que podemos fazer simultaneamente": "detalhar o RFP é uma delas", a análise de risco de terceiros é outra, "e depois também a prova de conceito". Escreva o RFP para abastecer as outras duas frentes, incluindo as perguntas de due diligence que a equipe de risco faria de qualquer forma e os termos de prova exigidos para os finalistas.

Se a equipe ainda não decidiu se vai desenvolver internamente ou comprar pronto, resolva isso antes de escrever o RFP, que assume que a resposta é comprar.

Por que os RFPs acabam especificando o sistema que você quer substituir

Os requisitos geralmente começam a partir da documentação do sistema atual, pois é o que a equipe tem em mãos. Suas integrações, campos de dados e contagens de regras são copiados para o RFP como requisitos, trazendo junto os velhos hábitos. Um oficial de conformidade de um banco, ao planejar a substituição de um sistema, apontou o hábito a ser evitado: o mapeamento de dados feito "do jeito mais fácil" e baseado no "sempre foi feito assim", que ele descreveu como "uma frase comum por aqui que precisamos eliminar".

O documento de requisitos resultante costuma ser genérico e sem um dono definido. Ao ser questionado se existia um documento de requisitos de negócio para a plataforma em avaliação, um líder de crescimento de uma empresa de ativos digitais respondeu: "Temos um bem genérico", e acrescentou que "precisa ser mais detalhado e específico, principalmente sobre... qual é a tolerância ao risco, que tipo de controles queremos ter?". A empresa também estava contratando "uma pessoa que será responsável por este fluxo", o que é a solução certa: um RFP precisa de um dono que possa definir o que a equipe de crédito precisa ser capaz de fazer.

Parte da rigidez do sistema a ser substituído foi projetada no momento da compra, em conjunto pelo comprador e pelo fornecedor. Um vice-presidente sênior de prevenção à lavagem de dinheiro em um grande banco regional, descrevendo o sistema atual da instituição, disse que "tanto o cliente quanto o fornecedor foram cúmplices em certas escolhas de design" e que o resultado ficou "muito engessado": "você precisa levar o carro de volta à concessionária para qualquer ajuste no motor. Você não consegue fazer nada sozinho". Um RFP escrito com base na estrutura atual repete esse mesmo erro para o próximo motor.

O custo dessa rigidez aparece sempre que a equipe de crédito precisa de uma mudança. Em um grande banco regional, um executivo de crédito disse que uma nova política de cartões levava meses de ponta a ponta, sendo que a maior parte desse tempo era gasta com testes. Um diretor de crimes financeiros em uma emissora de cartões afirmou que "cada solicitação de mudança custa uma fortuna" e que a equipe buscava "um sistema que seja muito mais focado em autoatendimento, porque literalmente não aguentamos mais pagar por solicitações de alteração".

Nada disso significa que o sistema atual seja ruim, e um RFP que o descreve como quebrado tira a credibilidade do comprador. Um diretor sênior de crédito de um banco digital, ao elaborar um plano de negócios, comentou: "estamos em uma situação razoavelmente boa com o [nosso sistema atual]. Então, ele não está quebrado", e planejou reescrever uma avaliação da situação atual que mostrava "capacidade limitada ou inexistente", pois "se eu apresentar este plano de negócios para a diretoria, eles vão questionar o que eu andei fazendo até agora, certo?". Descreva o sistema atual com precisão e defina os argumentos de mudança com base no que o modelo operacional precisará após a migração.

Uma forma de manter os requisitos focados no futuro é o método descrito por um líder de operações da área de crédito e cobrança de uma empresa de serviços financeiros digitais: "um documento de requisitos ou especificações" cobrindo o que seria necessário para atender às demandas internas, comparado a "um documento de contraste com tudo o que já vem pronto de fábrica" dos fornecedores. Monte o documento de requisitos com as capacidades que a equipe de crédito precisará e use o contraste para ver quais fornecedores já as atendem prontamente.

Sinais de que um RFP está apenas descrevendo o sistema antigo:

• Os requisitos mencionam as integrações, campos ou contagens de regras atuais em vez do que a equipe de crédito precisa ser capaz de fazer.

• O documento de requisitos é um modelo genérico ou não tem um dono responsável.

• Cada alteração descrita nos requisitos pressupõe que o fornecedor é quem deve realizá-la.

• O estado atual é descrito como totalmente quebrado ou inútil, quando na verdade não está.

• Os termos de migração são deixados para serem discutidos no escopo de trabalho posterior.

Escreva requisitos focando em como você vai operar após a migração

Escreva cada requisito como um resultado que uma equipe específica deve ser capaz de alcançar após a migração, e detalhe quais evidências você aceitará. A tabela abaixo reescreve nove requisitos comumente copiados de sistemas legados em RFPs.

As funcionalidades que realmente importam estão explicadas em o que procurar em uma plataforma de decisão de crédito. O papel do RFP é mais focado: transformar essas necessidades em requisitos que o fornecedor deve comprovar com evidências práticas.

Cada nova versão define quem deve fazer o quê, algo que pode ser testado de forma prática com o fornecedor.

Alterações de políticas e testes vêm em primeiro lugar porque é onde se consome mais tempo. Um executivo de crédito de um grande banco regional explicou que "o maior desafio é sempre a fase de testes, que costuma ser manual", com equipes que "montam casos de teste manualmente e depois acionam diferentes ramificações da política para garantir que tudo funcione como planejado". O requisito deve exigir o que um diretor de estratégia de risco de crédito de um grande banco descreveu: "rodar tudo novamente pelo motor de decisão e ver os impactos em cada detalhe de forma muito mais rápida".

O registro de cada alteração deve ficar no próprio motor, pois as evidências de mudança são auditadas. Um líder de implementação em um banco, ao descrever o início de uma auditoria antes de um lançamento, comentou que "cada nova alteração agora exige um chamado formal de solicitação de mudança". Exija que o próprio motor mantenha esse histórico: quem mudou o quê, quando e com qual aprovação. Usar uma ferramenta de chamados separada deixa as evidências espalhadas.

As decisões excepcionais (overrides) precisam do mesmo cuidado. Um analista sênior de crédito comercial de um banco local perguntou durante uma avaliação de sistema: "Existe uma forma de fazer exceções e overrides diretamente aqui dentro? Ou ficamos totalmente presos à política após cadastrá-la?". Os manuais de supervisão bancária descrevem que o registro de operações deve capturar as exceções às políticas estabelecidas para fins de controle e relatórios, portanto, inclua essa funcionalidade como um requisito.

As justificativas de decisão são obrigações legais, por isso devem estar nos requisitos. A legislação exige que as justificativas de recusa de crédito sejam específicas e indiquem o motivo principal da recusa. O teste que o motor precisa superar é simples, como explicou um líder de crédito de uma emissora de cartões: "eu precisava garantir que conseguia ligar diretamente a recusa à etapa exata da decisão".

Trate também o histórico de decisão como um requisito fundamental. Um líder de risco de um banco lembrou que os auditores disseram: "vocês precisam validar o que está rodando" e pediram para "enviar cada proposta e cada ponto de dado que serviu de base para aquela decisão, para que possamos validar o motor de decisão". Esse relato mostra um ótimo teste para o seu requisito: qualquer decisão deve poder ser reconstruída a partir dos dados de entrada, da versão da política utilizada no momento e das justificativas geradas.

Os testes precisam acontecer dentro do próprio motor que está sendo adquirido. Quando o backtesting e o monitoramento são feitos em um data warehouse separado do motor de decisão, a equipe acaba testando uma cópia da política em vez de testar o sistema real que toma as decisões. Para testes campeão-desafiante, exija um funcionamento em paralelo real sobre as propostas ativas e uma distribuição consistente, evitando que um cliente que retorne caia em um grupo de teste diferente, o que invalidaria a análise.

Informe a volumetria de propostas e consultas estimadas no RFP, exigindo preços de performance e armazenamento nessa escala para evitar surpresas financeiras no futuro. Adicionar uma nova fonte de dados não deve exigir uma reconstrução de plataforma ou desenvolvimento complexo.

Se os modelos de decisão forem criados ou monitorados dentro do motor, detalhe as ferramentas necessárias no requisito. A lista de exigências de uma instituição financeira de crédito pessoal incluiu amostragem e pesos, inferência de rejeitados, testes de validação cruzada, indicadores de estabilidade e poder de separação (como PSI, KS e AUC), como os motivos de recusa são gerados a partir do modelo, análise de características e escolha de algoritmos. Se você preferir trazer modelos próprios, exija um caminho simples para implantação e monitoramento.

Defina claramente o que ficará sob responsabilidade do motor de decisão e o que permanecerá no sistema de originação de propostas (LOS). Uma instituição financeira mantém todas as decisões no motor, mas deixa a geração de contratos e assinaturas em sistemas externos, tratando o motor estritamente como o cérebro das decisões de crédito.

Adicione um requisito essencial focado no futuro: que um novo modelo, fonte de dados ou estratégia chegue ao ambiente de produção sem a necessidade de criar uma nova infraestrutura de TI. Os limites de integração com o sistema principal (core), plataformas de mensageria e birôs são reais, mas devem ser listados separadamente, impedindo que o fornecedor responda a um requisito de negócios enviando apenas um diagrama de arquitetura técnica. Um gerente de estratégia em uma emissora de cartões resumiu as limitações de um sistema antigo à sua arquitetura engessada, destacando a falta de "capacidade de realizar backtests rápidos ou testar diferentes variáveis em tempo real". São exatamente essas capacidades que o RFP deve exigir.

Lista de verificação para o RFP: perguntas para fazer a todos os fornecedores

Cada pergunta abaixo exige que o fornecedor faça uma demonstração com seus dados ou em uma dinâmica prática de trabalho. Copie os tópicos para o seu RFP e adicione seus próprios critérios essenciais. Um responsável pela área de compliance de um banco manteve uma mentalidade chave durante toda a avaliação: "nós realmente fizemos as perguntas mais difíceis ao fornecedor?".

Para cada funcionalidade essencial, pergunte sempre se ela já está em produção ou se está apenas no plano de desenvolvimento futuro (roadmap). Um diretor de prevenção a fraudes, lembrando de uma apresentação sobre um "modelo inovador de IA que seria integrado aos sistemas legados", comentou: "isso realmente funciona hoje? Porque estou vendo um sistema que parece ter anos de atraso".

Alteração e controle de políticas

• Quais recursos incluídos na sua resposta já estão disponíveis hoje e quais estão no plano de desenvolvimento futuro (roadmap)? Vocês se comprometem contratualmente com as entregas desse plano das quais dependemos?

• Mostre de forma prática um analista de crédito alterando uma nota de corte, testando seu impacto e colocando-a em produção, sem o envolvimento da equipe técnica do fornecedor.

• Quem pode aprovar uma alteração de política e onde essa aprovação fica registrada?

• Como são feitas as exceções manuais (overrides), quais limites podem ser aplicados e onde essas exceções aparecem nos relatórios de controle?

• Quais tipos de alterações exigirão o suporte do seu time após o sistema estar no ar e quais são os custos dessas solicitações?

Testes e comprovação prática

• Rode uma amostra de nossas propostas passadas em uma política alterada e mostre de forma detalhada o impacto antes da publicação.

• Mostre uma nova política rodando em paralelo real sobre propostas ativas e aponte onde essas decisões de teste ficam registradas no banco de dados.

• Como o sistema garante que um cliente que retorna para concluir uma proposta permaneça exatamente no mesmo grupo de teste?

• Vocês aceitam realizar um teste prático com nossas próprias propostas antes da assinatura do contrato, sob as condições deste RFP, e existe algum limite de duração para essa validação?

• De quais dados vocês precisam para realizar essa prova, em qual formato, e como conduzem o processo caso não possamos compartilhar informações confidenciais?

Justificativas e recusa de crédito

Um diretor de risco de uma emissora de cartões resumiu bem o nível exigido para essa etapa: "Eu preciso ser capaz de explicar por que escolhemos esses limites de risco. E se a minha explicação for simplesmente 'porque o fornecedor sugeriu', isso não será aceitável para os auditores".

• Mostre os motivos que o seu motor gera para estes exemplos de recusa e ligue cada um deles à etapa específica que reprovou a proposta.

• Envie a lista completa de códigos de motivo de recusa, acompanhada de uma definição clara e direta de cada um deles.

• Mostre as informações do relatório de crédito sendo integradas à notificação de recusa enviada para uma proposta que utilizou essa consulta.

• Como as justificativas de recusa são montadas quando a decisão conta com a participação de um modelo estatístico?

• Qual documentação é disponibilizada para que possamos explicar nossos próprios critérios de decisão e notas de corte sem depender de vocês?

Dados e integração

• Quais fontes de dados já estão pré-conectadas hoje e o que é necessário para integrar uma nova fonte?

• Forneça os custos de performance e armazenamento para os volumes de propostas e necessidades de consulta detalhados neste RFP.

• Como podemos exportar nossos dados de decisão e em qual formato?

Modelos e monitoramento

Um líder de risco de modelos em um banco regional descreveu a ordem natural exigida pelos auditores: "Precisamos validar o modelo de forma independente antes que a equipe de negócios o coloque em produção".

• Quais partes do seu motor são tratadas como modelos estatísticos e qual documentação de suporte acompanha cada uma delas?

• O que nossos validadores internos receberão para cada modelo fornecido por vocês e em qual momento do projeto?

• Como podemos implantar e monitorar um modelo de decisão desenvolvido internamente por nós?

• O que o monitoramento do sistema acompanha de forma ativa pós-implantação e quem recebe os alertas de desvio?

Histórico de decisões e auditoria

• Reconstrua esta decisão antiga para nós: mostre as informações de entrada, a versão da política utilizada no momento e os resultados gerados.

• O que o registro de alteração de regras contém e como podemos exportá-lo para apresentar a um auditor ou regulador?

• Por quanto tempo as decisões e os dados usados para tomá-las ficam armazenados, e em qual formato?

Segurança, resiliência e due diligence de terceiros

• Apresente sua documentação de segurança da informação, bem como seus planos de resiliência operacional e continuidade de negócios.

• Como ocorrem os alertas de incidentes para nossa equipe e quais são os prazos máximos acordados?

• Quais subcontratados têm acesso aos nossos dados ou decisões e qual o processo para nos notificar caso ocorram mudanças nessa lista?

• Apresente suas demonstrações financeiras recentes e apólices de seguros contratadas.

• Com quais indicadores de nível de serviço (SLA) vocês se comprometem em contrato?

Migração e transição

• Como serão tratadas as propostas que já estiverem em andamento no momento da transição e em futuras atualizações de versões de regras? Responda por escrito.

• Qual parte do histórico de dados será migrada do nosso motor atual, em qual formato, e o que permanecerá armazenado no sistema antigo?

• Como os dois motores rodarão em paralelo e o que será considerado uma diferença aceitável ou explicável de decisão entre eles?

• O ambiente de produção será construído do zero de forma limpa ou será promovido a partir do ambiente de testes da prova de conceito?

• Quais acessos vocês precisam do nosso sistema principal (core), do nosso sistema de originação e dos birôs de crédito durante e após a migração, em quais prazos, e quem gerencia cada conexão?

Termos comerciais e encerramento

• Defina os valores para a prova de conceito, a implantação inicial e a mensalidade recorrente antes de iniciarmos os testes práticos.

• Que tipo de suporte técnico e assessoria de crédito estão incluídos após a assinatura e quem serão os profissionais de contato?

• Que tipo de flexibilidade contratual está prevista caso o serviço prestado não atenda às expectativas acordadas?

• Em caso de rescisão, com quais prazos de aviso prévio, planos de transição estruturada e devolução ou eliminação segura de dados vocês se comprometem?

Como avaliar e definir pesos para as propostas

Defina a distribuição de pesos para cada critério antes de receber as respostas dos fornecedores, garantindo que as notas reflitam as prioridades alinhadas internamente. Um especialista em prevenção a fraudes de um banco digital desenvolveu uma matriz de avaliação "com diferentes pesos para cada área" e depois validou a matriz com as outras equipes de negócios, prevendo que a equipe de compliance exigiria que certas obrigações essenciais fossem totalmente atendidas para que o projeto avançasse. Permita que a equipe de conformidade defina esses requisitos obrigatórios e avalie-os como aprovação direta ou desclassificação.

Defina um responsável para cada área de avaliação. Um líder de parcerias de uma fintech que atende bancos regionais descreveu uma matriz de notas dividida de forma que "diferentes membros do time avaliam facilidade de uso, escalabilidade, capacidades nativas, custos de mudança e a solidez do fornecedor". Custos de mudança e planos de continuidade de negócios precisam estar presentes na matriz de notas tanto quanto as funcionalidades técnicas.

Dê mais pontos para o que o fornecedor conseguiu demonstrar na prática do que para o que ele apenas descreveu no papel. Uma funcionalidade demonstrada com suas próprias propostas de teste, em uma sessão prática ou durante a prova de conceito, vale muito mais do que a promessa escrita em uma proposta. Funcionalidades planejadas no roadmap do fornecedor não devem pontuar até que estejam formalizadas no contrato.

Os pesos definidos fazem toda a diferença quando dois fornecedores parecem equivalentes na avaliação técnica. Um líder de risco de um banco, relembrando um processo de escolha anterior, descreveu a situação como "uma decisão extremamente difícil, em que ambos eram muito competitivos e competentes", revelando que a escolha final se deu porque a equipe operacional "simplesmente preferiu a usabilidade da interface de um dos sistemas". Pesos combinados previamente e um teste prático com propostas reais são os fatores que ajudam a diferenciar sistemas que parecem iguais no papel.

Exija o mesmo padrão de excelência de todas as respostas: detalhadas, completas e em conformidade com as regras de governança da empresa. Um gestor de risco de crédito pessoal descreveu o objetivo ideal como "não apenas adquirir um sistema moderno e atraente, mas garantir que ele venha com todos os controles de segurança e governança necessários".

Lembre-se de que os itens avaliados como "aprovado ou reprovado" funcionam como uma barreira: se um fornecedor falhar em um deles, ele estará fora da seleção, independentemente de quão alta seja sua nota nos outros pontos.

Exija um teste real em suas próprias propostas de crédito como condição para a lista de finalistas

A exigência de uma prova prática existe porque os compradores se lembram dos desafios que surgiram na última implementação. Um gestor responsável por contratos e conformidade regulatória explicou por que exigia esse teste: "A solução que temos hoje não atende plenamente o que gostaríamos, certo? Por isso, não queremos nos colocar na mesma situação da última vez que compramos um sistema, onde iniciamos a implementação e só então percebemos que havia coisas básicas que simplesmente não conseguíamos fazer".

Uma demonstração simples não responde a essa dúvida. Um CTO de uma instituição de crédito digital explicou que um teste prático "não precisa ser um projeto enorme", apenas o suficiente para responder a uma pergunta fundamental: "este sistema realmente funciona tão bem quanto na apresentação comercial, ou tudo aquilo foi apenas uma apresentação ensaiada?".

Inclua o teste prático no RFP como condição de seleção, com os seguintes termos:

• Escopo. Um backtest com suas propostas antigas e uma execução em paralelo de forma real sobre as propostas ativas. Um líder técnico de risco de crédito explicou as alternativas fracas comumente sugeridas, como "rodar um modelo apenas para gerar uma nota sem utilizá-la de fato... ou criar um teste campeão-desafiante com volumetria muito baixa", concluindo que "isso não representa um teste em paralelo real".

• Critérios assinados previamente. Defina os prazos, crie os critérios de sucesso que serão validados por ambos os lados e garanta o alinhamento prévio com a diretoria de que a aprovação nesses testes resultará no avanço do projeto. Como desenhar esses indicadores está explicado em critérios de aceitação para uma prova de conceito.

• Responsabilidade de cada lado. Defina claramente por escrito quais pontos o teste precisa validar e o que cada parte deve fornecer. Um líder de risco lembrou que um processo de teste feito de forma manual e demorada ocorreu justamente por falta de definição clara no início: "tivemos falhas em alinhar o que o sistema realmente podia entregar e o que estávamos de fato tentando validar".

• Prazo de teste e limites. Defina a duração máxima dos testes, o volume de dados e o critério para conclusão. Um líder de integração perguntou diretamente ao fornecedor: "Existe alguma restrição técnica do seu lado quanto ao tempo máximo de duração do ambiente de testes?".

• Preço acordado no início. Combine o escopo de valores comerciais antes de iniciar os testes técnicos, evitando que uma ótima validação de sistema fique travada por uma surpresa de orçamento.

Resolva as questões de privacidade de dados com a equipe jurídica e de segurança da informação antes de qualquer dado sair da instituição: defina quais dados serão usados, em qual formato e sob qual acordo de confidencialidade. Cada instituição adota uma estratégia: um líder de operações de dados em um banco disse que poderia fornecer dados reais, mas que "preferia optar por dados sintéticos" se isso acelerasse o processo, esclarecendo que as informações preparadas "foram descaracterizadas, garantindo que não houvesse vazamento de informações de identificação pessoal (PII) ou dados financeiros sigilosos". Pergunte a cada fornecedor como realizar esse teste caso não seja possível enviar dados reais completos.

Tenha clareza sobre o que esse teste pode provar antes de fechar o contrato. Ele mostra as decisões tomadas pelo motor em suas propostas, as justificativas fornecidas e a facilidade para criar, testar e colocar uma nova regra em produção. Ele não consegue prever as perdas de crédito de longo prazo, que só aparecem com o tempo de maturação das carteiras; por isso, a análise de perda é avaliada no backtest com base em dados antigos cujos resultados já são conhecidos. Um líder de estratégia de fraudes alertou que realizar um teste prático de longo prazo entre duas soluções ao mesmo tempo "pode ser extremamente complexo e demorado", já que uma análise comparativa profunda exigiria muitos meses de acompanhamento.

O guia de melhores motores de decisão de risco de crédito define como conduzir esses testes com os finalistas: um backtest de decisões antigas, uma regra desafiante paralela à atual, validação das justificativas de recusa, uma alteração de regra cronometrada e o plano de monitoramento definido antes do go-live.

O que perguntar aos clientes de referência do fornecedor

As chamadas com referências de mercado fazem parte do processo de due diligence, por isso reserve um tempo no cronograma do projeto para isso. Um gerente de projetos de um banco incluiu essa etapa no checklist de homologação de fornecedores, lembrando que "não é apenas uma tarefa formal, é uma etapa essencial de validação".

Peça contatos de referências com perfil semelhante ao seu: mesmo segmento de atuação, produtos parecidos e que tenham migrado de um sistema similar ao que você utiliza hoje. Pergunte sobre os problemas específicos enfrentados por eles e como foram resolvidos. Um analista sênior de crédito comentou que "indicadores genéricos como 'redução de risco médio' não dizem muito", preferindo entender "qual problema operacional específico eles tinham antes da troca e como o fornecedor os ajudou a resolver".

Procure saber sobre o suporte e o conhecimento técnico demonstrados pelo fornecedor após o contrato assinado. Um líder de estratégia de crédito de uma instituição financeira, ao planejar a troca do fornecedor atual, desabafou que os maiores problemas eram "a falta de suporte adequado, falta de conhecimento técnico e a recusa do fornecedor em negociar contratos mais flexíveis".

Perguntas para fazer a cada referência:

• De qual sistema vocês migraram e qual foi o maior desafio no dia do go-live?

• Qual desafio operacional específico motivou a escolha deste fornecedor e como ele foi resolvido?

• Como foi a atuação da equipe de entrega em comparação com o que foi prometido pelo time de vendas?

• Como tem sido o nível de suporte e o conhecimento técnico demonstrados pelo parceiro desde a assinatura do contrato?

• Quais melhorias prometidas no roadmap do produto realmente foram entregues e quais ficaram para trás?

• Quanto tempo leva para vocês alterarem uma regra de decisão hoje e quem realiza esse processo?

Inclua as condições de migração e transição no próprio RFP

Definir condições de migração apenas após a assinatura do contrato tira o seu poder de negociação. Coloque esses termos diretamente no RFP, exija respostas por escrito dos fornecedores e inclua isso na pontuação do projeto. Siga esta sequência de prioridades:

1. Propostas em andamento. Questione por escrito como serão tratadas as propostas iniciadas antes da transição e como o sistema lida com futuras mudanças de versões de regras. Uma proposta que inicia em uma versão de política e finaliza em outra precisa de uma regra clara registrada no sistema para definir qual versão tomou a decisão.

2. Histórico de decisões. As regulamentações exigem que as instituições financeiras conservem os dados das propostas de crédito, relatórios e comunicações enviadas por períodos mínimos que variam conforme o tipo de crédito e legislação local. Defina qual parte desse histórico será migrada para o novo motor, qual parte precisará ser consultada no sistema antigo, quem arcará com esses custos de consulta e trate essa migração histórica como uma frente dedicada desde o primeiro dia do projeto. Um líder de engenharia de uma empresa de pagamentos que optou por não migrar todo o histórico explicou que eles mantêm "uma versão simplificada de consulta do sistema anterior ativa" para que os auditores "consigam acessar as decisões mais antigas". A forma como as regras de retenção de dados se aplicam a cada motor deve ser validada com seu departamento jurídico.

3. Execução em paralelo. Faça o planejamento de transição de trás para frente, considerando o término do contrato atual. Um gestor de projetos estimou a data ideal de go-live considerando os prazos de aviso prévio do contrato vigente, adicionando uma margem de segurança para o final do ano, período em que os projetos costumam desacelerar nas empresas. Um responsável por riscos e compliance reforçou um limite importante: "se quisermos realizar uma execução em paralelo de forma real, ela precisa acontecer antes da data de desativação do sistema antigo". Estabeleça critérios claros para encerrar a fase de testes paralelos e defina as diferenças aceitáveis de decisão, já que o objetivo de um novo motor não é simplesmente copiar as decisões do antigo, mas sim aprimorá-las.

4. Ambiente de produção limpo. Construa o ambiente de produção do zero. Um gestor de projetos de tecnologia recusou a ideia de aproveitar o ambiente da prova de conceito diretamente para a produção, explicando que os planos de virada sempre exigem a exclusão de dados de teste e "você nunca deve realizar exclusões de dados diretamente em um ambiente oficial de produção".

5. Dependências do sistema. Mapeie todos os sistemas dos quais o motor dependerá, como o core bancário, a origination e os birôs, identificando quem gerencia cada um deles. Um diretor de operações de um banco relatou dificuldades para conseguir suporte da equipe do core bancário terceirizado, enquanto todas as informações necessárias para as decisões de crédito precisavam vir justamente dessa integração. Organize a virada de chave respeitando os outros projetos da empresa: um líder de projetos de conformidade optou por não iniciar uma segunda transição de sistema em paralelo a uma migração de plataforma que já estava acontecendo, pois "trazer mais um projeto ao mesmo tempo aumentaria muito a complexidade e o risco de execução".

6. Faseamento de produtos. Se a instituição possui diversos produtos de crédito que serão migrados para um único motor, planeje essa migração em etapas por linha de produto e monte o RFP prevendo todo o portfólio, inclusive os produtos que serão migrados por último. Uma instituição de crédito pessoal adotou essa estratégia para unificar seus produtos em um único motor, migrando uma carteira de cada vez sob o acompanhamento próximo da diretoria.

7. Termos de saída (Exit Strategy). Estabeleça previamente como as informações serão migradas para outro parceiro sem a imposição de custos abusivos e de que forma os seus dados e históricos serão devolvidos ou excluídos com segurança, dentro dos prazos estipulados pela sua instituição.

Após o novo motor estar em operação, cada nova alteração de política deve seguir um fluxo rigoroso de aprovação, teste e publicação, conforme detalhado em controle de alterações com o motor em produção.

A due diligence de terceiros começa na elaboração do RFP

As diretrizes de gerenciamento de risco de terceiros emitidas pelas autoridades reguladoras em junho de 2023 representam o padrão vigente para as instituições financeiras. Em setembro de 2026, novas propostas de atualização foram apresentadas pelos órgãos reguladores; por isso, verifique sempre as regras de compliance mais recentes aplicáveis no momento de lançamento do seu RFP.

As normas regulatórias estruturam o controle de riscos de fornecedores em cinco fases principais: planejamento; due diligence e seleção; negociação contratual; monitoramento contínuo; e encerramento. O RFP faz parte da etapa de due diligence e seleção, sendo precedido pelo planejamento. A regulamentação é muito clara sobre a responsabilidade final: "A contratação de fornecedores e parceiros externos não diminui a obrigação da instituição de cumprir com as exigências regulatórias e de segurança, da mesma forma que ocorreria se as atividades fossem realizadas de forma interna".

Sob as regras atuais, os processos de due diligence devem cobrir temas cruciais como segurança da informação, resiliência de sistemas, relatórios de incidentes e uso de subcontratados. A negociação de contrato, por sua vez, deve prever métricas claras de desempenho, planos de transição em caso de encerramento e a segurança na devolução ou eliminação de dados. Inclua o primeiro grupo como perguntas obrigatórias do RFP e o segundo como termos de contrato, garantindo que os fornecedores respondam e precifiquem esses itens antes da seleção final.

Uma instituição de crédito que faz parte de um grupo financeiro ou opera em parceria com um banco tradicional herda os fluxos de controle desse banco. Um executivo da área de crédito de uma instituição controlada por um banco explicou que "qualquer fornecedor que venha a se integrar com nosso sistema de crédito precisa passar pelo comitê de homologação e compras do banco controlador". Esse fluxo também se aplica a fintechs de crédito que operam em parceria com bancos parceiros, recomendando-se trazer a equipe de gestão de fornecedores do banco parceiro logo na fase de elaboração do RFP.

Os modelos estatísticos utilizados pelo fornecedor continuam sendo de responsabilidade da instituição financeira para fins de validação e entendimento. As orientações regulatórias de risco de modelos alertam que as instituições financeiras "podem não ter acesso total ao código-fonte, dados de treinamento ou metodologia interna do fornecedor de forma idêntica a um modelo próprio desenvolvido internamente. Apesar disso, as boas práticas e princípios de gestão de risco de modelos continuam sendo plenamente aplicáveis". Essas práticas recomendam "desenvolver um entendimento profundo sobre o funcionamento do modelo do fornecedor, incluindo sua consistência teórica, design, dados utilizados no desenvolvimento e performance", além de "realizar monitoramento e análises de resultados frequentes".

As diretrizes de conformidade definem um modelo como "um método, sistema ou abordagem quantitativa complexa que aplica teorias estatísticas, econômicas ou financeiras para processar dados de entrada e gerar estimativas quantitativas", deixando de fora operações aritméticas simples ou fluxos de regras determinísticas básicas que não utilizam teorias estatísticas complexas. Definir quais componentes do motor de decisão se enquadram nessa classificação é uma tarefa para a equipe interna de risco de modelos; por isso, certifique-se de perguntar a cada fornecedor quais módulos são tratados como modelos estatísticos e quais documentos técnicos acompanham cada um.

Como a Oscilar responde a este RFP

As soluções de concessão de crédito da Oscilar permitem que as equipes executem backtests rápidos em dados históricos para validar novas políticas de crédito antes de colocá-las em produção, analisem variações de performance entre diferentes versões de modelos e gerenciem taxas de aprovação, índices de inadimplência e seus próprios indicadores-chave (KPIs). A Oscilar monitora ativamente possíveis desvios de dados, variáveis e conceitos (drift) em paralelo aos KPIs de negócios por segmento.

Para as questões de registro de histórico e controle de alterações, a Oscilar oferece uma trilha de auditoria completa para cada decisão tomada com justificativas armazenadas, trazendo um design focado na supervisão humana das etapas de tomada de decisão (human-in-the-loop). A especificação técnica da plataforma assegura decisões rápidas de crédito, com tempos de resposta inferiores a 100 milissegundos; como em qualquer especificação técnica de mercado, encorajamos que essa performance seja validada com sua volumetria real durante a prova de conceito.

A Chartis Research incluiu a Oscilar em sua prestigiada lista FCC50 de 2026, que destaca as principais empresas de tecnologia financeira e conformidade, com reconhecimento de destaque em inovação com inteligência artificial e personalização no modelo de código simplificado (Low-Code/No-Code). Como essa lista foca em soluções de crimes financeiros e conformidade, ela não estabelece uma comparação direta com outros motores de decisão de crédito do mercado. Entre as instituições financeiras que confiam na tecnologia da Oscilar para decisões de crédito e gestão de risco estão SoFi, Nuvei e Clara.

Perguntas frequentes

Como evitar que o RFP acabe limitando a escolha ao modelo de arquitetura atual?

Escreva cada requisito focando no resultado final que a equipe de crédito precisa alcançar após a migração, como alterar e testar uma política de crédito sem abrir um chamado técnico para o fornecedor, e mantenha as limitações e conectores em uma lista à parte. Peça para cada fornecedor demonstrar esses resultados na prática usando dados reais da sua empresa. Apresente os dados do sistema atual de forma precisa e baseie a justificativa de mudança nos resultados futuros que o novo modelo de operação exige.

Devemos enviar o RFP também para o fornecedor atual?

Sim, caso a instituição realmente considere a possibilidade de renovar a parceria. As respostas do atual parceiro ajudarão a avaliar se o sistema que vocês já utilizam hoje tem capacidade de atender ao novo modelo de operação pós-migração, e submetê-lo às mesmas condições de teste prático garante uma comparação equilibrada. Caso o parceiro atual não consiga atender às exigências mínimas do RFP, o processo servirá como documentação de conformidade sobre a necessidade da troca.

O que um teste prático pode comprovar antes do fechamento do contrato, e o que ele não consegue avaliar?

Um teste prático realizado com suas próprias propostas consegue validar o funcionamento real do motor, a qualidade das justificativas geradas e a facilidade operacional para alterar, testar e publicar uma nova política de crédito. Ele não tem como prever as taxas de inadimplência de longo prazo, uma vez que estas só aparecem após o ciclo completo de pagamento dos empréstimos. As evidências de inadimplência e performance de risco são analisadas através do backtest, rodando regras com base em propostas antigas cujo histórico financeiro já é conhecido.

As diretrizes regulatórias de risco de terceiros de 2023 se aplicam à aquisição de um motor de decisão?

Sim, as diretrizes de gerenciamento de risco de terceiros estão em vigor para as instituições financeiras reguladas, e o processo de RFP para um motor de decisão representa o ponto de partida da fase de due diligence. Em setembro de 2026, propostas de atualização de regras foram apresentadas pelas agências reguladoras com planos de substituir as orientações anteriores assim que as novas versões forem aprovadas. Certifique-se de validar quais regras estão vigentes no momento do lançamento do seu RFP.

Podemos desativar o motor de decisão antigo imediatamente após o novo entrar no ar?

Apenas após definir claramente onde o histórico de dados ficará armazenado. As normas regulatórias exigem que as instituições financeiras mantenham as propostas de crédito recebidas, os relatórios de suporte e as comunicações enviadas aos clientes por períodos mínimos de até 25 meses para crédito a pessoas físicas e 12 meses para crédito a empresas, salvo exceções locais. Portanto, o histórico que não for migrado para a nova solução precisa continuar acessível para consultas futuras em algum ambiente. O RFP deve especificar quais dados serão migrados, quais permanecerão no sistema de origem e como serão mantidos os custos desse armazenamento de consulta.

Como iniciar o processo de RFP para um motor de decisão de crédito

Comece analisando os requisitos que foram extraídos do sistema atual. Reescreva cada um desses pontos como resultados operacionais objetivos que a equipe de crédito deve alcançar após a migração, defina os tipos de evidências técnicas aceitáveis para cada item e estabeleça os pesos de nota antes de lançar o RFP ao mercado. Em seguida, adicione as regras de testes práticos obrigatórios e os termos de migração de sistemas, que são muito mais simples de negociar antes da assinatura do contrato.

Caso a Oscilar esteja entre as empresas finalistas do seu processo de seleção, envie o seu RFP com as mesmas exigências de testes práticos. A página sobre concessão de crédito B2B da Oscilar descreve em detalhes como a plataforma gerencia decisões para crédito comercial.