Data Leakage en Credit Scoring: El Error que Invalida tu Modelo

Imagina que construyes un scorecard con un Gini de 0,85. Un resultado extraordinario, muy por encima de los valores típicos de 0,40 a 0,65 en credito al consumo. El modelo pasa todas las pruebas de validación, el equipo está satisfecho y se despliega en producción.

Tres meses después el modelo deja de funcionar. El Gini cae a 0,35. Las predicciones son inútiles. El equipo de riesgo investiga y encuentra el problema: una de las variables del modelo contenía información futura, datos que en el momento real de la toma de decisión no estarían disponibles. El modelo había aprendido a predecir el default usando información que solo existe después de que el default ocurre. Un problema que no esta en el modelo, esta en los datos.

Esto es lo que se conoce como data leakage. Es el error más difícil de detectar en la construcción de modelos de credit scoring y el más costoso cuando pasa desapercibido. Un modelo con data leakage puede parecer perfecto durante la validación y será completamente inútil en producción.

En esta entrada explicamos qué es el data leakage, los tipos que existen, cómo detectarlo y cómo prevenirlo. El constructor de scorecards del laboratorio de Analytics Lane implementa detección automática de data leakage en el preprocesado, diferenciando claramente entre leakage temporal y pseudo-IDs, dos problemas distintos que a menudo se confunden.

Qué es el data leakage

El data leakage ocurre cuando el modelo tiene acceso durante el entrenamiento a información que no estaría disponible en el momento real de tomar la decisión. El modelo aprende a usar esa información — extremadamente predictiva, pero ilegítima — y obtiene métricas de validación artificialmente buenas. Pero, debido a que cuando se despliega en producción esa información ya no está disponible, el modelo falla.

La palabra “leakage” (fuga en español) describe bien el fenómeno: información del futuro “se fuga” hacia el pasado contaminando el conjunto de entrenamiento.

En credit scoring el momento de la toma de decisión es la fecha de la solicitud de crédito. Cualquier variable que contenga información posterior a esa fecha es potencialmente leakage. Y la frontera temporal no siempre es obvia, especialmente cuando los datos proceden de sistemas operacionales que actualizan los registros históricos con información nueva.

Los tipos de data leakage en credit scoring

En la práctica, el data leakage aparece siempre en alguna de estas cinco formas:

Tipo 1: Leakage temporal directo

El caso más claro. La variable contiene información que por definición solo puede existir después del evento de default.

Ejemplos típicos:

• dias_mora_actual: los días de mora en el momento del análisis, calculados sobre el estado actual del préstamo
• fecha_primer_impago: la fecha en que el cliente dejó de pagar por primera vez
• importe_recuperado: cuánto se ha recuperado de una deuda en mora
• provision_constituida: la provisión contable que el banco ha dotado para ese cliente
• estado_operacion: con valores como “impagado”, “en mora”, “en concurso”, “fallido”
• num_cuotas_impagadas: número de cuotas sin pagar

Estas variables tienen tasas de default artificialmente perfectas: todos los clientes con dias_mora_actual > 90 han impagado, por definición. El modelo aprende esta relación trivial pero inútil; en producción, al evaluar una solicitud nueva, dias_mora_actual es cero por definición porque el préstamo aún no existe.

No es capacidad predictiva. Es una tautología disfrazada de modelo.

Tipo 2: Leakage por proxy

Más sutil y más difícil de detectar. La variable no mide directamente el default pero es una transformación o consecuencia de él.

Ejemplos típicos:

• calificacion_interna_riesgo: si esta calificación se calcula usando el propio modelo de default o información posterior, es un proxy del target
• scoring_bureau_actual: si el sistema de información crediticia actualiza el scoring con información de mora, el scoring actual de un cliente que ya ha impagado refleja ese impago
• saldo_disponible_actual: en tarjetas de crédito, los clientes en mora suelen tener el límite bloqueado, lo que hace que el saldo disponible sea cero o negativo
• num_consultas_bureau_recientes: un cliente que está buscando refinanciación porque no puede pagar puede tener más consultas recientes

La clave para identificar el leakage por proxy es preguntarse: ¿el valor de esta variable en el momento de la solicitud original habría sido el mismo que el valor que tenemos en el conjunto de datos? Si la respuesta es no, hay leakage.

El modelo no ve el default directamente, pero ve su sombra.

Tipo 3: Leakage por diseño del conjunto de datos

Este tipo es consecuencia de cómo se construye el conjunto de datos de entrenamiento, no de las variables en sí. Ocurre cuando la muestra de entrenamiento no respeta correctamente la ventana temporal.

