Ciencia de datos financieros, Parte 0: 7 diferencias entre la ciencia de datos financieros y el ML general

Comienza la serie «Fundamentos de ciencia de datos financieros». Este artículo es la primera entrega (Parte 0). Quiero explicar, en orden y como si fuera un libro desde la Parte 0, por qué la ciencia de datos funciona de manera distinta al ML general en el campo de la evaluación crediticia. Trataré temas como reject inference, inferencia causal, calibración, validación, equidad y regulación.
El texto original se publicó primero en mi blog → https://han-co.com/ko/blog/part0-finance-ds-7-differences

No soy un veterano con décadas en este campo. Más bien, trabajé como ingeniero en manufactura, luego pasé al sector financiero y ahora trabajo como data scientist del lado de evaluación crediticia. Por eso, me gustaría que vieran este texto no tanto como un “esta es la respuesta correcta”, sino como un ordenamiento de las cosas con las que yo mismo me perdí al entrar en este campo, de esos momentos de pensar “oye, seguí el libro al pie de la letra, ¿entonces por qué sigo fallando?”.

Lo curioso es que no era algo que solo me pasara a mí. Incluso gente que sabe construir y evaluar muy bien modelos de ML en general, cuando llega a evaluación crediticia suele cometer errores parecidos al menos una vez. Los indicadores de validación salen bien, pero en producción el modelo no rinde como debería; la exactitud es de 99%, pero nadie se alegra; exprimiste 0.01 más de desempeño y entonces el área de riesgos bloquea el despliegue…

Más que un problema de habilidad, esto pasa porque finanzas —especialmente evaluación crediticia— no es simplemente “aplicar ML a datos financieros”, sino un campo con reglas algo distintas. Y casi todo lo que veremos en esta serie —reject inference, inferencia causal, calibración, validación y equidad— al final se basa en esas reglas.

1. El sesgo de selección es la configuración por defecto

En los datos de entrenamiento que tenemos hay, en realidad, un gran hueco: solo vemos el resultado de pago de los clientes aprobados. Nunca podremos saber si los clientes rechazados habrían pagado o habrían caído en default. Para empezar, a esas personas ni siquiera se les emitió la tarjeta.

En ML general normalmente se asume que “los datos representan a la población”. Pero en evaluación crediticia esa suposición está rota desde el principio. Los datos de entrenamiento son clientes que ya fueron aprobados en el pasado, mientras que el conjunto sobre el que el modelo debe decidir es el de todos los solicitantes que todavía no han sido aprobados. Son poblaciones distintas.

Total de solicitantes  
├─ Aprobados (resultado observado)  
│   ├─ Pago  → pago normal  
│   └─ Default  → mora/default  
└─ Rechazados (resultado no observado)  → ??? no sabemos si habrían pagado o caído en default  

El modelo aprende solo de los “clientes aprobados”. El resultado real de los clientes rechazados no queda en los datos.

Esta sola característica provoca más problemas de los que parece. Como no existen datos posteriores al rechazo de los “clientes rechazados”, el modelo no puede aprender sobre la región que él mismo rechaza y hereda tal cual los sesgos de la política de evaluación pasada. Por eso, en este campo reject inference (inferencia sobre rechazados) y la inferencia causal no son técnicas especiales, sino lo básico. (Más adelante dedicaré una entrega completa a cada uno de estos temas.)

2. El tiempo fluye en una sola dirección y los modelos envejecen

Si mezclaste los datos aleatoriamente e hiciste K-fold, en realidad hiciste un poco de trampa con el futuro. Eso pasa porque en los datos de validación se mezclan datos del pasado y del futuro.

Los datos crediticios fluyen a lo largo del tiempo. Un modelo entrenado con datos de clientes de 2024 evalúa clientes de 2026. En ese intervalo cambian las condiciones económicas, suben las tasas de interés y también cambian el comportamiento de los clientes y los productos. La distribución se desplaza (drift). El K-fold aleatorio mezcla pasado y futuro, y mete discretamente en la validación información de la que jamás podrías disponer en producción.

