top of page

COSAS VEREDES

Tras más de 20 años trabajando en modelización tanto en cliente final como consultor, me encuentro que no se suele dar importancia a un cálculo sistemático y al detalle del valor añadido que aportan los modelos que genera un área de lo que ahora se denomina DS.


ree
ree

Figura 1: Ordenación de datos por risk buckets en un model de bajo Gini frente a otro de mayor Gini (la muestra de simulación es exactamente la misma)


¿Acaso es igual la eficiencia del modelo de la izquierda frente al de la derecha? ¿Y qué ocurre cuando no hay ordenación de datos? ¿Cómo se cuantifica en términos monetarios el aporte económico de un área de DS?


En esta primera entrada del 2024 voy a tratar de cómo se puede dar valor a un área de modelización en el área de riesgo de crédito. Por tanto, no voy a abarcar la totalidad de los modelos que se pueden aplicar (en áreas como marketing, previsiones de demanda, …) porque cada grupo de modelos, va a requerir su propia metodología para medir su aporte económico en euros a la empresa.


En este sentido un área donde la aplicacón de modelos es bastante común es cuándo se trabaja con el problema de la admisión en riesgo de crédito. Es decir, se está ante una financiación de una compra, o bien la concesión de un préstamo, de una hipoteca e incluso en el seguro de riesgo de crédito cuando se trata de financiar una venta a plazos… En todos estos caso donde o bien se ofrece dinero o un producto con la esperanca de que un determinado contrato se cumpla, es habitual que exista un modelo que evalúe si dicho contrato será exitosamente cumplido o no.


Como bien cabe imaginar, en estas áreas un buen modelo puede hacer que se gane mucho dinero o que se pierda bastante, bien porque el modelo no era tan bueno, bien porque no se aplique adecuadamente como ocurre cuando hay desfases con la política comercial y el poder discriminante del modelo (que no se tratará aquí).


Este post es la primera parte de una serie de 3 posts que iré publicando semanalmente para que no sea muy largo. De modo que a continuación muestro como establecer una medida prudente de los beneficios aportados por un modelo de riesgo de crédito en el área de admisión sin considerar los rechazados, dejando esta parte para el segundo de los posts y uno final explicando como se puede hacer todo con R (mi lenguaje favorito a pesar de que siempre he tenido problmeas de pronunciación con esta letra).


Por tanto, para establecer una medida en euros de la eficiencia de un modelo, conviene considerar una serie de directrices:

 

  • La medición se realiza sólo sobre población aceptada, lo cual implica que la eficiencia obtenidos de un modelo de riesgo de crédito, será menor que si se pudiera medir sobre el total de la población (incluyendo la población rechazada), pero el problema es que de los rechazados por el modelo, no se sabe si éstos cumplirían o no con el contrato y sólo cabe ser estimada por alguna técnica de inferencia que se deja para la segunda parte (como se ha comentado anteriormente), por tanto cabe esperar que el resultado a ofrecer va a ser un un resultado mínimo del valor que aporta el modelo a la compañía.

 

  • En general se conoce el porcentaje de rechazo del modelo que se va a denominar rejection, el cual conviene que sea menor al 30%. En mi caso, suelo trabajar con rejection menores al 5% - 10%. Asociado al rejection y según el tipo de modelo que sea, hay un cutoff o punto de corte en términos de valores o de score o de probabilidad a partir del cual se acepta/rechaza un individuo (o una empresa, o incluso alguna transacción de un modo más genérico).

 

  • El Gini que se toma como referencia, al igual que la medida, se calcula también sobre la población aceptada por el modelo, por lo que cabe esperar que el Gini real sea incluso más eficiente que el considerado (hay modos de aplicar inferencias de denegados, pero se debe, en mi opinión realizar demasiadas asumpciones, por lo que el método que describo aquí, aunque con la limitación comentada en la primera directriz, es más sencillo de entender y fácil de usar en la mayoría de los casos).


