ESTIMACIÓN DEL VALOR AÑADIDO APORTADO POR LOS MODELOS DE RIESGO DE CRÉDITO II

Como prometí voy con la segunda parte parte del anterior post, dejando en una tercera, como con R, sería factible hacer todo esto, eso sí, siempre y cuando se tenga la información preparada que por lo general (por no decir nunca, lo está).

Pues bien, el método anteriormente descrito, nos daba de un modo bastante prudente una estimación de los beneficios sin demasiada “inferencia estadística”, pero debido a sus limitaciones y a que consume, bastante información de la disponible, resulta preferible este segundo método que hace uso del concepto de curva de riesgos que va a permitir inferir la cantidad de información necesaria a partir de la existente:

Figura 1: Distribución de las tasas de riesgo en importe frente a la población acumulada

Nota: Hay borrones y eliminación de datos a propósito en la anterior figura

Con un poco más de dificultad, se puede trabajar con los rechazados por el modelo y por tanto cabe deducir una barra adicional justo delante de la primera donde se tiene:

• El número de transacciones (o clientes) rechazados por score

• La exposición de las transacciones

• E incluso el tipo de interés a nivel de transacción aplicado (si éste depende del producto, merchant, condiciones del cliente, etc)

El único dato que no se conoce va a resultar ser la tasa de riesgo en importe, es decir, al ser los anteriores clientes rechazados por el modelo, no se conoce si dichos clientes finalmente acaban pagando o no y cuánto dejarían de pagar exactamente, por esta última razón, para cada uno de los buckets observados el ratio que se calcula es:

A diferencia de lo mostrado en la figura anterior, el número buckets para este propósito suele ser mayor y no tienen por qué tener tasas de población similares (sobre todo si el modelo no es muy granular), por ese motivo, es conveniente definir un eje horizontal donde se tengan la tasa de exposición acumulada y un eje vertical con las tasas de riesgo (o risk rates). Además la curva anterior debe construirse recalculando todo el eje horizontal para tener en cuenta a los rechazados, por lo que se obtendrá el porcentaje de rechazo. En este caso, se estima la curva de riesgos sobre los buckets que se tienen datos y que dará una expresión del tipo:

Así pues se tendría inferido el dato final necesario que permitiría inferir el importe impagado en la zona desconocida.

Nótese que lo que se ha hecho ha sido una construcción similar a lo comentado en el anterior post pero desde otro punto de vista.

Figura 2 Esquema gráfico análogo al del anterior post

En este caso, se tiene el cutoff aplicado a la población mediante el modelo puesto en producción pero ¡Ojo! Yo siempre digo que: “los modelos no producen dinero, sino que lo producen quienes lo aplican”, en un modelo de riesgo, la producción de dinero, cuando el modelo es bueno, viene de su aplicación natural mediante el rechazo activo de los clientes que probablemente impagen.

Además del cutoff, se conoce toda la exposición antes y después de éste ya que en el momento de rechazo se ha intentado adquirir el producto financiero con su coste y en general (si no habría que estimarlo en función de lo conocido) se conoce también el ingreso que se habría obtenido de haberse contratado. Finalmente mediante la inferencia se va tener también el valor del impago que se habría producido de no haber aplicado el modelo por lo comentado anteriormente, por tanto se tiene toda la información necesaria de lo que se ha denominado Detection Zone que ahora cabría denominarse Rejection Zone. Así pues se tienen las siguientes cantidades:

Profits without Model = (Inferred Income + Income) – (Inferred Exposure at Default + Exposure at Default)

Profits with Model = Income – Exposure at Default

El valor por tanto que aportaría el modelo sería:

Model Add value = Profits with Model – Profits without Model = Inferred Income – Inferred Exposure at Default

Nótese que esta metodología, no es mucho más complicada que la anterior y tan sólo hay que añadir la estimación de la curva de riesgos y cabe seguirla periódicamente. Además al igual que en el anterior caso, también permitiría la comparación de modelos y también se observa que por lo general a mejores Ginis (o ROCs) para una misma cartera, mayor valor añadido por parte de los modelos utilizados.