Por eso, la validación básica en finanzas es OOT (out-of-time), es decir, evaluar con un período posterior al del entrenamiento. Después del despliegue también hay que monitorear continuamente cuánto se movió la distribución y cómo cambian los clientes con el paso del tiempo. El modelo empieza a envejecer desde el momento en que se despliega.

3. No basta con “quién es más riesgoso”; hace falta “exactamente qué porcentaje”

En problemas de clasificación general, por lo común basta con acertar el orden. Lo importante es ordenar bien quién es más riesgoso que quién, y AUC mide esa capacidad.

Pero en crédito no podemos quedarnos ahí. Se necesita una probabilidad absoluta, es decir, una PD calibrada (calibrated PD). Hace falta poder decir “la probabilidad de default de este cliente es exactamente 3.2%” para poner precio al riesgo (risk-based pricing), constituir provisiones (provisioning) y calcular la pérdida esperada. Solo con el ranking no se puede hacer ninguna de esas cosas.

Por eso, en crédito es bastante común que pase esto: un modelo tiene un AUC excelente, pero una PD incorrecta. La capacidad de discriminación (discrimination) y la calibración (calibration) son ejes distintos, así que hay que cuidar ambas. (También preparé una entrega dedicada solo a calibración. Sorprendentemente, mucha gente omite esta parte.)

4. El costo es asimétrico, llega mucho después y se mide en dinero

La exactitud (accuracy) cuenta todos los errores como si pesaran lo mismo. Pero en crédito, el peso de los errores no se parece en nada.

Lo que se gana al aprobar a un buen cliente es el margen (unos pocos miles de yenes), mientras que el costo de un default es LGD × EAD (cientos de miles de yenes). Un lado pesa decenas de veces más. Por eso, lo que debemos optimizar no es la exactitud, sino la ganancia esperada y la pérdida esperada.

Ganancia esperada = (1 − PD) × margen − PD × LGD × EAD  

La pérdida esperada (EL) en caso de default se descompone de nuevo como el producto de tres elementos.

EL = PD × LGD × EAD  

• PD: probabilidad de default
• LGD: pérdida dado el default
• EAD: exposición al momento del default

Cada uno de esos tres elementos es un problema de modelado distinto. La clave del scoring es la PD.

Además, la respuesta correcta llega mucho tiempo después. Si hoy apruebas a un cliente, solo entre 12 y 24 meses más tarde se confirma si cayó o no en default. Que la etiqueta llegue tan tarde choca bastante con la forma de pensar del ML acostumbrada al feedback rápido. Hay que seguir acumulando decisiones sin conocer todavía el resultado.

5. La estabilidad le gana al desempeño límite

En una competencia de ML, exprimir aunque sea 0.001 adicional de AUC se considera una virtud. Como en competencias tipo Kaggle. Pero en los modelos de crédito del mundo real, muchas veces eso termina siendo una pérdida.

Un modelo que se volvió inestable por obtener una gota más de desempeño pronto se convierte en un costo operativo. Me refiero a modelos en los que la puntuación se mueve demasiado con cualquier pequeña variación en la entrada, no son reproducibles, o aparecen zonas extrañas donde “a mayor ingreso, menor score”. La estabilidad operativa, la reproducibilidad y la monotonicidad suelen ser más importantes que unas décimas o milésimas de desempeño. Esa es también una de las razones por las que la regresión logística sigue viva como estándar de scoring incluso en la era de los GBM.

6. La interpretabilidad no es una opción, sino una obligación

En otros campos, poder explicar “¿por qué salió esta predicción?” es un buen extra. Pero en crédito, si no existe esa explicación, muchas veces es ilegal o directamente no se puede desplegar.

La notificación del motivo de rechazo (adverse action, 否決理由), la explicación ante el regulador y la gobernanza interna exigen todas responder “por qué ese score”. Por eso, una caja negra no es algo elegante, sino un riesgo en sí mismo. Esa es la razón por la que en la práctica se prefieren estructuras como WOE o scorecards, donde los motivos salen de forma natural, y aun cuando se usa boosting se deja montado un mecanismo para extraer razones con SHAP.