El problema de la ventana de observación

En un estudio de credit scoring típico se define:

• Fecha de referencia: el momento en que se evalúa al cliente (la solicitud)
• Ventana de observación: el período anterior a la fecha de referencia del que se toman los datos de las variables
• Ventana de performance: el período posterior a la fecha de referencia en el que se observa si el cliente impaga

El leakage ocurre cuando datos de la ventana de performance se filtran a la ventana de observación. Por ejemplo si se usa el saldo medio de los últimos 12 meses para un cliente cuyo préstamo se originó hace 6 meses y lleva 6 meses en mora, esos últimos 6 meses de saldo incluyen el período de mora y el saldo medio estará artificialmente deprimido.

El problema del look-ahead bias

Ocurre cuando se usan en el entrenamiento datos que en la fecha de referencia aún no estaban disponibles porque aún no habían ocurrido. Por ejemplo si se usan los ingresos declarados en la declaración de la renta de 2024 para entrenar un modelo que evalúa solicitudes de 2023, obviamente, en 2023 la declaración de 2024 no existía.

El sesgo de supervivencia

Solo se incluyen en el conjunto de datos los clientes que “sobrevivieron”, es decir, que completaron el proceso de solicitud, que no fueron rechazados automáticamente, que mantuvieron el producto durante la ventana de performance. Los clientes que cancelaron el producto antes de que terminara la ventana de performance pueden estar excluidos, introduciendo un sesgo sistemático. Lo que representa un caso típico del sesgo de supervivencia.

Tipo 4: Leakage por pseudo-IDs

Técnicamente los pseudo-IDs son distintos del leakage temporal, pero es algo igualmente dañino. Un pseudo-ID es una variable que identifica o casi identifica a cada observación individualmente.

Ejemplos típicos:

• nombre o apellidos del cliente
• nif, nie, dni o número de pasaporte
• num_expediente o num_contrato
• email o telefono
• codigo_postal a nivel de portal (miles de categorías únicas)

El problema con los pseudo-IDs no es que contengan información del futuro, es que el modelo los memoriza. Si en el dataset de entrenamiento el cliente con nif = 12345678A impagó, el modelo aprende que ese NIF predice el impago. En el conjunto de entrenamiento esto produce un WOE e IV artificialmente altos. En producción, cuando el modelo ve un NIF nuevo que no estaba en el entrenamiento, algo que es de lo más habitual, no tiene información y colapsa.

El resultado es el mismo que con el leakage temporal: métricas de validación perfectas en entrenamiento, modelo inútil en producción. La diferencia es simplemente el mecanismo, memorización en lugar de información del futuro.

El modelo no aprende patrones. Memoriza casos.

Por qué el data leakage es tan difícil de detectar

Lo más peligroso del data leakage no es que exista. Es que no se ve. Algo que se puede explicar por varios motivos.

Las métricas de validación no lo detectan

Esta es la razón principal por la que el data leakage es tan peligroso. Un modelo con leakage produce métricas de validación excelentes — Gini alto, KS alto, AUC alto — incluso en el conjunto de test, siempre que el test también contenga la variable con leakage.

La validación estándar (train/test split) no detecta el leakage porque tanto el conjunto de entrenamiento como el de test tienen el mismo problema. El modelo aprende la relación espuria en el train y la confirma en el test, porque en el test también existe esa relación espuria.

La única forma de detectar el leakage con métricas de validación es hacer una validación out-of-time, es decir, usar un período temporal distinto para el test. Si el Gini cae drásticamente entre la validación estándar y la validación out-of-time es una señal de leakage o de overfitting severo.

El leakage puede ser sutil

No todo el leakage es tan obvio como dias_mora_actual. En muchos casos el leakage es parcial, la variable contiene información del futuro solo para algunos clientes o en algunos rangos de valores.

Por ejemplo saldo_medio_ultimos_6_meses puede estar calculado correctamente para la mayoría de los clientes pero contaminar la muestra para los clientes cuyos primeros impagos ocurrieron dentro de esa ventana de 6 meses. El leakage es real pero afecta solo a una fracción de la muestra.

Los nombres de las variables engañan

Una variable llamada ingreso_anual parece perfectamente inocua. Pero si ese ingreso anual corresponde a la declaración de la renta del año siguiente a la fecha de referencia hay leakage. El nombre no dice nada sobre cuándo se calculó la variable.

