ANÁLISE DE CRÉDITO INTELIGÊNCIA ARTIFICIAL
Artigo_Veja_como_e_facil_desenhar_politica-de-credito

Veja como é fácil desenhar sua política de crédito com Decision Designer

por Bruno Silva Senior Software Engineer na Neurotech

Quando uma instituição financeira trabalha com concessão de crédito, é natural que ao fornecê-lo algumas regras sejam seguidas, seja para determinar os riscos ou a capacidade de pagamento do cliente, por exemplo. A estas regras, é dado o nome de  política de crédito. Essa política tem como objetivo orientar as decisões de concessão de crédito de forma consistente e prudente, buscando minimizar riscos e maximizar a rentabilidade da operação. Além disso, ela envolve a análise de informações sobre a situação financeira, histórico de crédito, capacidade de pagamento e outras características relevantes do cliente.

A Neurotech, por meio da plataforma Riskpack, possui soluções completas para todo o ciclo de vida do crédito, desde a prospecção até a recuperação de clientes devedores com maior propensão a pagar suas dívidas, descoberta de potenciais fraudes, e assim por diante. Cada componente do Riskpack cumpre um papel importante neste ciclo, e neste estudo de caso focaremos no Decision Designer.

O Decision Designer é uma ferramenta low-code de desenho de fluxos de trabalho baseada em BPM (business process model). A ideia por trás deste tipo de ferramenta é que usuários de negócio, que normalmente não possuem um entendimento profundo dos conceitos de programação, possam expressar suas ideias e regras de negócio através de pouquíssimo código, fazendo uso de noções básicas de modelos de negócio, tais como:

  • Tarefas e subtarefas (“execute a subtarefa FLX_SCORE”)
  • Decisões baseadas em valores (“se o resultado da tarefa FLX_RECEITA_PJ for igual a APROVADO, siga por este caminho, senão, continue por aquele outro caminho”)
  • Resultados (“ao chegar no final deste caminho, informe que esta tarefa terá como resultado o valor REPROVADO”)

Para o contexto do Decision Designer, as tarefas podem ser dos seguintes tipos:

  • Fluxo: são aquelas tarefas que contém desenhos intuitivos que indicam o “caminho” pelo qual a decisão vai seguir;
  • Tabela: são tabelas de decisão, no padrão de “se isto e aquilo, então o resultado será este”. Representam uma outra forma de tomar decisão, mais textual e um pouco mais avançada, mas quem também não envolve programação;
  • Variável: são valores básicos que podem ser comparados e atribuídos durante a tomada de decisão; estes valores podem ser do tipo número inteiro ou real, texto, lista ou booleano (utilizado para valores sim e não)
  • Recurso externo: são integrações com outros módulos do Riskpack, como uma consulta a algum bureau externo, por meio do Gateway (componente que faz a ponte entre nosso motor de decisão e as fontes de dados externas), ou uma consulta a uma base de dados através do Upload (componente que contém os registros de dados disponíveis dos clientes que serão consumidos pelo nosso motor), entre outras possibilidades

Uma importante consequência da definição da tarefa é a possibilidade de divisão em subtarefas. Desta forma, podemos estruturar as ideias lógicas de maneira hierárquica, onde um usuário com maior expertise de negócio pode desenhar os fluxos em mais alto nível, indicando, por exemplo, os passos em linhas gerais e os caminhos pelos quais a decisão deve percorrer, enquanto um usuário mais técnico pode, por exemplo, detalhar melhor e dividir os fluxos em regras, e aplicar tabelas, variáveis e até mesmo consultar recursos externos para enriquecer a tomada de decisão.

Além disso, criar regras de maneira hierárquica também permite sua adição à base de reuso, sendo possível utilizá-las sempre que necessário em novas políticas. Isto torna o processo bem mais produtivo e documentado, uma vez que as regras que foram adicionadas à base do reuso já foram extensivamente testadas e aplicadas anteriormente.

Exemplo de utilização

Para exemplificar melhor como podemos otimizar a divisão de papéis durante a construção de uma política, imagine o seguinte cenário: 