7. La sobrecarga regulatoria y de gobernanza siempre está presente

Por último, un modelo no se puede desplegar libremente.

No termina todo cuando ya construiste el modelo. La gestión de riesgo de modelos (MRM), la validación independiente, la documentación y la trazabilidad de auditoría forman parte del proceso de desarrollo. Se separan los desarrolladores de los validadores y un modelo nuevo normalmente pasa bastante tiempo en shadow mode, observado en paralelo, antes de entrar en la toma de decisiones real. La intuición típica de startup de “despleguemos rápido el modelo que mejor rinde” aquí no funciona muy bien. Si va lento, es por una razón. Un solo modelo puede terminar impactando provisiones y hasta el cálculo de capital.

(Trabajando en Japón esto se siente todavía más de cerca. En la emisión de tarjetas y los límites de crédito existe la obligación, bajo la Ley de Ventas a Plazos (割賦販売法), de calcular el monto estimado de capacidad de pago (支払可能見込額), así que el modelo se convierte directamente en fundamento legal. Hablaré de esto aparte en la entrega sobre regulación.)

¿No lo va a hacer todo la IA?

Últimamente me hacen mucho esta pregunta. Con la rapidez a la que avanzan la IA generativa y los agentes, me preguntan si de verdad vale la pena aprender este tipo de conocimiento de modelado. Mi respuesta honesta es que, al contrario, hace más falta que antes (al menos por ahora).

Las 7 cosas que vimos hasta aquí no son un algoritmo específico, sino la estructura del problema en este campo. Contrafactuales no observados, datos que fluyen en orden temporal, costos asimétricos, probabilidades absolutas, estabilidad, obligación de explicación y regulación. Poner un LLM encima no hace que esos problemas desaparezcan. Más bien, hace falta alguien que sepa que esos problemas existen para evitar que un modelo generado automáticamente se equivoque con total seguridad en sí mismo.

En particular, los puntos 6 y 7 son clave. Hay que explicar el motivo del rechazo, hay que validar el modelo de manera independiente, y el resultado se usa como base para provisiones y cálculo de capital. Los modelos de caja negra chocan estructuralmente con esos requisitos. Por eso, la IA generativa no se lleva toda la evaluación crediticia de punta a punta; en cambio, quien entiende “por qué debe ser explicable y cómo se valida” es quien permanece en el lugar de juzgar los resultados que produce esa IA.

Claro que también hay cosas que sí cambian. La escritura de código repetitivo y el análisis básico cada vez pasan más al terreno de la IA. Por eso, el centro de gravedad del trabajo práctico se mueve desde la capacidad de escribir modelos a mano hacia el criterio para plantear bien el problema, validarlo y auditarlo. Eso segundo es justamente lo que esta serie quiere abordar.

Entonces, ¿qué significa tener habilidad en este campo?

Si resumimos estas 7 ideas en una sola línea, sería así:

La ciencia de datos financieros no es una “competencia de exactitud predictiva”, sino el trabajo de estimar de forma explicable y estable contrafactuales no observados (counterfactual) en un entorno donde el tiempo avanza y los costos son asimétricos.

Los indicadores de evaluación y las scorecards son algo así como el boleto de entrada. La verdadera diferencia de nivel se define en el sesgo de selección, la causalidad, la validación y la gobernanza.

En esta serie quiero profundizar una por una en estas 7 ideas. Cómo abordar reject inference, por qué casi todos se equivocan con la calibración, por qué la inferencia causal es clave en evaluación y cómo validar para sobrevivir en producción. A partir de la próxima entrega, avancemos juntos.

---

Este artículo se publicó originalmente en han-co.com y se serializa simultáneamente en coreano y japonés. El texto original con diagramas dibujados a mano y la suscripción por correo están aquí → https://han-co.com/ko/blog/part0-finance-ds-7-differences