Para un director de riesgos, el scoring no es un ejercicio analítico, sino una palanca que entra directamente en el coste del riesgo, la tasa de aprobación y la capacidad de la cartera para sobrevivir a un ciclo peor. Un sistema de scoring crediticio bien construido permite decidir más rápido, más barato y de forma repetible, y aun así defender cada decisión ante la auditoría interna y el regulador. El problema rara vez está en el algoritmo; mucho más a menudo vive en los datos, en el proceso que rodea al modelo y en quién puede mantenerlo funcionando durante años.
Por nuestra experiencia, lo difícil de estos proyectos es juntar tres mundos a la vez: ingeniería de datos, modelización de riesgo y compliance. En scoring no tenemos una implantación propia terminada que podamos señalar como referencia; lo que sí aportamos es igual de concreto, las personas y las competencias que construyen estos sistemas. Combinamos ingenieros de datos y especialistas de AI/ML del Grupo RITS (nuestros equipos de AI/ML y datos centrados en datos y machine learning) con nuestra experiencia en proyectos para el sector financiero.
¿Para qué hace falta un scoring crediticio y una evaluación del riesgo?
La evaluación del riesgo pone orden en una decisión que de otro modo es subjetiva y difícil de defender. En vez de fiarnos del instinto de un analista, reducimos el riesgo del cliente a un valor medible y repetible y solo después construimos encima la política crediticia. Eso le da al banco varias cosas a la vez: tiempos de decisión más cortos, coherencia entre sucursales y canales, un rastro de auditoría claro y la posibilidad de dirigir el apetito de riesgo con umbrales de corte en lugar de corrigiendo solicitudes a mano. Es esa repetibilidad, y no el resultado de una decisión concreta, lo que marca la diferencia a escala de cartera.
¿Qué datos alimentan los modelos de scoring y qué pasa con su calidad?
Un scoring vale lo que valen los datos con los que aprende y con los que funciona. Antes de que nadie toque un modelo, ordenamos la capa de datos, porque es ahí donde se esconde la mayoría de los problemas posteriores. En la práctica trabajamos con varios tipos de fuentes:
- datos internos del banco - historial de cuentas, transacciones, amortizaciones e impagos,
- datos de registros externos - burós de información crediticia y empresarial,
- datos de comportamiento y de solicitud - actividad en los canales digitales, datos del formulario de solicitud,
- datos macro y sectoriales - el contexto en el que se mueve la cartera.
El mayor riesgo no son los datos que faltan, sino su inconsistencia, sus huecos y los cambios silenciosos de definición entre sistemas. Por eso construimos controles de calidad de datos, un diccionario de variables y monitorización de completitud como parte de la solución, y no como un añadido posterior. Un modelo entrenado con datos sucios queda bien sobre el papel y falla en producción.
¿Reglas o machine learning, y qué pasa con la explicabilidad?
Esta no es una elección binaria. Las reglas de negocio dan control total e interpretabilidad inmediata, así que funcionan de maravilla para políticas duras y cortes regulatorios. Los modelos de ML, a su vez, capturan relaciones que no se pueden escribir a mano y normalmente mejoran la separación entre clientes. En proyectos de scoring lo que más hacemos es combinar ambos enfoques: una capa de reglas para las condiciones duras y un modelo estadístico o de ML donde decide la calidad de la predicción.
La explicabilidad es crítica aquí. En crédito hay que justificar una decisión ante el cliente y ante el supervisor, así que preferimos modelos y herramientas que muestren por qué un cliente obtuvo una determinada puntuación. En la práctica eso significa scorecards transparentes y, cuando entra el ML, técnicas como SHAP y una descripción clara de las variables. Un modelo que no puedes explicar es, en este terreno, un riesgo y no una ventaja.
¿Cómo se validan y monitorizan los modelos de scoring después del go-live?
Un modelo no es un proyecto que termina, sino un sistema que vive. La cartera se desplaza, el comportamiento de los clientes deriva y un buen año puede adormecer al equipo justo antes de uno peor. Por eso tratamos la validación y la monitorización como un proceso continuo, no como un visto bueno puntual. En esta capa solemos vigilar:
- el poder discriminante (Gini, KS, AUC) sobre datos out-of-time, no solo sobre el conjunto de entrenamiento,
- la estabilidad de la población y de las variables (PSI) a lo largo del tiempo,
- la concordancia entre predicción y realidad (calibración, backtesting),
- umbrales de alerta que avisan pronto de la degradación del modelo.
Lo diseñamos para que el equipo de riesgos vea la salud del modelo en tiempo real y tenga una base sólida para decidir un reentrenamiento antes de que el deterioro impacte en el coste del riesgo.
¿Cómo se gestionan el cumplimiento, el sesgo y la supervisión humana?
El scoring funciona con datos sobre personas, así que el cumplimiento y la ética no son un añadido, sino una condición de contorno. Nos aseguramos de que el modelo no se apoye en atributos sensibles ni en sus proxies ocultos, y lo probamos buscando sesgo entre grupos de clientes. En paralelo mantenemos documentación completa: de dónde vinieron los datos, cómo se construyó el modelo y cómo se validó, porque eso es lo que pasa por auditoría.
Aparte, diseñamos la persona en el circuito de decisión. El sistema automatizado puede recomendar y resolver los casos evidentes, pero las decisiones límite y las denegaciones que requieren una justificación se quedan con un experto, con el contexto claro en pantalla. Ese planteamiento junta la velocidad de la automatización con la responsabilidad que espera el supervisor.
¿Cómo se conecta el scoring con el proceso de crédito y los sistemas del banco?
El mejor modelo no entrega nada hasta que forma parte de un proceso de decisión real. Por eso miramos el scoring de punta a punta: desde la solicitud, pasando por el motor de decisión, hasta los sistemas core y el reporting. Exponemos el modelo como un servicio con API, para que la decisión llegue en milisegundos y vuelva al proceso junto con su justificación. Lo conectamos con el motor de reglas, el sistema de solicitudes y el data warehouse, manteniendo el versionado del modelo y un registro completo de cada decisión. El objetivo es simple: el scoring como parte repetible del proceso, y no como una hoja de cálculo ejecutada al margen.
¿Qué competencias aportamos a un proyecto de scoring?
Formamos el equipo alrededor de la etapa concreta y del hueco que haya en tu propio equipo, no «por si acaso». En proyectos de datos y riesgo solemos cubrir estos perfiles:
- ingenieros de datos - construyen la capa de datos, los pipelines y los controles de calidad,
- data scientists / especialistas de ML - diseñan, entrenan y validan los modelos,
- ingenieros de MLOps / DevOps - despliegan los modelos y la monitorización en producción,
- desarrolladores backend - conectan el scoring con el motor de decisión y los sistemas del banco.
Ese equipo trabaja en un modelo de refuerzo de equipo o equipo dedicado, bajo tu supervisión y dentro de tu marco de compliance, sumando competencias justo donde faltan.
¿Cómo lo hacemos en RITS?
Lo hacemos como partner nearshore desde Polonia que combina competencias de datos e IA con experiencia en el sector financiero. No vendemos una «caja» de scoring, porque un buen scoring siempre está hecho a medida de la cartera, la política y los datos de un banco concreto. En su lugar cubrimos los perfiles y construimos la solución contigo, junto a tu equipo de riesgos: ingenieros de datos del Grupo RITS y especialistas de AI/ML (nuestros equipos de AI/ML y datos) construyen la capa de datos y los modelos, mientras nosotros cuidamos la explicabilidad, la validación y la integración en el proceso. Verificamos las competencias antes de empezar y trabajamos en una zona horaria cercana, así que el equipo entra en revisiones y reuniones sin una larga puesta en marcha.
¿Por dónde empezar con el scoring y la evaluación del riesgo?
Empieza por una sola decisión de crédito y sus datos, no por elegir un algoritmo. Define exactamente qué quieres predecir (p. ej. el riesgo de impago en un producto concreto), qué datos tienes de verdad y con qué calidad, y cómo debe encajar la decisión en el proceso y en la supervisión. Eso define el alcance del modelo, los requisitos de validación y los perfiles que necesitas. Si estás sopesando cómo montar mejor el equipo, encontrarás una comparación en nuestro artículo sobre modelos de colaboración en TI.
¿Vas a construir un scoring crediticio o a renovar tu evaluación del riesgo de cliente? Hablemos - buscamos un equipo y un enfoque para tu cartera y tus requisitos de supervisión.
Construye con nosotros el scoring y la evaluación del riesgo