Con todo lo anterior la metodología a aplicar sería la siguiente:

 

  • Se considera el segmento de aplicación del modelo y para un período temporal (un mes / trimestre), se considera toda la población donde existirá una exposición total que se denominará TotalExposure y la correspondiente al impago (tras haber pasado un horizonte de previsión, en ocasiones dicho horizonte es de 12 meses, pero en otros casos puede ser inferior) que se denominará TotalExposureAtDefault

 

  • Por otro lado, asociados a la cartera (dato a dato) se tendrá también unos ingresos, bien por pago de tipos de interés, bien por pago de primas (en el caso del seguro de riesgo de crédito), que caben denominarse TotalIncome 

 

  • Tras lo anterior se aplica el correspondiente porcentaje de rejection del modelo y se considera toda la exposición que habría. A partir de aquí, para el perídodo considerado (y teniendo por supuesto también en cuenta el horizonte de previsión) se obtendrá una exposición tras el rejection (sobre la aceptación conocida) que cabe denominar ModelExposure y también se tendrá a partir de dicho procentaje los impagos, que tendrán la correspondiente exposición y que cabe finalmente denominar como ModelExposure

 

  • Análogamente, cabría estimar los correspondientes ingresos tras aplicar el modelo y que se denominarán como ModelIncome

 

 

Pues bien, a partir de las anteriores cantidades que (con mayor o menor dificultad), pueden ser calculadas (al ser datos que conectan fuentes operativas y contables por lo general), se obtendrían los siguientes ratios:

                             

ree

En general, si el modelo mejora el sistema, debería ocurrir que:


ree

                        

De hecho, una aproximación a la detección realizada por el modelo se obtendría con:



ree


Así pues, el Detection Rate informa sobre qué parte del riesgo es detectado por el modelo y en teoría se rechazaría por éste. Por tanto, tendrá efecto en cómo de pequeño será el ratio Model Monetary Risk Rate frente al Total Monetary Risk Rate pudiéndose hablar de una mejora del modelo que se definiría como:


ree

Finalmente, el cálculo en euros (que no siempre tiene que ser positivo, pero que se espera que así lo sea), cabría estimarse del siguiente modo, donde ahora entra la estructura de ingresos, que hasta ahora no se ha tratado y por tanto cabe hablar de benefios totales que van a ser denominados como TotalProfits frente a los atribuibles por el uso del model que se denominarían ModelProfits:


ree

La anterior cantidad conviene que sea positiva, porque de no serlo, implicaría que el sistema de admisión actual no genera suficiente ingreso para cubrir el riesgo, además aquí no se consideran otros costes como los operacionales, por tanto, no basta con que sea positivo, sino que debería alcanzar un determinado nivel “suficientemente positivo”.

 

Por otro lado lo que nos interesa son los ModelProfits que, va a ser el aporte de aplicar el modelo sobre el TotalProfits y cuya estimación se haría del siguiente modo:


ree

Figura 2: Esquema gráfico de algunos de los conceptos considerados en la metodología de estimación de riesgos y beneficios atribuilbles a un modelo de admisión de riesgo

 

Varias observaciones a lo anterior:


  1. Conviene notar que ModelProfits depende del cutoff o de la aversión al riesgo o del nivel de rejection a considerar, se observa que si el modelo es bueno, hay un valor eficiente del cutoff donde se maximizan los beneficios, es por tanto falso que continuas restricciones de la concesión implique siempre mayores beneficios

  2. ModelProfits está también muy conectada con el valor denominado RiskRedution, una elevada reducción del riesgo debida al modelo, hará que el aporte del modelo al sistema sea mayor

  3. En general ModelAddValue es positivo, pero si fuese negativo puede ser debido a que o bien se esté rechazando por encima del 40%, o bien se esté ante un modelo con bajo Gini en cuyo caso habría que analizar si este valor tan bajo de Gini es porque realmente es un mal modelo o porque el rejection del que se parte es demasiado alto (a partir del 30%-40% podría dar inconsistnecias en el valor Gini y esta metodología, aunque aplicable, habría que tratarla con cuidado)

  4. Por otro lado, en la mayoría de los sistemas de admisión, hay reglas que deniegan a los clientes antes de que llegue al modelo por tanto, esta población no se considera rechazada por el modelo, y no entran en la valoración que aquí se está aplicando (una regla podría ser rechazar a todos los clientes con los que la compañía ha tenido evento de riesgo de crédito no debidamente satisfecho)



Finalmente os pongo un modelo de tabla de seguimiento (con números simulados) de los resultados de una cartera que sigo mes a mes (con un horizonte de previsión de 3 meses):


