Políticas de Crédito

Requisitos previos de acceso

• Permiso (módulo): creditConfigManage (para crear/editar). La lectura de la pantalla está habilitada por viewCredits.
• Licencia/Feature: CREDIT_INVESTMENTS habilitada en la licencia del tenant (Vault).
• Contenedor del menú: TOKENIZACIÓN → grupo Crédito Tokenizado

Qué es / cuándo usar

La pantalla de Políticas de Crédito registra reglas de elegibilidad y evaluación automática de riesgo que el motor de crédito aplica automáticamente sobre Deals (operaciones), Cuentas por cobrar y Parties (participantes). Cada política es un conjunto de reglas (campo + operador + valor) asociadas a una acción — aprobar automáticamente, enviar a revisión manual o rechazar.

Use esta pantalla antes de operar crédito: las políticas son el "bloqueo de riesgo" que decide si una operación pasa directamente, requiere análisis humano o es bloqueada en el origen, sin depender de que el operador recuerde cada criterio.

Requisitos previos

• Permiso: creditConfigManage registrado para el rol del operador (recordar: el permiso es doble — enum estático CPM en el backend + módulo dinámico en la BD que controla los *ngIf de la pantalla; ambos deben estar activos para que aparezcan los botones).
• Licencia/Feature: CREDIT_INVESTMENTS habilitada. Si está deshabilitada, el grupo Crédito Tokenizado ni siquiera aparece en el menú.
• Dependencias de otras pantallas: ninguna. Sin embargo, tiene sentido registrar políticas antes de crear Deals/Cuentas por cobrar, ya que la evaluación se ejecuta en el momento de aprobación de esas entidades.

Paso a paso

1. Acceda al menú Crédito Tokenizado → Políticas.
2. Use los filtros Alcance (Deals / Cuentas por cobrar / Parties) y Activo (Sí/No) para localizar políticas existentes.
3. Haga clic en Crear para abrir el formulario.
4. Complete Nombre, Alcance, Prioridad, Versión y la Acción (qué ocurre si una regla falla).
5. En el bloque Reglas, haga clic en Agregar regla y construya cada condición: Campo (la lista cambia según el alcance), Operador, Valor y un Mensaje de error opcional.
6. Haga clic en Guardar (o Actualizar al editar).

Campos

Campo	Qué es	¿Obligatorio?	Efecto en el sistema/backend
Nombre	Identificación de la política	Sí	Guardado en name; aparece en el listado y en el resultado de la evaluación (policyName).
Alcance	En qué entidad se aplica la política: DEAL, RECEIVABLE o PARTY	Sí	Define scope. El motor solo evalúa políticas cuyo alcance coincide con la entidad que se está aprobando (PolicyEvaluationService.evaluate(scope, ...)). Cambiar el alcance modifica la lista de Campos disponibles.
Prioridad	Orden de evaluación (menor = más temprano)	No (default 0)	Guardado en priority; las políticas se obtienen ordenadas por prioridad. No interrumpe la evaluación — todas las políticas del alcance se evalúan, pero el orden afecta la lectura del resultado.
Versión	Número de versión de la política	No (default 1)	Guardado en version; sirve para rastrear revisiones de la regla a lo largo del tiempo.
Activo	Activa/desactiva la política	Sí (default Sí)	Guardado en active. Solo las políticas activas son evaluadas (findByScope(scope, true)). Desactivar es la forma de "jubilar" sin borrar el historial.
Descripción	Texto libre que explica la política	No	Guardado en description; documentación interna, sin efecto en la evaluación.
Acción	Qué ocurre si alguna regla de la política falla: Aprobar Automáticamente, Revisión Manual o Rechazar	Sí	Guardado dentro de rulesJson como action. En la evaluación, la acción se escala entre todas las políticas reprobadas: REJECT > MANUAL_REVIEW > AUTO_APPROVE. Basta con que una política exija REJECT para que el resultado final sea rechazo.
Regla → Campo	Atributo de la entidad a comparar (ej.: grossAmount, riskScore, originator.riskScore)	Sí (por regla)	Leído por dot-notation del objeto evaluado (originator.riskScore lee de { originator: { riskScore } }). La lista de campos es específica por alcance.
Regla → Operador	= ≠ > ≥ < ≤ IN NOT IN BETWEEN EXISTS NOT EXISTS	Sí (por regla)	Define la comparación. IN/NOT IN/BETWEEN esperan una lista de valores (separados por coma); BETWEEN usa exactamente dos (mín, máx). EXISTS/NOT EXISTS verifican la presencia del campo.
Regla → Valor	Valor de comparación	Condicional	Convertido automáticamente: true/false se convierten en booleano; los números se convierten en numérico; para IN/NOT IN/BETWEEN se divide por coma en lista.
Regla → Mensaje	Mensaje de error mostrado cuando la regla falla	No	Guardado en rule.message; aparece en el resultado de la evaluación como motivo de la reprobación (failedRules[].message).

