Última atualização: Outubro de 2026
O software de tomada de decisão de crédito pega nos dados de candidatura de um credor, nos seus modelos e na sua política de crédito, e devolve uma decisão com motivos específicos sobre cada candidatura, sob o controlo da equipa de crédito. Não é uma pontuação de crédito e faz mais do que um motor de regras. Nenhum produto individual é o melhor para todos os credores. Este guia estabelece nove critérios para escolher um software de tomada de decisão de crédito, o aspeto de uma resposta fraca em cada um deles e como verificar cada resposta nas suas próprias candidaturas, em vez de numa demonstração.
Resumo (TL;DR)
O software de tomada de decisão de crédito é a camada de decisão entre o sistema de originação de empréstimos e os fornecedores de dados: entrada de dados, aplicação de modelos e políticas, saída de uma decisão fundamentada e manutenção de registos.
A pontuação de crédito é uma das entradas. Um motor de regras executa a política nas entradas que lhe são fornecidas. O software de tomada de decisão de crédito adiciona orquestração de dados, testes antes do lançamento, motivos, revisão de casos encaminhados e um registo de auditoria.
Escolha com base em nove critérios: quem altera a política, como uma alteração é testada, como os dados entram, como os seus modelos entram, se cada recusa apresenta motivos específicos, o que o registo de auditoria mostra, como as candidaturas encaminhadas são tratadas, se a fraude e o crédito partilham o mesmo fluxo e quem é o proprietário da plataforma após a entrada em funcionamento.
Verifique todas as respostas nas suas próprias candidaturas. Uma demonstração criada com dados de outra pessoa prova muito pouco sobre os seus.
A Oscilar publica este guia e avalia-se a si própria com base nos mesmos nove critérios mais abaixo na página.
O que é um software de tomada de decisão de crédito?
O software de tomada de decisão de crédito recebe dados de candidatura, os modelos de um credor e a sua política de crédito, e devolve aprovação, recusa, encaminhamento ou uma contraproposta, juntamente com os motivos da decisão. A equipa de crédito, e não a engenharia, controla a política executada.
O software de decisão de crédito é a camada de decisão. Situa-se entre o sistema de originação de empréstimos, que gere a candidatura, os documentos e a reserva, e os fornecedores de dados cujas informações alimentam cada decisão. Não substitui o sistema de originação.
Explicar a decisão faz parte do trabalho. De acordo com o Regulamento B, um credor que recuse uma candidatura deve ao candidato uma declaração de motivos, e essa declaração deve "ser específica e indicar o(s) principal(ais) motivo(s) para a ação adversa" (12 CFR 1002.9(b)(2)). O software que decide mas não consegue explicar o motivo deixa a parte mais difícil de uma recusa para outra pessoa.
Este guia destina-se a credores particulares e comerciais, incluindo bancos, cooperativas de crédito e fintechs de crédito, que estão a escolher um software de tomada de decisão de crédito pela primeira vez ou a substituir um motor de decisão que já se tornou pequeno para as suas necessidades.
Pontuação de crédito, motor de regras ou software de decisão de crédito: qual é a diferença?
Uma pontuação de crédito, um motor de regras e um software de decisão de crédito realizam funções diferentes. A pontuação de crédito é apenas um dado de entrada: um número que classifica o risco de um candidato. Um motor de regras executa uma política do tipo "se-então" sobre quaisquer dados recebidos. O software de decisão de crédito adiciona o que envolve ambos: recolhe os dados, aplica os modelos e a política, testa as alterações antes de entrarem em funcionamento, associa motivos a cada decisão, encaminha candidaturas referenciadas para um analista e mantém um registo.
A diferença surge quando as pontuações não coincidem. Um diretor de análise de risco de crédito de uma cooperativa de crédito descreveu como dois fornecedores colocavam o mesmo candidato em escalões de risco muito diferentes e perguntou como resolver a discrepância, pois "se tudo o que vai fazer é... enviar todas estas coisas para revisão manual... esta automatização não alcançou realmente... os seus objetivos de eficiência". Uma pontuação de crédito não consegue resolver isso. A política de crédito, executada dentro do software de decisão, tem de o fazer.
As regras e os modelos também são geridos de forma diferente. Um responsável pelo crédito a particulares num banco regional descreveu uma configuração apenas com regras da seguinte forma: "não é um modelo. É um conjunto de instruções se-então". A orientação atualizada sobre risco de modelo da Reserva Federal, SR 26-2 (17 de abril de 2026, emitida juntamente com o boletim OCC 2026-13 e FDIC FIL-15-2026), define um modelo como "um método, sistema ou abordagem quantitativa complexa que aplica teorias estatísticas, económicas ou financeiras" e exclui "processos e softwares determinísticos baseados em regras".
Os modelos de crédito enquadram-se nessa definição geral, embora a orientação nunca mencione o crédito pelo nome e coloque a IA generativa e agêntica fora do seu âmbito. Na prática, o modelo de crédito que um credor traz enquadra-se na gestão de risco do modelo, enquanto um limite fixo na política de crédito é lido como uma regra determinística. O boletim da OCC também revogou a orientação de exame da OCC de 1997 sobre modelos de pontuação de crédito.
O mesmo responsável pelo crédito a particulares iniciou a avaliação perguntando se a plataforma era apenas um motor de decisão ou se também geria documentos, assinatura eletrónica e a ligação ao sistema bancário principal. Faça essa pergunta a todos os fornecedores, porque as respostas variam.
Pontuação de crédito | Motor de regras | Software de decisão de crédito | |
|---|---|---|---|
O que faz | Classifica o risco de um candidato através de um número | Executa políticas do tipo "se-então" nos dados que recebe | Recolhe dados, aplica modelos e políticas, devolve uma decisão fundamentada |
Quem altera | O criador da pontuação | Frequentemente a equipa de engenharia | A equipa de crédito, com aprovação e registo |
Como é testado | Pelo criador da pontuação | Casos de teste criados manualmente, se existirem | Face a candidaturas passadas e em tempo real antes do lançamento |
O que explica | Os fatores por trás da pontuação | Que regra foi ativada | Os principais motivos da decisão, associados ao que foi avaliado |
O software de decisão de crédito utiliza a pontuação como uma entrada e executa a sua política através de um motor de regras. Para perceber o funcionamento interno, consulte como funciona um motor de decisão.
Como funciona o software de tomada de decisão de crédito
O software de tomada de decisão de crédito executa cinco passos em cada candidatura.
Entrada de dados. O software solicita ficheiros de agências de crédito, dados bancários e de fluxo de caixa e os próprios dados do credor, na ordem que a política exige, para que uma consulta de dados dispendiosa só ocorra se a candidatura chegar a essa fase.
Modelos e políticas aplicados. Os próprios modelos do credor, desenvolvidos no seu ambiente de modelação e integrados no software, pontuam a candidatura. As regras da política de crédito aplicam então limites, elegibilidade e exceções definidas.
Saída de decisão fundamentada. O software devolve aprovação, recusa, encaminhamento ou contraproposta. Cada recusa traz motivos, e a interpretação oficial do Regulamento B indica que estes "devem relacionar-se com e descrever com precisão os fatores realmente considerados ou pontuados por um credor."
Candidaturas encaminhadas para análise. As candidaturas que a política não consegue resolver são enviadas para um especialista em crédito, que terá à sua frente os dados, pontuações e resultados das regras. Cada decisão de sobreposição (override) é gravada com a respetiva justificação.
Registo guardado. Cada decisão é armazenada com os seus dados de entrada, a versão da política e a versão do modelo que a gerou, para que o credor possa reconstruí-la mais tarde.
Os passos quatro e cinco são onde os produtos mais se diferenciam e onde as demonstrações menos revelam.
Precisa de um software de tomada de decisão de crédito?
Um credor provavelmente precisa de um software de tomada de decisão de crédito quando alterar a política de crédito demora mais tempo do que decidir alterá-la. Sinais comuns:
As regras de política estão no código. Um gestor de produto numa fintech de crédito a particulares descreveu a rotina: "se for algo muito simples, limitamo-nos a criar um pedido à nossa equipa de engenharia e eles tratam disso de acordo com as prioridades." O mesmo gestor de produto referiu que "a maioria das nossas regras ainda está codificada de forma rígida (hard coded)."
A lógica de negócio está dispersa por vários canais e sistemas, impossibilitando saber qual versão da política decidiu determinada candidatura.
Testar uma alteração demora mais tempo do que escrevê-la.
O motor resiste à mudança. Um responsável de aquisições num emissor de cartões de crédito descreveu uma plataforma anterior como sendo "muito pouco flexível para fazer qualquer tipo de alteração".
Muitas avaliações começam como uma descoberta de mercado e não como uma falha: a equipa de crédito quer saber o que está disponível e como se compara com o que utiliza atualmente.
Alguns credores não precisam de comprar. Um analista de risco sénior num credor do setor automóvel com o seu próprio motor e uma equipa de TI forte descreveu propostas de políticas a serem enviadas para as TI e lançadas após um curto ciclo de controlo de qualidade, concluindo que um fornecedor de software de decisão não se adequava ao seu caso no momento. Se as alterações de política já são lançadas rapidamente, com testes e registo, o argumento para adquirir um novo software perde força.
Quando o software de tomada de decisão de crédito funciona bem, quatro coisas mudam. A equipa de crédito passa a controlar as alterações de política. As alterações são testadas em candidaturas reais antes do lançamento, cada recusa apresenta os seus motivos e o registo responde às perguntas dos auditores sem necessidade de um programador presente.
Os detalhes variam conforme o segmento. Os credores comerciais que procuram softwares de decisão de crédito B2B podem ler o que o software de subscrição de crédito B2B deve cobrir, e os credores a particulares podem ler como automatizar a subscrição de crédito a particulares.
Encontre o software de tomada de decisão de crédito certo para a sua instituição financeira
Não existe um único software de tomada de decisão de crédito que seja o melhor para todos. O melhor software de decisão de crédito para a sua instituição é aquele que se destaca nas suas próprias candidaturas face aos nove critérios indicados abaixo. Cada critério fornece a pergunta a fazer, o aspeto de uma resposta fraca e como pode verificar a resposta por si próprio.
1. Quem pode alterar a política de crédito e quem aprova a alteração?
Pergunte quem na sua equipa pode alterar um limite, adicionar uma regra ou mudar de estratégia, e de que forma essa alteração é aprovada e registada. O diretor de análise de risco de crédito de uma cooperativa de crédito mencionado anteriormente referiu que as pessoas que definem a política de crédito estão afastadas da operação diária do motor de decisão: as alterações são redigidas, aprovadas e entregues a outra equipa para implementação.
Uma resposta fraca envolve encaminhar as alterações através da equipa de serviços do fornecedor ou dos seus próprios engenheiros. Tenha atenção à rapidez aparente que esconde esta mesma dependência. Um responsável de dados e engenharia num credor automóvel descreveu uma alteração urgente de regra que passou do diretor executivo para um gestor de produto e depois para um engenheiro, que "alterou o JSON, sem sequer ser necessário reimplementar o serviço." A alteração foi rápida, mas continuou a precisar de um engenheiro.
Verifique: peça ao fornecedor para que o seu analista de crédito faça uma alteração de política num ambiente de testes, com aprovação e registo de alterações, sob a sua observação.
2. Como é testada uma alteração antes de entrar em funcionamento?
Muitas vezes, os testes são o verdadeiro obstáculo. Um gestor de risco e análise num credor de crédito pessoal parcelado afirmou que "a principal preocupação é testar no nosso sistema atual", acrescentando que "mesmo o teste retroativo (back testing) é bastante complexo." Pergunte como é que uma alteração é testada face a candidaturas anteriores, quantas estratégias podem ser executadas em simultâneo e se consegue ver o efeito de uma única regra antes do lançamento.
Uma resposta fraca baseia-se em casos de teste criados manualmente ou num simples teste A/B. Casos criados manualmente falham em identificar interações entre regras, e uma única versão alternativa pode não ser suficiente: o mesmo gestor pretendia várias estratégias a correr em simultâneo para determinados segmentos. Um diretor executivo num credor online a particulares descreveu o teste de hipótese de regra única, "se eu remover esta regra ou se adicionar esta regra", como "algo que faço manualmente neste momento".
Verifique: forneça a cada fornecedor uma alteração de política efetuada por si no ano passado e peça para ver o respetivo impacto nas suas candidaturas passadas antes do lançamento.
3. Como entram os dados e com que facilidade pode adicionar ou mudar de fornecedor?
Um responsável pela estratégia de risco de crédito num grande banco regional colocou este ponto em primeiro lugar: "a flexibilidade do fornecedor de dados é o aspeto mais importante na minha opinião." Pergunte como é adicionada uma nova fonte de dados, quem cria a ligação e se as fontes podem ser consultadas condicionalmente, para pagar apenas pelos dados que uma decisão necessita.
Uma resposta fraca transforma cada novo atributo num projeto no plano de desenvolvimento do fornecedor.
Verifique: indique a próxima fonte de dados que planeia adicionar e peça os passos necessários, quem será o responsável e um exemplo de como foi feito para outro credor. Para perceber o que o software deve suportar quando estiver a funcionar em pleno volume, consulte o que uma plataforma de decisão de crédito deve suportar em produção.
4. Como entram os seus próprios modelos e o que mostra o software quando estes estão em execução?
Pergunte como é integrado um modelo criado no seu próprio ambiente, como é que uma nova versão substitui a antiga e o que o software reporta sobre o modelo quando este está ativo. Pergunte também onde é feita a monitorização do modelo: no próprio software ou nas suas ferramentas internas.
Uma resposta fraca trata o modelo como uma caixa negra dentro do motor, ou disponibiliza apenas os modelos do próprio fornecedor.
Verifique: traga um dos seus modelos e peça para vê-lo a pontuar as suas candidaturas, com a respetiva versão registada em cada decisão.
5. Cada recusa apresenta motivos específicos que correspondem ao que foi avaliado?
O Regulamento B exige motivos principais específicos para uma recusa, e esses motivos devem corresponder aos fatores realmente considerados ou avaliados. O responsável pelo crédito a particulares de um banco regional, citado anteriormente, fez uma das primeiras perguntas práticas nessa avaliação: "E no caso da carta de ação adversa enviada ao cliente, qual é a informação enviada se houver uma recusa?" Pergunte como são gerados os motivos, se provêm do modelo e da política que tomou a decisão e se pode analisar os principais motivos e a sua estabilidade ao longo do tempo.
Uma resposta fraca apresenta códigos de motivo genéricos ou motivos associados manualmente após a decisão. O CFPB retirou as suas Circulares 2022-03 e 2023-03 sobre ações adversas a 12 de maio de 2025, mas os requisitos do regulamento mantêm-se.
Verifique: extraia uma amostra de candidaturas recusadas de um teste e analise cada motivo face ao que foi pontuado.
6. O que mostra o registo de auditoria?
Peça o registo completo de uma única decisão: dados de entrada, versão da política, versão do modelo, motivos e quem alterou o quê e quando. Uma resposta fraca remete-o para um programador. Um gestor de produto de subscrição de crédito num credor automóvel fintech descreveu como responderia a esse pedido hoje: "aqui está, fale com o programador da minha equipa. Ele pode mostrar-lhe o código".
Verifique: peça ao fornecedor para reconstruir uma das suas decisões de teste apenas com base no registo e verifique se cada alteração de política apresenta uma descrição legível.
7. Como são tratadas as candidaturas encaminhadas, as sobreposições (overrides) e as exceções?
Codificar políticas não elimina o julgamento humano. Um subscritor sénior de crédito comercial num banco comunitário perguntou: "Existe forma de fazer sobreposições aqui dentro? Ou temos de nos limitar estritamente à política de crédito que introduzimos?" As pessoas que analisam as candidaturas encaminhadas também são utilizadores. O diretor executivo do credor online a particulares perguntou: "O que é que os meus especialistas de crédito vão estar a analisar?"
Uma resposta fraca trata o ecrã de revisão como uma questão secundária, com sobreposições efetuadas fora do software e sem justificação registada.
Verifique: peça a um dos seus especialistas em crédito para analisar candidaturas encaminhadas em ambiente de teste e forçar uma sobreposição, localizando depois esse registo de sobreposição no sistema.
8. O controlo de fraude e o crédito correm no mesmo fluxo?
Quando as decisões de fraude e crédito estão em sistemas separados, uma alteração de um lado afeta os resultados do outro sem que ninguém se aperceba. O responsável pela estratégia de risco de crédito no grande banco regional afirmou: "quando fazemos uma alteração nas ferramentas de fraude, não fazemos ideia de como isso afeta... as taxas de aprovação e tudo o que flui pelo processo."
Pergunte se as verificações de fraude e a política de crédito correm no mesmo fluxo de decisão com um registo unificado. Uma resposta fraca significa sistemas separados, registos separados e a ausência de uma visão partilhada sobre as taxas de aprovação.
Verifique: peça para ver uma alteração de regra de fraude e o respetivo efeito nas aprovações de crédito numa única vista.
9. Quem é o proprietário da plataforma após a entrada em funcionamento e o que está incluído no produto base?
Pergunte quem faz a manutenção das políticas e integrações após a entrada em funcionamento. Um diretor de crédito num banco comunitário colocou a questão de forma direta: "parece-me que vocês fazem o desenvolvimento inicial e que a manutenção contínua seria feita internamente pela nossa equipa. É este o modelo?" O diretor executivo do credor online a particulares descreveu um excelente apoio durante a fase de desenvolvimento, mas uma equipa mais fraca após a entrada em funcionamento, solicitando não ser entregue a uma equipa nova após o lançamento.
Pergunte o que está incluído no produto base. Um avaliador comercial num fornecedor de soluções "compre agora, pague depois" (BNPL) ficou sem saber "que partes daquele processo são o chamado produto base e o que é considerado um módulo extra." Uma proposta demasiado genérica também constitui uma resposta fraca: o responsável de aquisições do emissor de cartões de crédito citado anteriormente referiu: "tudo parece interessante, mas é difícil saber... sem entrarmos em casos de utilização mais específicos".
Verifique: peça a identificação da equipa específica que o irá apoiar após a entrada em funcionamento e uma correspondência detalhada entre a demonstração e a proposta de contrato.
Para realizar estas verificações como um teste estruturado numa lista de candidatos, leia como testar plataformas de decisão de risco de crédito nas suas próprias candidaturas. Para transformar estas perguntas num pedido de proposta formal, consulte como escrever um RFP para motor de decisão de crédito.
Como a Oscilar se posiciona face a estes critérios
A Oscilar publica este guia e vende software de tomada de decisão de crédito, pelo que deve ler esta secção como uma autoavaliação face aos mesmos nove critérios. Onde a resposta depender de detalhes que variam conforme o credor, a resposta mais honesta é: peça-nos para lhe demonstrarmos com as suas próprias candidaturas.
A Oscilar é a camada de decisão, não um sistema de originação de empréstimos. Situa-se entre o seu sistema de originação e os seus fornecedores de dados.
Alterações de política (critério 1). As equipas de crédito criam processos em ferramentas sem código (no-code) e de baixo código (low-code), e podem descrever o processo e a lógica de regras em linguagem natural. Peça-nos para mostrar o seu analista a efetuar uma alteração de política, com a respetiva aprovação e registo.
Testes (critério 2). Os credores executam testes retroativos (backtests) em dados históricos para validar uma nova política de crédito antes de a implementar, além de realizarem testes A/B. Se precisa de várias estratégias em simultâneo para um mesmo segmento, peça-nos para lhe mostrar como isso correria nas suas candidaturas.
Dados (critério 3). Os credores ligam os seus próprios dados. Peça-nos para detalhar o processo de adicionar a próxima fonte da sua lista e definir quem a desenvolve.
Modelos (critério 4). Os credores trazem os seus próprios modelos, criados no seu ambiente de eleição, e executam-nos lado a lado com as regras. A Oscilar monitoriza desvios de dados, de funcionalidades e de conceitos, bem como KPIs de resultados por segmento.
Motivos de recusa (critério 5). Peça-nos para lhe mostrar os motivos diretamente nas suas próprias candidaturas recusadas.
Registo de auditoria (critério 6). A Oscilar foi concebida com um registo de auditoria completo por decisão com armazenamento de justificações e intervenção humana integrada (human-in-the-loop). Foi desenhada para se adequar às orientações de gestão de risco de modelos interinstitucionais.
Candidaturas encaminhadas (critério 7). Peça-nos para lhe mostrar o ecrã de revisão com os seus próprios especialistas em crédito a analisar casos encaminhados.
Fraude e crédito (critério 8). Peça-nos para lhe mostrar uma alteração de fraude e o seu impacto nas aprovações de crédito numa vista unificada.
Após a entrada em funcionamento e produto base (critério 9). Pergunte-nos, por escrito, quem apoiará a sua equipa após o lançamento e o que está integrado no produto base.
A plataforma foi concebida para tomar decisões em menos de 100 milissegundos.
Uma grelha de avaliação para software de decisão de crédito
A grelha de avaliação abaixo converte os nove critérios naquilo que deve pedir a cada fornecedor para lhe mostrar, identificando os sinais de alerta a que deve estar atento. Atribua uma pontuação de 1 a 5 a cada linha.
# | Critério | Peça para ver | Sinal de alerta | Pontuação |
|---|---|---|---|---|
1 | Controlo de políticas | O seu analista a fazer uma alteração, com aprovação e registo de alterações | As alterações têm de passar pelo fornecedor ou pelos seus engenheiros | |
2 | Testes antes do lançamento | Uma alteração de política anterior testada com as suas candidaturas passadas | Apenas casos de teste criados à mão ou testes A/B simples | |
3 | Entrada de dados | Os passos e o responsável por adicionar a sua próxima fonte de dados | Cada novo atributo é tratado como um projeto no plano do fornecedor | |
4 | Os seus modelos | Um dos seus modelos a pontuar as suas candidaturas, com registo da versão | O modelo é uma caixa negra, ou apenas correm os modelos do fornecedor | |
5 | Motivos de recusa | Motivos em candidaturas suas recusadas, comparados com o que foi avaliado | Códigos genéricos ou motivos associados manualmente à posteriori | |
6 | Registo de auditoria | Uma decisão de teste reconstruída unicamente a partir do registo | É necessário um programador para conseguir ler o registo | |
7 | Candidaturas encaminhadas | Os seus analistas a gerir casos encaminhados e a registar uma sobreposição | As sobreposições de decisão ocorrem fora do software | |
8 | Fraude e crédito | Uma alteração de fraude e o respetivo efeito nas aprovações numa única vista | Sistemas separados e registos desintegrados | |
9 | Após entrada em funcionamento | A equipa de suporte dedicada identificada e a correspondência demo-contrato | Uma boa equipa no desenvolvimento inicial, seguida de descompromisso |
Avalie cada fornecedor com base nas mesmas candidaturas, no mesmo ambiente de teste, para que as pontuações permitam uma comparação justa.
Perguntas frequentes
Como escolho o melhor software de tomada de decisão de crédito este ano?
Escolha com base no desempenho do software com as suas próprias candidaturas e dê pouca importância a listas genéricas de funcionalidades. Avalie cada fornecedor com base em nove pontos: controlo de políticas, testes, dados, modelos, motivos de recusa, registo de auditoria, análise de casos encaminhados, fraude e crédito num único fluxo e suporte após a entrada em funcionamento. Realize as mesmas verificações com cada fornecedor utilizando as mesmas candidaturas.
O que é um software automatizado de decisão de crédito?
O software automatizado de tomada de decisão de crédito decide a maioria das candidaturas sem necessidade de trabalho manual. Recolhe os dados, aplica os modelos e a política do credor e devolve uma decisão fundamentada em tempo real. As candidaturas que a política não consegue resolver são encaminhadas para análise humana, mantendo-se a política e as exceções sob controlo da equipa de crédito.
Como é que o software melhora a tomada de decisão de crédito?
O software melhora a decisão de crédito ao aplicar a mesma política a todas as candidaturas, associando justificações a cada decisão e registando a forma como foram tomadas. Permite à equipa de crédito alterar e testar políticas sem depender de prazos e filas da equipa de engenharia. Além disso, mantém as candidaturas encaminhadas e sobreposições centralizadas, garantindo a visibilidade e auditabilidade das decisões de exceção.
Como deve um banco digital ou credor fintech avaliar um software de decisão de crédito?
Um banco digital ou credor fintech deve avaliar o software com base na rapidez com que a sua equipa de crédito consegue alterar e testar políticas, na facilidade de ligação de novas fontes de dados e na manutenção da velocidade de decisão perante grandes volumes de candidaturas. Solicite um teste com as suas próprias candidaturas e analise os motivos de recusa e o registo de auditoria com o mesmo rigor de um regulador bancário. Os credores em rápido crescimento precisam também de assegurar quem apoiará as alterações de política após a entrada em funcionamento.
A Oscilar é um fornecedor de software de tomada de decisão de crédito?
Sim. A Oscilar fornece software de tomada de decisão de crédito para credores particulares e comerciais: a camada de decisão que se posiciona entre o sistema de originação de empréstimos e os fornecedores de dados, onde as equipas de crédito criam, testam e alteram políticas. A Oscilar publica este guia, e a secção acima faz uma autoavaliação face aos mesmos critérios recomendados para analisar qualquer fornecedor.
O que deve reter para a sua próxima avaliação
O software de tomada de decisão de crédito prova o seu valor quando permite à equipa de crédito alterar políticas, testar essas alterações e explicar cada decisão com base num registo que responde às exigências de um auditor. Leve estes nove critérios e a grelha de avaliação para a sua próxima análise e peça a cada fornecedor para provar o desempenho do sistema com as suas candidaturas. Para conhecer a abordagem da Oscilar, consulte a solução de subscrição de crédito da Oscilar.

Equipe Oscilar
A equipe da Oscilar é formada por especialistas em diversas áreas de gestão de risco. Estes artigos refletem pontos de vista e conhecimentos de várias fontes e colaboradores de toda a organização.