ree

 
 
 
  • fjroar
  • 11 nov 2023
  • 3 Min. de lectura

Esta entrada que denomino “Puestas en producción sencillas para vagos R”, no es para menospreciar a quién desee ponerla en práctica (yo ya lo llevo haciendo bastante tiempo …, aunque no soy el mejor ejemplo de no vago jjj) sino que es para informar a muchos estadísticos y DS (fundamentalmente) que me he ido encontrando por ahí, que es posible automatizar de modo sencillo procesos y que no es que podamos, sino que DEBEMOS de ser perfectamente autónomos y tener un cierto grado técnico para determinados fines y no estar requiriendo de las áreas de IT constantemente desarrollo de procesos u otras choradas.


En un anterior post (primera parte de este):



Se trataba de cómo poner modelos de producción en R, lo había hecho todo a partir de un fichero ejecutable .bak que tras ser pulsado cuando el usuario quisiese, le permitiría disparar todo un conjunto de procesos ordenados y orquestados por un programa main.R

Sin embargo, aún puede ser molesto el tener que sencillamente tocar el botón ya que todos sabemos que en nuestro día a día, nos llegan un montón de cosas y además, está el tema de las vacaciones que hace que nos olvidemos de hasta la contraseña para entrar en el Windows, cuanto más, que hay que tocar al dichoso botón.

Pues bien, cuando en una empresa no se goza de plataformas muy avanzadas o hay una enorme burocracia para poner procesos que deberían ser triviales en producción, siempre cabe hacer uso de una calendarización de tareas que casi todos los sistemas operativos permiten, siendo el caso de Windows el siguiente:

ree

Desde luego, sin tener ni idea de programación, es posible indicarle a Windows que haga el trabajo por nosotros y es más, no es necesario ni tan siquiera crear el anteriormente citado fichero .bak sino que directamente, pulsando en la Acción de Crear tarea … que está en el lado derecho de la anterior aplicación (que existe en todos los Windows) y que permite ir creando la tarea dando una enorme cantidad de detalles sobre el modo de ejecución:

ree

Además, entre las tareas más usuales, se encuentra la ejecución de un programa, que tras pulsar Siguiente nos lleva a las siguientes pantallas, donde en la de la izquierda se nos pide que se elija el programa a ejecutar:


ree

Por tanto, con estos sencillos pasos se puede hacer que se ejecute el proceso llamando al programa main.R directamente que estará en la correspondiente carpeta y que en el caso del anteriormente citado proceso de preventiva, tendría el siguiente contenido:


ree

De este modo, se podría directamente eliminar execution y realizar la asociación para la ejecución del diagrama siguiente que ya se comentó en un anterior post:



ree

Además, y lo mejor de todo es que la ejecución por esta vía, genera un log directamente que nos informa de cualquier incidencia que pudiera haber ocurrido.


Por si fuera poco, además R ofrece un librería que permite hacer todo lo anterior de un modo aún mucho más directo. En el caso de Windows (existe otra para esos amantes del Linux …) la librería es taskscheduleR donde podría programarse sencillamente un proceso diario, sin tener que abrir el taskmanager tal como sigue:


library(taskscheduleR)

taskscheduler_create(taskname = “202311_EjecucionPreventiva”,

rscript = “ ../main.R”,

schedule = “DAILY”,

starttime = “10:35”,

startdate = format(Sys.Date(), “%d/%m/%Y”))


Se observa por tanto que indicando en el parámetro rscript la correspondiente ruta, el proceso ya estaría debidamente enrutado.


Finalmente, algunas conclusiones e indicaciones:


  • Lo que se ha descrito tanto en el anterior post citado como en este es un modo de poner procesos en producción en R de modo sencillo y dependientes eso sí, de la máquina donde está R instalado. Hay que tener garantizado, por tanto, para que todo vaya bien que la máquina estará conectada a la red de la empresa y es por tanto conveniente que esté encendida, por tanto, este método es ideal para servidores on premise y sólo en el caso de que sean procesos que nos interese ejecutar a modo personal, la máquina de procesamiento será lógicamente nuestro propio PC.


  • Este método sirve prácticamente para cualquier tipo de lenguaje tipo open source como Python, sin embargo, para los amantes del software propietario tengo que decirles que pueden tener bastantes problemas si van por este camino y es algo más complejo, es lo que tiene pagar tecnologías que esclavizan más que liberan.


  • Como se ha observado, es factible con pocos recursos crear agentes totalmente mecanizados que, puedan llegar incluso a ejecutar modelos dinámicamente y servir datos en distintos formatos, alimentar una base de datos, etc.


  • Finalmente espero que haya servido de ayuda estos 2 post y que os permita eludir el paso, a veces necesaria y excesivamente burocratizado de tener que pasar por IT cuando es algo sencillo a ejecutar de modo batch. Dejemos a los de IT trabajar y propongámosle en todo caso, ejercicios más complejos que requieran procesos tipo real-time.

 
 
 

