Políticas de crédito: cómo digitalizarlas y aplicarlas sin excepciones

Resumen ejecutivo

En la mayoría de las instituciones financieras, la política de crédito vive en un PDF, en la cabeza del director de riesgos, y en mil excepciones de WhatsApp. El motor de decisión real es la mesa de control, no el sistema.

El resultado: cada solicitud que toca a un humano abre la puerta a discrecionalidad, sesgo y tiempo. Y lo peor: la política que está escrita y la política que se aplica son cosas distintas, y nadie puede auditar la diferencia.

Esta guía explica cómo se traduce una política de crédito tradicional a un motor de reglas digital, auditable y modificable sin código.

1. Qué es una política de crédito (en serio)

Una política de crédito es el conjunto de reglas escritas que definen a quién, cuánto, en qué condiciones y bajo qué validaciones la institución otorga crédito. Debe cubrir:

• Sujetos de crédito (perfil mínimo, edad, ingreso, antigüedad laboral, geografía).
• Productos elegibles por perfil.
• Montos, plazos y tasas por segmento de riesgo.
• Documentación requerida por nivel.
• Reglas de buró (score mínimo, MOP, consultas recientes, capacidad de pago).
• Validaciones obligatorias (RENAPO, listas PLD, verificación domiciliaria).
• Reglas de excepción: quién puede aprobar qué fuera de política, con qué límite, con qué soporte.
• Reglas de revisión y vigencia.

Si tu política no cubre alguno de estos puntos, no es política, es lineamiento.

2. Por qué la política en PDF deja de funcionar

Tres problemas estructurales:

1. Drift. Cada excepción aprobada por mesa se vuelve precedente. En 12 meses, la política aplicada se separa de la escrita.
2. Latencia de cambio. Cambiar el cutoff de score en un PDF toma 5 minutos. Implementarlo en el sistema, 6 semanas vía ticket a TI.
3. No auditable. Cuando el regulador o el consejo pide "muéstrame cómo decidiste estos 50 créditos rechazados el trimestre pasado", la respuesta honesta es "no podemos".

Las instituciones modernas resuelven los tres problemas a la vez moviendo la política al motor.

3. Anatomía de un motor de reglas de crédito

El motor de decisión es la pieza donde la política se vuelve ejecutable. Características no negociables:

• Configurable sin código por el área de riesgos.
• Versionado: cada cambio queda registrado con autor, fecha, motivo.
• Backtest: antes de publicar un cambio, simularlo sobre la cartera histórica.
• Trazabilidad punto a punto: para cualquier crédito (aprobado o rechazado), reconstruir qué reglas se evaluaron, con qué insumos y qué decidieron.
• Champion/Challenger: poder correr 2 versiones de política en paralelo sobre subgrupos.
• Excepciones controladas: si una solicitud cae fuera, escala a un nivel humano con límite y firma; el caso queda como excepción etiquetada.

Sin estas seis cosas, el "motor" es solo un if-else escondido en código.

4. La pirámide de decisión

Una política digital madura ordena las reglas en capas:

1. Knockouts (binarios, primero): edad, geografía, listas PLD, MOP malo, fraude previo. Si falla, rechazo inmediato.
2. Validaciones (deben pasar): RENAPO, comprobante de ingreso, biometría.
3. Score (numérico): combinación de buró + alternativos. Genera cutoff.
4. Capacidad de pago: cálculo de DTI sobre ingreso validado.
5. Asignación de oferta: monto, plazo, tasa según segmento de riesgo.
6. Reglas de portafolio: límites por canal, geografía, producto, tipo de cliente.

El 80% de las solicitudes se resuelven en las capas 1-3. La mesa de control solo toca el 20% restante.

5. Excepciones: el termómetro de tu política

En una operación sana, las excepciones son < 10% de las solicitudes aprobadas, todas con monto bajo y todas etiquetadas por motivo. Si tus excepciones son 30% o más, alguna de estas cosas pasa:

• La política es demasiado restrictiva y la realidad la sobrepasa todos los días.
• Los aprobadores no respetan la política y aprueban fuera por relación comercial.
• El sistema no permite implementar la política como está escrita, así que la mesa la "corrige".

Cualquiera de las tres es un problema, no una virtud.

6. Cómo se ve el día a día con política digitalizada

• Una solicitud nueva entra, el motor evalúa todas las capas en menos de 2 segundos y devuelve aprobado, rechazado o excepción.
• Aprobado pasa directo a oferta, contrato y desembolso.
• Rechazado guarda en su expediente las reglas que no pasó.
• Excepción cae en cola de un comité virtual con SLA, soporte adjunto y nivel de aprobación calibrado al monto.
• Cada viernes, el reporte automático muestra: % de aprobación, % de excepciones por aprobador, drift de cutoff, comparativo de cosecha vs. baseline.
• Cuando el comité decide ajustar política, el cambio se simula sobre los últimos 90 días de solicitudes antes de publicarse.

Eso es control de riesgo en serio. Lo otro es Excel.

7. Plan de migración (PDF a motor)

Mes 1: levantar la política aplicada real (no la escrita). Entrevistas a mesa, muestreo de aprobaciones del último trimestre, identificación de reglas implícitas.

Mes 2: traducir la política a estructura de motor (knockouts, validaciones, score, capacidad, oferta, portafolio). Documentar excepciones legítimas como reglas, no como "discrecionalidad".

Mes 3: backtest contra histórico, ajuste de cutoffs, publicación en champion/challenger sobre 20% de la operación.

Mes 4-6: ramp-up al 100%, retiro gradual de excepciones manuales, monitoreo semanal de drift.

8. Conclusión

La política de crédito no es un documento: es el corazón operativo de tu institución. Mientras viva en PDF y en cabezas, estás operando una política distinta a la que crees.

Si quieres ver cómo se ve un motor de reglas de crédito configurable, auditable y con backtest integrado, agenda una demo.