O dono de uma loja de conveniência de um posto de gasolina (vamos chamá-lo de André) decide fazer um cartão fidelidade para cativar os viajantes que por ali passam. A sua ideia inicial é, baseado nos dados fornecidos pelos clientes, ou aplicar algum tipo de desconto progressivo para clientes rotineiros ou fornecer o cartão fidelidade para novos clientes. Como  André ama muito sua cidade, e sempre que pode, faz propaganda do turismo local, para novos  clientes de outros estados ele também gostaria de entregar-lhes um pequeno souvenir (chaveiro ou porta-moedas). Além do mais, clientes que fazem aniversário naquele dia recebem um cartão de parabéns personalizado e uma taça de champanhe para fazer um brinde.

Este simples cenário é riquíssimo para exemplificar vários elementos do Decision Designer, associados aos conceitos de programação. Por exemplo, podemos começar a pensar em alto nível os tipos de clientes que pensamos em atender, quais são as variáveis de entrada que iremos precisar, etc. Em um cenário do mundo real, precisaríamos de muitas informações para conferir realmente se o cliente possui aqueles dados que foram fornecidos, qual sua renda, se existe alguma tentativa de fraude, entre outras coisas. Vamos então considerar apenas o que está definido no exemplo para modelar a política de acordo:

  • Nome: Para personalizar o cartão de aniversário
  • Data de nascimento: Para saber se hoje é seu aniversário e também verificar se você é maior de idade para receber a taça de champanhe
  • CEP: Para verificar se o cliente é deste ou de outro estado
  • Quantidade de compras no estabelecimento: Para saber se é cliente novo ou não, e também para calcular o desconto progressivo

Por definição de padrão, todas as variáveis de entrada no Decision Designer (ou DD) começam por PROP_, derivado de propostas Então, para as variáveis acima, podemos criar as seguintes propriedades:

Uma vez que foram definidas as variáveis que serão utilizadas na política, o próximo passo é traduzir os cenários descritos em regras do tipo SE -> SENÃO -> ENTÃO. O Decision Designer é próprio para isto, e sua interface intuitiva ajuda bastante nesta tarefa. Considerando inclusive que André não possui um conhecimento aprofundado sobre programação, ele pode desenhar a regra principal sem grandes dificuldades, da seguinte forma:

Que interessante! André conseguiu, no formato de fluxo de decisão, descrever exatamente o que ele espera como saída da sua política. A forma como a regra foi dividida em sub-regras, é uma variação de um conceito de programação chamado de divisão e conquista, onde você divide um problema em partes menores para facilitar seu entendimento para conseguir resolver de maneira direta um problema muito simples, fazendo a junção dos resultados para compor o resultado final.

Como é possível ser observado, a regra principal foi dividida em quatro sub-regras:

  • RGR_CLIENTE_NOVO: que indica se um cliente é novo (NOVO) ou já cliente (RECORRENTE)
  • RGR_ESTADO: define se um cliente é deste estado (MESMO) ou de outro estado (OUTRO)
  • RGR_ANIVERSARIO: verifica se hoje é aniversário do cliente (SIM ou NÃO)
  • RGR_IDADE: decide se o cliente pode ou não receber o brinde alcoólico através de sua idade.

Por ter conseguido desenhar a regra principal de maneira tão fácil, André também se aventurou a definir as sub-regras. Começando pela regra de definição se é um cliente recorrente ou novo (RGR_CLIENTE_NOVO), ele notou que bastava comparar o número de compras daquele cliente (que já recebe como entrada), para decidir se o cliente é novo ou recorrente.

Para definir a RGR_IDADE, apesar de não saber programar, ele notou que no Decision Designer existe uma seção com funções pré-definidas, e uma delas é justamente calcular idade. Que legal! Para utilizar a função calcularIdade, ele arrastou diretamente no desenho e percebeu que a função pedia qual a variável de entrada e qual a variável de retorno. Como ainda não tinha criado a variável de retorno, ele criou uma nova variável do tipo CALC para isto. As variáveis CALC possuem este nome porque, por definição de padrão, são calculadas em tempo de execução, em comparação às variáveis PROP que vêm como entradas da proposta, como já vimos anteriormente.


