Políticas de Crédito

Pré-requisitos de acesso

• Permissão (módulo): creditConfigManage (para criar/editar). A leitura da tela é liberada por viewCredits.
• Licença/Feature: CREDIT_INVESTMENTS habilitada na licença do tenant (Vault).
• Contêiner do menu: TOKENIZAÇÃO → grupo Crédito Tokenizado

O que é / quando usar

A tela de Políticas de Crédito cadastra regras de elegibilidade e avaliação automática de risco que o motor de crédito aplica automaticamente sobre Deals (operações), Recebíveis e Parties (participantes). Cada política é um conjunto de regras (campo + operador + valor) associadas a uma ação — aprovar automaticamente, mandar para revisão manual ou rejeitar.

Use esta tela antes de operar crédito: as políticas são a "trava de risco" que decide se uma operação passa direto, precisa de análise humana ou é barrada na origem, sem depender do operador lembrar de cada critério.

Pré-condições

• Permissão: creditConfigManage cadastrado para a role do operador (lembrar: a permissão é dupla — enum estático CPM no backend + módulo dinâmico no DB que controla os *ngIf da tela; ambos precisam estar ativos para os botões aparecerem).
• Licença/Feature: CREDIT_INVESTMENTS habilitada. Se desabilitada, o grupo Crédito Tokenizado nem aparece no menu.
• Dependências de outras telas: nenhuma. Porém, faz sentido cadastrar políticas antes de criar Deals/Recebíveis, pois a avaliação roda no momento da aprovação dessas entidades.

Passo a passo

1. Acesse o menu Crédito Tokenizado → Políticas.
2. Use os filtros Escopo (Deals / Recebíveis / Parties) e Ativo (Sim/Não) para localizar políticas existentes.
3. Clique em Criar para abrir o formulário.
4. Preencha Nome, Escopo, Prioridade, Versão e a Ação (o que ocorre se uma regra falhar).
5. No bloco Regras, clique em Adicionar regra e monte cada condição: Campo (a lista muda conforme o escopo), Operador, Valor e uma Mensagem de erro opcional.
6. Clique em Salvar (ou Atualizar em edição).

Campos

Campo	O que é	Obrigatório?	Efeito no sistema/backend
Nome	Identificação da política	Sim	Gravado em name; aparece na listagem e no resultado da avaliação (policyName).
Escopo	Em qual entidade a política se aplica: DEAL, RECEIVABLE ou PARTY	Sim	Define scope. O motor só avalia políticas cujo escopo bate com a entidade sendo aprovada (PolicyEvaluationService.evaluate(scope, ...)). Trocar o escopo muda a lista de Campos disponíveis.
Prioridade	Ordem de avaliação (menor = mais cedo)	Não (default 0)	Gravado em priority; as políticas são buscadas ordenadas por prioridade. Não interrompe a avaliação — todas as políticas do escopo são avaliadas, mas a ordem afeta a leitura do resultado.
Versão	Número de versão da política	Não (default 1)	Gravado em version; serve para rastrear revisões da regra ao longo do tempo.
Ativo	Liga/desliga a política	Sim (default Sim)	Gravado em active. Apenas políticas ativas são avaliadas (findByScope(scope, true)). Desligar é a forma de "aposentar" sem apagar histórico.
Descrição	Texto livre explicando a política	Não	Gravado em description; documentação interna, sem efeito de avaliação.
Ação	O que acontece se alguma regra da política falhar: Aprovar Automaticamente, Revisão Manual ou Rejeitar	Sim	Gravado dentro do rulesJson como action. Na avaliação, a ação é escalada entre todas as políticas reprovadas: REJECT > MANUAL_REVIEW > AUTO_APPROVE. Basta uma política exigir REJECT para o resultado final ser rejeição.
Regra → Campo	Atributo da entidade a comparar (ex.: grossAmount, riskScore, originator.riskScore)	Sim (por regra)	Lido por dot-notation do objeto avaliado (originator.riskScore lê de { originator: { riskScore } }). A lista de campos é específica por escopo.
Regra → Operador	= ≠ > ≥ < ≤ IN NOT IN BETWEEN EXISTS NOT EXISTS	Sim (por regra)	Define a comparação. IN/NOT IN/BETWEEN esperam lista de valores (separados por vírgula); BETWEEN usa exatamente dois (mín, máx). EXISTS/NOT EXISTS checam presença do campo.
Regra → Valor	Valor de comparação	Condicional	Convertido automaticamente: true/false viram booleano; números viram número; para IN/NOT IN/BETWEEN é dividido por vírgula em lista.
Regra → Mensagem	Mensagem de erro exibida quando a regra falha	Não	Gravada em rule.message; aparece no resultado da avaliação como motivo da reprovação (failedRules[].message).

