Arquitectura de una biblioteca de precios globales con pagos inmutables

Question

Por biblioteca de precios globales me refiero a una biblioteca

• gestión de los recursos propios, de los tipos, etc., de los productos híbridos
• con varios modelos (BS, LV, SV, LSV)
• disponer de varios métodos numéricos (fórmula analítica, MC, PDE FD/FE)

Nunca he tenido que diseñar una biblioteca de precios global, sólo he tenido que escribir bibliotecas de precios aisladas de MC o PDE FD, con BS, LV y SV principalmente, en un entorno puramente de front office, por lo que tenía bastante libertad para el modelado y el diseño. En estos casos siempre utilicé la siguiente arquitectura (en el caso de un MC de juguete) :

• a Product tiene una (referencia a) PayOff
• a PayOff tiene un Model y un ComputePayOff método que calcula la retribución en un camino generado por el modelo
• a Model tiene un RandomNumberGenerator y un GenerateMCPath que genera una ruta MC con fechas dadas con el generador aleatorio dado

PayOff es abstracto, así como Model y RandomNumberGenerator Aunque siempre he tenido problemas para evitar el aumento exponencial de subclases debido a la funcionalidad transversal, ya que no soy un experto en patrones de diseño (¿puente?).

De modo que PayOff tiene mucha información "no inmutable". Por ejemplo, si mi RandomNumberGenerator es un Sobol, puede tener un miembro que cambia después de generar el número aleatorio, de modo que después de un precio, PayOff tiene una información que ha cambiado. Nunca me preocupé por eso.

Ahora, tengo la tarea de diseñar un poc para una biblioteca de precios global, con la restricción de que Product y PayOff no deben cambiar (van a ser (des)serializados). Podría, por supuesto, con un montón de contorsiones, seguir haciendo como en el juguete-ejemplo anterior, pero estaría mal.

Sin embargo, después de pensar, algunas cosas no cambian: efectivamente quiero tener tres categorías de "objetos" :

• productos (o pagos para simplificar)
• modelos
• métodos numéricos

y estas categorías pueden cruzarse, por ejemplo:

• la intersección de los pagos europeos, el modelo BS y las fórmulas cerradas (un tipo especial de método numérico) da como resultado la fórmula BS
• la intersección de los pagos europeos y el modelo de Heston produce como métodos numéricos fórmulas cerradas, PDE FD2D o MC

etc. De hecho, la biblioteca necesita procesar un pago dado bajo un modelo dado, utilizando un método numérico dado, teniendo en cuenta que no puede ponerle precio a todo en cualquier modelo y con cualquier método numérico...

¿Existe una forma clásica de diseñar esto? Como no tengo la intención de reinventar la rueda necesariamente, miré QuantLib y Strata hasta ahora, pero ambos tienen "pagos" no inmutables.

Answer 1

Esa es la mejor pregunta que casi nadie hace. Estoy contigo en lo de Quantlib y Strata, realmente no he visto un diseño muy bueno por ahí pero he visto bastantes malos. Es definitivamente factible y tiene grandes ventajas en términos de pruebas, mantenimiento, escalabilidad. La regla de oro es que tus objetos deben corresponder a conceptos.

El problema central (en los malos diseños) es que el Payoff tiene un modelo o motor de precios, etc. Conceptualmente el payoff es simplemente una traducción de la parte de cálculo de una hoja de términos. Cualquier cosa que se añada encima será simplemente demasiado y no será un diseño limpio. La funcionalidad de Payoff se resume a calcular cantidades de flujo de caja dados los precios de los subyacentes. Puede tener funciones de obtención para fechas, tipos de eventos (barreras), niveles clave (huelga), etc., por supuesto.

Un motor de precios conoce los pagos, no al revés. Además de los pagos, necesita uno o más mercados y algunos parámetros del modelo. Internamente, el motor de precios crea un modelo a partir de los objetos del mercado (para obtener la deriva, el vol, etc.) y los parámetros del modelo. El motor de precios puede ser analítico o numérico. El analítico es sencillo. Un motor de precios numérico necesita producir el calendario de fechas para el cálculo basado en el conjunto de Pagos que tiene que valorar. También necesita recoger una representación de todos los cálculos necesarios. Si quieres eficiencia entonces quieres descomponer cada payoff en componentes más pequeños que describan los cálculos básicos como promedios, digitales, etc. Puedes tener motores basados en PDE(FD) o en MC.

Un motor de precios basado en FD combinará el Modelo y el Método Numérico(FD) para resolver una EDP con condiciones de contorno. La clase PricingPDE modela el habitual PDE de precios hacia atrás más un método postStep() para realizar los cálculos de Payoff. El motor FD en sí mismo no sabe de precios. Simplemente está resolviendo una EDP con condiciones de contorno. Toda referencia a la "fijación de precios" está en la clase PricingPDE. El mismo motor FD puede utilizarse para la calibración o, por qué no, para resolver la ecuación básica del calor.

Lo mismo ocurre con un motor MonteCarlo.

Answer 2

Los pagos pueden desglosarse en flujos de caja reales impulsados por variables subyacentes (calculados a partir de activos/tipos simulados, etc.). Además, habría una lista de características, como barreras, posibilidad de rescate, ejercicio anticipado, etcétera. El motor debe tener en cuenta todas estas características de la retribución y, si no puede, significa que la retribución no puede valorarse. En cuanto a los modelos, si un modelo puede simular todas las variables subyacentes y los factores desencadenantes de las características, entonces puede utilizarse para fijar el precio de esa retribución. Si es el modelo adecuado en el sentido de que cubre o no todos los factores que pueden influir en el precio, eso hay que decidirlo de antemano. Por ejemplo, fijar el precio de un cliquet con vol locales sería posible, pero no la forma de hacerlo cuando se negocian.