Reglas fuertes y reglas débiles

Casi todos los modelos de admisión que hemos visto empiezan igual: una lista de condiciones y un if. Si se cumplen todas, aprobado. Si falla una, rechazado.

Ese diseño se rompe la primera semana. Porque hay condiciones que significan esta operación no existe y condiciones que significan esto que lo mire alguien, y meterlas en la misma lista obliga a elegir entre rechazar operaciones buenas o aprobar operaciones que nadie miró.

Dos niveles, tres desenlaces

La distinción que funciona es clasificar cada regla en uno de dos niveles:

• Una regla fuerte incumplida rechaza.
• Una regla débil incumplida manda a revisión manual.
• Si se cumplen todas, aprobado.

Fíjate en que dos niveles de regla producen tres desenlaces. Y en que el rechazo manda sobre la revisión: si una operación incumple una fuerte y tres débiles, es un rechazo, no una revisión con matices.

Fuertes hay pocas, y son casi siempre binarias: el contribuyente está activo, el contribuyente está habido, la empresa no está en una lista de exclusión. Son condiciones sobre las que nadie va a ejercer criterio, porque no hay criterio que ejercer: un contribuyente al que SUNAT no localiza en su domicilio fiscal no es alguien a quien vayas a cobrarle una factura.

Débiles son casi todas las demás, y son las que llevan número: años operando, meses de historial, porcentaje en cada categoría de la central de riesgos, días de atraso, deuda tributaria, plazo de la operación, uso de la línea.

En Pluxo esos dos niveles son tres severidades —rechazo, revisión y aviso—, porque hace falta un tercer escalón para las señales que no deben bloquear nada pero sí quedar escritas.

Se evalúan todas, incluso después de un rechazo

Cuando una regla fuerte falla, la tentación es cortar el bucle y devolver el rechazo. Es más rápido y es un error.

Que una operación incumpla cinco reglas es información distinta a que incumpla una. La primera es una empresa con la que no vas a trabajar; la segunda puede ser un dato mal cargado. Si cortas en la primera, el analista que abre el caso no puede distinguirlas, y tú tampoco puedes analizar tu propia cartera después.

El coste de seguir evaluando es despreciable. El coste de no saber es alto.

Una decisión sin traza no es una decisión

Un motor que devuelve RECHAZADO es un motor que no sirve. Lo que tiene que devolver, por cada regla que ha mirado:

qué regla · qué hecho miró · con qué operador · contra qué umbral · qué valor encontró · si pasó o no · y la frase que lo explica

Con eso, la respuesta al cliente deja de ser una opinión y pasa a ser una comprobación. El analista no reconstruye nada. El comité de riesgos puede auditar decisiones de hace seis meses. Y cuando alguien discute un rechazo, la conversación es sobre el umbral, que es lo que se puede cambiar, y no sobre si el sistema funciona bien.

Es también lo que permite la única prueba honesta de una política: coger operaciones que ya pasaron y volver a evaluarlas con el umbral nuevo antes de guardarlo.

Superar la línea no debería rechazar

Merece la pena mirar aparte una regla que casi todo el mundo coloca en el nivel equivocado.

Que una operación supere la línea disponible del deudor no dice nada malo del deudor. Dice que esta operación concreta no cabe hoy. Puede caber mañana, cuando cobre otra, o puede caber si se parte, o puede caber si alguien decide ampliar la línea porque el deudor lo merece.

Rechazarla automáticamente tira una operación buena y una conversación comercial. Mandarla a revisión cuesta cinco minutos de un analista.

La regla general: una regla es fuerte solo si ninguna persona razonable, con toda la información delante, aprobaría esa operación. Si se te ocurre un caso en el que sí, es débil.

El resultado que hay que aceptar

Si escribes los cortes con la severidad que de verdad quiere tu comité de riesgos, va a pasar algo incómodo: la aprobación automática se convierte en la excepción. La mayoría de las operaciones caen en revisión manual.

Nuestra primera reacción fue pensar que el modelo estaba mal calibrado. No lo estaba. La cola de análisis es la operativa normal de un factoring, no un caso borde, y el trabajo del motor no es vaciarla.

El trabajo del motor es que cada caso llegue a esa cola con el expediente montado, la regla que lo mandó ahí escrita y el valor que la incumplió al lado. Un analista que entiende en diez segundos por qué tiene un caso delante resuelve al día muchos más que uno que empieza de cero cada vez.

Y con los umbrales en una pantalla en vez de en el código, el comité puede mover el que le sobra sin abrir un ticket ni esperar a un despliegue. Que es, al final, de lo que va todo esto.