Acciones y modales

• Crear / Actualizar: guarda la política mediante createPolicy / updatePolicy. El botón Guardar/Actualizar solo se renderiza para quienes tienen creditConfigManage.
• Agregar regla / Eliminar regla: manipulan la lista de reglas en el formulario y regeneran el rulesJson automáticamente (no se edita el JSON a mano).
• Editar (ícono de lápiz en la tabla): carga la política y reconstruye las reglas a partir del rulesJson guardado.

Como es una operación sensible de configuración de riesgo, guardar puede disparar step-up (re-autenticación contraseña + MFA, header X-Step-Up-Token, ventana de 5 min) dependiendo de la configuración del entorno. Esto no es aprobación 4-eyes — solo reconfirma la identidad del operador.

Reglas de negocio / advertencias

Atención

• Sin política = aprobación automática. Si un alcance no tiene ninguna política activa, la entidad es auto-aprobada por defecto. No existe un "denegar todo" implícito — el bloqueo solo existe si usted lo registra.
• Fallo en la evaluación cae en Revisión Manual. Si el motor produce un error al evaluar (ej.: rulesJson corrupto), el resultado se fuerza a MANUAL_REVIEW por seguridad — nunca aprueba a ciegas.
• Los campos nulos reprueban. Si el campo de la regla no existe en el objeto evaluado, la mayoría de los operadores falla (excepto NOT EXISTS). Tenga cuidado al referenciar campos que no siempre vienen completados.
• Cambiar el alcance restablece los campos válidos. Las reglas construidas en un alcance pueden referenciar campos que no existen en otro; revise las reglas si cambia el alcance de una política existente.
• La escalada de acción es por reprobación. Una sola política con acción REJECT reprobada ya lleva el resultado global a rechazo, aunque decenas de otras hayan pasado.

• Valores financieros: los campos numéricos comparados (valores brutos/netos, límites de crédito) representan montos que en el dominio de crédito se tratan como BigNumber — al definir umbrales (ej.: grossAmount > 100000), verifique la unidad/decimales esperados por el motor.

Ejemplos

Escenario 1 — Auto-aprobar deals pequeños de un originador confiable

Objetivo: liberar sin fricción operaciones de bajo valor de buenos originadores.

1. Alcance: Deals. Acción: Aprobar Automáticamente.
2. Reglas:
   • grossAmount ≤ 50000
   • originator.riskScore ≥ 70
   • originator.defaultCount = 0
3. Guardar.

Resultado: al aprobar un deal de R$ 30.000 cuyo originador tiene un score de 80 y cero incumplimientos, las tres reglas pasan y el deal es auto-aprobado. Si el valor fuera R$ 80.000, la regla ≤ 50000 falla y, como la acción es AUTO_APPROVE, esta política simplemente no bloquea — el resultado dependerá de las demás políticas del alcance.

Escenario 2 — Forzar revisión manual de cuentas por cobrar sin factura validada

Objetivo: nunca aprobar automáticamente una cuenta por cobrar sin documento fiscal validado.

1. Alcance: Cuentas por cobrar. Acción: Revisión Manual.
2. Reglas:
   • hasInvoiceValidation = true — Mensaje: "Factura no validada".
   • hasDebtorConsent = true — Mensaje: "El deudor no confirmó".
3. Guardar.

Resultado: una cuenta por cobrar sin factura validada hace que la primera regla falle; como la acción es MANUAL_REVIEW, la cuenta por cobrar va a la cola de análisis humano en lugar de ser aprobada directamente.

Escenario 3 — Rechazar parties por encima del límite de crédito

Objetivo: bloquear de inmediato a los participantes sobre-apalancados.

1. Alcance: Parties. Acción: Rechazar. Prioridad: 1 (evaluar temprano).
2. Reglas:
   • usedCredit < creditLimit — (modele como between/lte según la métrica disponible; use un techo absoluto aquí, ej.😃
   • defaultCount ≤ 2 — Mensaje: "Exceso de incumplimientos".
3. Guardar.

Resultado: una party con 3 incumplimientos reprueba la segunda regla; como la acción es REJECT, el resultado global de la evaluación será rechazo aunque otras políticas pasen.

Pantallas relacionadas

• Plantillas de Precios
• Plantillas de Cascada (Waterfall)
• Tipos de Cuenta por Cobrar
• Guía de Crédito
• Crédito Tokenizado (índice del grupo)