Para muchos de aquellos que hacen modelos de Credit Scoring, como es mi caso, estoy casi seguro de que os habréis preguntado ¿Cómo puedo incorporar analítica más avanzada a esto y que además mantenga la estructura de interpretación sencilla que me ofrece un Credit Scoring?


Pues bien, esto es un tema que lo trataré en https://eventum.upf.edu/101896/detail/ii-congreso-de-r-y-xiii-jornadas-de-usuarios-de-r.html pero a lo que voy ahora es a ofrecer una vía sencilla que responda a la anterior pregunta, sin meterme en demasiado lío con lo que significaría ir hacia un Machine Learning, que lo dejo para la charla o para otro post posterior.


Pues bien, el Credit Scoring como es bien sabido se estructura en 2 partes fundamentales, la parte del trameado de variables y la de la construcción de un modelo de regresión logística subyacente. Una vez hechas estas 2 partes, el siguiente paso, la construcción de la tarjeta de puntuación se hace de un modo sencillo ya que mediante logaritmos se transforma la salidad habitual de probabilidades de estos modelos como suma de puntos a partir de los scoring parciales.


Una extensión, bastante natural en mi opinión, sería permitir que las regresiones ridge y/o lasso puedan hacer el papel de la regresión logística subyacente y así se estaría dando al menos, posibilidad de introducir estos modelos paradigmáticos del Machine Learning y por tanto se podría jugar con hiperparámetros como el elastic net al que nos habilita la librería de R glmnet:


ree

Entonces el tema es ¿Cómo hacer todo lo anterior de una manera sencilla en R? Pues la respuesta va a ser mediante el uso por un lado de una de mis librerías favoritas como es la scorecard, por supuesto también con el uso de la citada librería glmnet y finalmente con la contribución que os hago sobre una función que he preparado y que he denominado scorecard_glmnet(), esta función tiene como entrada 3 elementos, 2 de los cuáles son los elementos que necesita la función scorecard() de la dichosa librería scorecard y un tercer elemento como es el valor del lambda, con el que se va a penalizar los coeficientes, donde recomiendo que para elegirlo se haga uso de la función cv.glmnet() de la librería glmnet, que si no se pone, se tomará lambda = 0.


Pues bien con mi función, que la podéis utilizar y trastear como os de la gana si la tomáis de mi git en esta url https://github.com/FJROAR/R-function-scorecard_glmnet, se genera una salida totalmente compatible con scorecard_ply() también de la librería scorecard() y que permite generar, posteriormente y en un paso super sencillo, la tarjeta de puntuación como si fuera cualquier modelo de Credit Scoring (todo esto está en el código del git con un ejemplo adicional para que podáis reproducir y para lo que os recomiendo que os descarguéis el dataset https://www.kaggle.com/datasets/mlg-ulb/creditcardfraud), con lo que ya se habría generado una tarjeta de puntuación, ahora sí con un algoritmo propio del Machine Learning (que se conocía, en caso de la ridge desde los años 70 y en el caso de la Lasso desde el 96 ideada por el gran Robert Tibshirani).


Para finalizar, quiero indicar que el interés en compartir esta entrada es simplemente tratar de facilitar la vida a gente que esté trabajando con estas técnicas de CS con R por lo que estoy seguro de que hay realizaciones de este tipo, seguramente mejor montada que la que yo ofrezco, ya que esta es una idea muy natural que estoy seguro que ha sido muy explorada, aunque aquí la he sacado porque creo que más de uno es posible que no lo muy claro.

 
 
 

© 2021 by Francisco J. Rodríguez Aragón. Proudly created with Wix.com

bottom of page