En conjuntos de datos procedentes de sistemas operacionales — donde los registros se actualizan continuamente — la misma variable puede estar calculada en distintas fechas para distintos clientes, dependiendo de cuándo se extrajo la información. Esto es especialmente frecuente en entidades con sistemas legados donde la trazabilidad temporal de los datos es deficiente.

Señales de alerta de data leakage

Aunque el leakage es difícil de detectar definitivamente sin conocer el proceso de generación de los datos, existen señales de alerta que deben provocar una investigación más profunda.

IV muy alto (> 0,50)

Como vimos en el artículo sobre WOE e IV, un IV superior a 0,50 es sospechoso. En variables financieras genuinas es muy raro obtener IVs tan altos sin leakage. Las excepciones existen — algunas variables de sistema de información crediticia pueden tener IVs legítimamente altos — pero siempre deben investigarse.

Tasa de default extrema en algún valor

Si algún valor o bin de una variable tiene una tasa de default cercana al 100% o al 0%, es una señal de alerta. Una tasa del 98% en el bin dias_mora_actual > 90 no es poder predictivo — es una tautología.

Correlación muy alta con el target

Una correlación biserial entre la variable y el target superior a 0,70 es inusual en variables genuinamente predictivas. No es imposible — la variable puede ser realmente muy predictiva — pero merece investigación.

Nulos correlacionados con el target

Si los valores nulos de una variable se concentran en buenos pagadores o en malos pagadores de forma muy marcada, puede ser que la variable solo exista después del default. Por ejemplo importe_recuperado solo tiene valor para los clientes que han impagado, para el resto es nulo. Esta distribución de nulos es en sí misma una señal de leakage.

Nombre de la variable sospechoso

Variables con términos como “mora”, “impago”, “default”, “incumplimiento”, “recuperado”, “provision”, “dotacion”, “saneamiento”, “dias_” en el contexto de pagos, o “estado_” con valores que describen situaciones de mora son candidatas a leakage temporal directo.

Cómo prevenir el data leakage

Evitar el data leakage no es cuestión de algoritmos, sino de disciplina en los datos.

Definir claramente la fecha de referencia

Antes de construir el dataset de entrenamiento hay que definir con precisión qué fecha se considera la fecha de referencia, el momento en que se toma la decisión de crédito. Todos los datos de las variables deben ser anteriores a esa fecha para cada observación.

Esta definición parece obvia pero en la práctica es frecuente que distintos miembros del equipo tengan distintas interpretaciones. Documentar la fecha de referencia y el proceso de construcción del conjunto de datos es esencial.

Auditar cada variable con la pregunta correcta

Para cada variable del conjunto de datos hay que hacerse explícitamente la pregunta: ¿estaría disponible esta variable, con este valor, en el momento de la decisión de crédito?

No “¿podría estar disponible en teoría?” sino “¿estaba disponible en la práctica para esta observación específica, con este valor específico, en esa fecha específica?”

Esta auditoría es manual y requiere conocimiento del negocio y de los sistemas de información. No hay un algoritmo que la sustituya completamente.

Usar validación out-of-time

Además de la validación estándar train/test, hacer siempre una validación out-of-time: entrenar con datos de un período y validar con datos de un período distinto y posterior. Si hay leakage el Gini caerá significativamente en la validación out-of-time.

Una caída de más de 5-8 puntos de Gini entre la validación estándar y la out-of-time es una señal de alerta que merece investigación.

Reconstruir el conjunto de datos desde el origen

Cuando se detecta leakage la solución definitiva es reconstruir el conjunto de datos desde los sistemas originales, asegurando que cada variable se extrae con los valores que tenía en la fecha de referencia de cada observación. Esto requiere que los sistemas operacionales tengan trazabilidad histórica, capacidad de reconstruir el estado de un registro en cualquier fecha pasada.

Si los sistemas no tienen esta trazabilidad, el conjunto de datos puede estar irremediablemente contaminado y hay que trabajar solo con variables cuya definición temporal sea inequívoca.

Mantener un registro con la definición de cada variable

Para cada variable del modelo documentar es aconsejable documentar la siguiente información:

• Qué mide exactamente
• De qué sistema procede
• En qué fecha se calcula o extrae
• Si puede cambiar retroactivamente (si el sistema actualiza valores históricos)
• Si hay dependencia temporal con el evento de default

Este registro — el diccionario de datos del modelo — es esencial para auditar el leakage y para los ciclos de reentrenamiento futuros.

El caso especial de las variables de bureau

Las variables procedentes de bureaus de crédito (CIRBE en España, Equifax, Experian, TransUnion) merecen una mención especial porque son especialmente propensas al leakage sutil.