Neste caso, ele criou a variável CALC_IDADE para, a partir da função calcularIdade, e recebendo a PROP_DATA_NASCIMENTO como entrada, saber quantos anos o cliente tem, conforme a imagem a seguir:

André agora se deparou com dois cenários que não soube resolver sem a ajuda de códigos de programação:

  1. Como saber o estado de um cliente, apenas com o CEP em mãos?
  2. Como saber a data de hoje, para comparar com a data de nascimento e saber se é aniversário do cliente ou não?

André esperava, com a resposta destas perguntas, concluir as regras RGR_ESTADO e RGR_ANIVERSARIO, respectivamente. A boa notícia é que, para a primeira delas, ele vai conseguir resolver no DD sem utilizar quase nenhuma programação! Para isto, ele vai utilizar um recurso muito interessante do DD que é a integração com sistemas externos, para enriquecer sua tomada de decisão.

Ao navegar pelo DD com suas credenciais do Gateway, ele notou que a consulta Correios tem as seguintes entradas e saídas:

É exatamente o que ele queria! Com um CEP como entrada, obter qual o estado (ou UF) daquele CEP. Da mesma forma que ele conseguiu arrastar elementos para a regra principal, ele poderá arrastar a consulta Gateway para a sua área de desenho. Antes disso, será necessário indicar que a variável que ele escolheu como entrada para o CEP (PROP_CEP) seja vinculada à entrada cep da consulta CORREIOS:

André notou que a saída do Gateway para saber o estado de um CEP é a saída UF, mas que ela é do tipo texto. Variáveis do tipo texto não podem ser arrastadas diretamente para a área de desenho. Ele então, teve uma ideia: que tal criar uma variável calculada com a lista dos estados, e aí sim, poder arrastá-la para tomar a decisão? Isto é totalmente possível, mas fazemos aqui uma reflexão com o André: apesar da lista de estados ser relativamente pequena, e se fosse uma lista de países por exemplo? Ou dos municípios brasileiros? Como iríamos preencher centenas ou até milhares de valores na lista?

A resposta é simples: como nossa decisão para a RGR_ESTADO é baseada no fato de ser deste ou outro estado, a lista não precisa ser exaustiva! Neste caso, podemos fazer uso do atributo Default, que indica qual o valor padrão daquela lista. Este valor é útil porque ao tentar atribuir qualquer outro valor não presente na lista, ele será aplicado. Desta forma, a lista CALC_ESTADO ficou da seguinte forma:

Com a lista criada, André vinculou a saída uf da consulta CORREIOS ao CALC_ESTADO:

Uma vez que foram vinculadas entradas e saídas para uma consulta do Gateway, agora sim é possível incluí-la no desenho e tomar decisões baseadas tanto no resultado em si, quanto nas variáveis que foram vinculadas. Deste modo, a regra RGR_ESTADO, fica assim:

Ou seja, a consulta CORREIOS do Gateway é acionada, recebendo como entrada o cep, que foi copiado de PROP_CEP, e dentre as suas saídas, copia o resultado da saída uf para a variável CALC_ESTADO, e caso o resultado do Gateway indique qualquer outro estado, a lista irá receber o valor OUTROS através do atributo Default, resultando na saída OUTRO da RGR_ESTADO.

Agora André está em um impasse: chegou na última das regras, a RGR_ANIVERSARIO. Já familiarizado com os conceitos que vimos até então no DD, ele não se recorda de nenhum recurso que consiga ajudá-lo diretamente. Mas como ele é sempre muito antenado, está sabendo que só se fala em LLMs e ajudantes de chat em IA, que podem auxiliá-lo nesta tarefa. A ideia é explicar o máximo possível o que ele deseja fazer e pedir ao assistente para gerar o código apropriado.

Exemplo de prompt de comando utilizando IA generativa

Apesar de ser uma excelente oportunidade para aplicar estes conceitos, André precisa, como ele mesmo já desconfia, criar uma variável calculada CALC_ANIVERSARIO, para decidir na sua área de código (ícone ?) se é ou não seu aniversário. Como a lista por padrão já é criada com os valores SIM e NÃO, não será necessário nem alterar a lista de valores.