Varios comentarios a todo esto:

• Model Add value no es más que la diferencia entre el ingreso que se habría obtenido por comisiones o fees al cliente (que pueden conocerse en muchos casos con precisión pero que en otras ocasiones deberá ser estimado) menos el riesgo que se habría evitado, este último número será mayor cuanto “más empinada” sea la curva, además es una función que dependerá de los siguientes elementos:

El nivel de demanda del producto (o número de transacciones)

La calidad en riesgo de la comentada demanda

El cutoff elegido

La política de precios

   El Gini o capacidad discriminante del modelo

• Nótese que si se sube el precio o las comisiones, manteniéndose todo lo demás constante, el Model Add value disminuiría y tiene su lógica porque las comisiones irían cubriendo los posibles riesgos que tendrían lugar y entonces o se consigue un modelo más eficiente o dicho valor cae (esto tiene bastantes connotaciones adicionales que no voy a comentar aquí)

• En esta metodología no están incluidos los siguientes costes:

Costes financieros: el principal es el tipo de interés del dinero que al menos va a ser el nivel euribor y en el caso de las financieras cabe esperar que sea ligeramente superior

   Costes operativos: en general hay reglas y variables externas que tienen un precio y que se paga por exposición aceptada e incluso rechazada

Costes de estructura: donde cabe al menos considerar el coste del personal implicado en generar y mantener el producto financiero

Todo lo anterior indica que si por ejemplo me compro un ordenador a plazos en Amazon por 1000 € a pagar durante un año ¿Cuánto me debe cobrar Amazon en términos de financiación de esta compra sabiendo que su tasa de impago es de un 3%? Pues por lo pronto tendrá que tomar dinero prestado para financiar el producto seguramente al 4% si consigue un “precio amigo” dado que actualmente el euribor está al 3.5%, aparte hará consultas a bureau de crédito y otros agentes que podrá suponer en el mejor de los casos unos 10€ lo que añade un 1% (o algo más) a todo y finalmente el coste de mantener a un personal que haga la gestión, que gestione el dato, que plantee un plan de recobro en caso de impago, etc. Por tanto al menos

entre un 8% - 10% para no incurrir en pérdidas. Actualmente, para este tipo de

compras la TAE de Amazon ronda el 13% como se observa a continuación:

• Lo anterior hace que, aunque en general es rentable tener modelos, hay que seguir su evolución a nivel de poder discriminante y de valor añadido con períodos de tiempo lo más cortos pero a la vez, lo más representativos posible

Figura 3: Tabla de seguimiento de la eficiencia de una cartera de pago aplazado a 3 meses con algunas columnas relevantes (ac significa after cutoff y bc before cutoff)

Nota: (1) Hay borrones y eliminación de datos a propósito en la anterior figura

            (2) Nótese que Global Profits sería Profits without model y Profits ac sería Profits with model

Para finalizar, cabe comentar que mientras el método del post anterior es útil para analizar variaciones en la política de riesgo al crear escenarios por variación del cutoff, este método es menos restrictivo si bien es cierto que la inferencia realizada con la curva de riesgos será muy imprecisa en modelos malos y en estos casos, donde no se sea capaz de discriminar adecuadamente el riesgo, las tasas de la región de rechazo serán por lo general las tasas medias, lo que también tiene sentido que sea así, ya que para esos casos se tendría una curva plana.

Estimación del valor añadido aportado por los modelos de Riesgo de Crédito I

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.

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:

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

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

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:

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:

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:

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):

Puestas en producción sencillas para vagos en R

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):

https://manage.wix.com/dashboard/41f0e522-6283-4f4d-a1c5-ac229e76a383/blog/256b426a-acc4-4e0a-ba6f-afb8fd968965/edit?referralInfo=sidebar

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:

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:

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:

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:

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:

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.