Un bureau de crédito agrega información de múltiples entidades sobre el comportamiento crediticio de un cliente. El scoring del bureau y las variables derivadas (número de impagos en el sistema, días de mora máximos, saldo en mora) son variables muy predictivas, pero pueden estar contaminadas.

El problema es que el bureau actualiza sus registros continuamente. Si se solicita la información del bureau para un cliente en el momento de construir el dataset de entrenamiento — no en el momento original de la solicitud de crédito — los valores pueden reflejar comportamientos posteriores a la fecha de referencia.

La solución correcta es usar el fichero de bureau tal como estaba en la fecha de referencia de cada observación, lo que requiere que el bureau tenga versiones históricas de sus datos o que la entidad haya guardado las consultas originales. Esto no siempre es posible y es uno de los motivos por los que el leakage de bureau es tan frecuente y tan difícil de eliminar completamente.

Leakage vs variables correlacionadas con el ciclo económico

Existe una confusión frecuente entre leakage y variables que simplemente cambian con el ciclo económico. No son lo mismo.

Una variable como tasa_desempleo_provincial en el momento de la solicitud es una variable legítima, estaba disponible en el momento de la decisión y no contiene información del futuro. Pero si el modelo se entrenó en un período de alta tasa de desempleo y se aplica en un período de baja tasa, la variable tendrá valores muy distintos y el modelo puede degradarse.

Esto no es leakage, es deriva del modelo (model drift). El modelo aprendió una relación correcta en el período de entrenamiento pero esa relación ha cambiado. La solución no es eliminar la variable sino monitorizar el PSI y reentrenar cuando la distribución cambia significativamente.

El leakage es un problema de construcción del conjunto de datos. La deriva del modelo es un problema de cambio en la distribución de los datos a lo largo del tiempo. Confundirlos lleva a soluciones incorrectas.

Data leakage en el constructor de scorecards del laboratorio

El constructor de scorecards del laboratorio de Analytics Lane, incluido en la Suite de Credit Scoring, implementa detección automática de leakage durante el preprocesado, con dos detectores separados para dos tipos de problemas distintos:

• Detector de pseudo-IDs: Evalúa cinco señales: ratio de valores únicos, tamaño mínimo de categoría, IV alto con bins pequeños, patrones de texto identificadores y nombres de variable sospechosos. Clasifica las variables en cuatro niveles de severidad y muestra una ficha detallada con las señales detectadas.
• Detector de data leakage: Evalúa cinco señales distintas: nombre de variable con términos asociados a mora o impago, correlación biserial alta con el target, tasa de default extrema en algún valor, nulos correlacionados con el target y valores categóricos que describen estados de mora. Igualmente clasificado en niveles de severidad con ficha detallada.

Ambos detectores generan avisos diferenciados que aparecen en el momento de cargar el conjunto de datos, antes de cualquier análisis. El analista puede excluir las variables problemáticas desde ese primer momento o mantenerlas con una justificación documentada que queda registrada en el log de decisiones.

La detección automática no sustituye la auditoría manual, ningún algoritmo puede sustituir el conocimiento del negocio y del proceso de generación de los datos. Pero sí sirve como primera línea de defensa que captura los casos más obvios y obliga al analista a reflexionar sobre cada variable sospechosa.

Conclusión

El data leakage es el error más silencioso y más costoso en la construcción de modelos de credit scoring. Silencioso porque las métricas de validación estándar no lo detectan, de hecho las mejoran artificialmente. Costoso porque un modelo en producción con leakage no solo no funciona sino que puede generar decisiones de crédito sistemáticamente incorrectas durante meses antes de que el problema se detecte.

Prevenirlo requiere tres cosas que no son algoritmos sino disciplina:

• Una definición clara de la fecha de referencia para cada observación del conjunto de datos, es decir, el momento exacto en que se toma la decisión de crédito y que determina qué información es legítima y cuál no.
• Una auditoría variable a variable que responda explícitamente la pregunta: ¿estaría disponible este valor en el momento de la decisión? No en teoría, en la práctica, para esta observación específica, en esa fecha específica.
• Una validación out-of-time que detecte las caídas en el Gini que la validación estándar oculta.

El data leakage no es un problema técnico que se resuelve con mejores algoritmos. Es un problema de comprensión del negocio y de disciplina en la construcción del conjunto de datos. Y por eso es el error que más frecuentemente destruye modelos que sobre el papel parecían excelentes.

Nota: Las imágenes de este artículo fueron generadas utilizando un modelo de inteligencia artificial.