E agora, com ajuda do assistente de IA, André pode inicialmente ficar um pouco confuso, e dizer: “quero saber se hoje é aniversário”, e vai notar que a resposta pode ser um pouco abrangente demais. A ideia é que ele seja o mais específico possível na hora de solicitar. Vamos ajudá-lo! Veja o exemplo abaixo:

Preciso de um código em Java que, dada a variável de texto aniversario (que é uma data no formato dia/mês/ano), altere o valor de um objeto para SIM ou para NÃO. Aplique as seguintes restrições:

  • Não utilize nenhum import no código, apenas o nome completo das classes
  • Não apresente o bloco de código completo, apenas o trecho correspondente
  • A primeira linha deste bloco deve ser a inicialização da variável aniversario no seguinte formato: String aniversario = (String) Global.PROP_DATA_NASCIMENTO.run();
  • A última linha deste bloco deverá ser a atribuição de valores baseado no resultado: se verdadeiro: setValue(“SIM”), caso contrário, setValue(“NÃO”)

Existem várias formas de chegar ao mesmo resultado e o código gerado poderá ser levemente diferente, mas a ideia geral está bem descrita e há grande chance de sucesso. Sobre as restrições, as duas primeiras são especificidades do DD, e não têm relação direta com o problema (resumindo, é muito provável que elas apareçam em todas as consultas que sejam feitas a assistentes de IA deste tipo para o DD), e as duas últimas são para vincular as entradas e saídas que desejamos (variável PROP_DATA_NASCIMENTO e alterar o valor do próprio CALC_ANIVERSARIO, respectivamente).

É importante ter em mente que é preciso ter um certo cuidado ao fazer estes tipos de prompts para a IA. Imagine se ao invés de solicitar apenas a função de aniversário, por exemplo, ele descrevesse todo o funcionamento de sua política e o seu concorrente também começasse a fazer perguntas semelhantes para a IA e se aproveitasse disso? André acabaria, sem saber, ajudando a inteligência artificial a melhorar suas respostas sobre pontos muito peculiares do seu negócio e poderia, potencialmente, expor alguma estratégia.

André pode também ficar seguro ao colar este código gerado pelo assistente, pois o DD efetua validações importantes de segurança, verificando se existe algum código malicioso presente.

Concluindo esta etapa, André colou seu código e ficou muito contente, pois agora, finalmente sua política está quase construída. Para concluir a política, ele arrastou a CALC_ANIVERSARIO para a RGR_ANIVERSARIO e terminou o seu desenho:

Com isto, André finaliza o desenho de sua política. De sua rápida jornada, podemos extrair algumas coisas interessantes:

  • O processo de tomada de decisão pode aproveitar-se de estratégias de divisão de problemas em problemas menores
  • O Decision Designer é ótimo com abstrações, favorecendo bastante usuários leigos em programação, mas também fornece possibilidades de escrita de códigos para usuários mais avançados
  • Ferramentas de IA assistivas são muito poderosas, mas podem receber informações demais sobre nosso negócio caso não tenhamos cuidado. Neste exemplo André, ele acertou bastante ao pedir apenas uma parte específica do seu problema para ser resolvido (cálculo de aniversário). 

Este estudo, apesar de seu caráter fictício, cobriu a maior parte dos elementos que podem ser utilizados para a criação de uma política. André, com pouco conhecimento em programação e com o devido treinamento em nossa ferramenta conseguiu criar a política da sua loja de conveniência. Você também irá conseguir criar políticas de crédito muito mais complexas com o uso do Decision Designer. Não perca a oportunidade de conhecer o nosso Motor de Decisão Riskpack e entender como ele pode alavancar a estratégia do seu negócio.

Conte com a Neurotech

Você possui desafios na gestão da sua carteira de crédito ou ficou interessado sobre como o Big Data pode fazer a diferença na gestão de riscos da sua empresa? Fale conosco e conte com a expertise de mais de 20 anos no mercado de tecnologia!  

A Neurotech é referência em transformar um mundo de dados dispersos em informações confiáveis e relevantes para que nossos clientes prevejam novas oportunidades de negócios e obtenham resultados expressivos. 

Acesse nosso site e veja como podemos lhe apoiar em seus desafios de negócio.

https://www.neurotech.com.br/desafios/