Ações e modais

• Criar / Atualizar: grava a política via createPolicy / updatePolicy. O botão Salvar/Atualizar só é renderizado para quem tem creditConfigManage.
• Adicionar regra / Remover regra: manipulam a lista de regras no formulário e regeneram o rulesJson automaticamente (você não edita o JSON na mão).
• Editar (ícone lápis na tabela): carrega a política e remonta as regras a partir do rulesJson salvo.

Como é uma operação sensível de configuração de risco, salvar pode disparar step-up (re-autenticação senha + MFA, header X-Step-Up-Token, janela de 5 min) dependendo da configuração do ambiente. Isso não é aprovação 4-eyes — é só re-confirmar a identidade do operador.

Regras de negócio / cuidados

Atenção

• Sem política = aprovação automática. Se um escopo não tem nenhuma política ativa, a entidade é auto-aprovada por padrão. Não existe "negar tudo" implícito — a trava só existe se você cadastrá-la.
• Falha de avaliação cai em Revisão Manual. Se o motor der erro ao avaliar (ex.: rulesJson corrompido), o resultado é forçado para MANUAL_REVIEW por segurança — nunca aprova no escuro.
• Campos nulos reprovam. Se o campo da regra não existir no objeto avaliado, a maioria dos operadores falha (exceto NOT EXISTS). Cuidado ao referenciar campos que nem sempre vêm preenchidos.
• Troca de escopo reseta os campos válidos. As regras montadas num escopo podem referenciar campos que não existem em outro; revise as regras se mudar o escopo de uma política existente.
• A escalada de ação é por reprovação. Uma única política com ação REJECT reprovada já leva o resultado global a rejeição, mesmo que dezenas de outras tenham passado.

• Valores financeiros: os campos numéricos comparados (valores brutos/líquidos, limites de crédito) representam montantes que no domínio de crédito são tratados como BigNumber — ao definir limiares (ex.: grossAmount > 100000), confira a unidade/casas decimais esperadas pelo motor.

Exemplos

Cenário 1 — Auto-aprovar deals pequenos de originador confiável

Objetivo: liberar sem fricção operações de baixo valor de bons originadores.

1. Escopo: Deals. Ação: Aprovar Automaticamente.
2. Regras:
   • grossAmount ≤ 50000
   • originator.riskScore ≥ 70
   • originator.defaultCount = 0
3. Salvar.

Resultado: ao aprovar um deal de R$ 30.000 cujo originador tem score 80 e zero inadimplências, as três regras passam e o deal é auto-aprovado. Se o valor fosse R$ 80.000, a regra ≤ 50000 falha e, como a ação é AUTO_APPROVE, essa política simplesmente não bloqueia — o resultado dependerá das demais políticas do escopo.

Cenário 2 — Forçar revisão manual de recebíveis sem NFe validada

Objetivo: nunca aprovar automaticamente recebível sem documento fiscal validado.

1. Escopo: Recebíveis. Ação: Revisão Manual.
2. Regras:
   • hasInvoiceValidation = true — Mensagem: "NFe não validada".
   • hasDebtorConsent = true — Mensagem: "Sacado não confirmou".
3. Salvar.

Resultado: um recebível sem NFe validada faz a primeira regra falhar; como a ação é MANUAL_REVIEW, o recebível vai para a fila de análise humana em vez de ser aprovado direto.

Cenário 3 — Rejeitar parties acima do limite de crédito

Objetivo: barrar de imediato participantes super-alavancados.

1. Escopo: Parties. Ação: Rejeitar. Prioridade: 1 (avaliar cedo).
2. Regras:
   • usedCredit < creditLimit — (modele como between/lte conforme a métrica disponível; aqui use um teto absoluto, ex.😃
   • defaultCount ≤ 2 — Mensagem: "Excesso de inadimplências".
3. Salvar.

Resultado: uma party com 3 inadimplências reprova a segunda regra; como a ação é REJECT, o resultado global da avaliação será rejeição mesmo que outras políticas passem.

Telas relacionadas

• Templates de Precificação
• Templates de Cascata (Waterfall)
• Tipos de Recebível
• Guia de Crédito
• Crédito Tokenizado (índice do grupo)