Problema con el cronograma de cupones con la fecha inicial del cupón

Question

Estoy tratando de hacer coincidir el interés devengado, el precio limpio, el precio sucio y la duración de los datos subyacentes de iBoxx. He llegado casi a igualar perfectamente sus medidas pero me he encontrado con un caso límite en el que no estoy seguro de cómo abordarlo mejor.

Tengo un bono emitido el 2017-11-09 con una fecha de inicio de devengo de intereses el 2017-11-14 y una fecha de vencimiento el 2024-11-15. Cuando creo el objeto Schedule como se muestra a continuación:

# Crear schedule
    Schedule = ql.Schedule(FechaInicio, 
                            FechaVencimiento,
                            ql.Period(FrecuenciaCupon),
                            Calendario,
                            ql.Unadjusted, 
                            ql.ModifiedFollowing,
                            ql.DateGeneration.Backward, 
                            False)

Obtengo la siguiente salida cuando llamo a

list(Schedule)

Obtengo

[Date(14,11,2017), Date(15,11,2017), Date(15,5,2018), Date(15,11,2018), Date(15,5,2019), Date(15,11,2019), Date(15,5,2020), Date(15,11,2020), Date(15,5,2021), Date(15,11,2021), Date(15,5,2022), Date(15,11,2022), Date(15,5,2023), Date(15,11,2023), Date(15,5,2024), Date(15,11,2024)]

Como se puede ver en las primeras dos entradas, tenemos la fecha de inicio de devengo de intereses y luego una fecha de cupón al día siguiente (en la fecha semestral asociada con la fecha de vencimiento).

Mi pregunta es: ¿debería resetearse el devengo de intereses el 2017-11-15? Para referencia el cusip es 911312BL9. Encontré la siguiente información a través de FactSet que la fecha inicial de cupón es de hecho el 2018-05-15. Por lo tanto, parece que la forma en que he construido mi Schedule es incorrecta. Sin embargo, no estoy seguro de cómo ajustar mi código en Python. La diferencia entre mi salida y la de iBoxx desaparece después del 2018-05-15 lo que indica que están contabilizando correctamente el hecho de que el devengo de intereses no se reinicia el 2017-11-15.

Answer 1

A veces un periodo de cupón es largo y a veces es corto. En tu ejemplo, es posible, pero poco probable, que el primer periodo de cupón solo tenga una duración de 5 días. Es más probable, pero no seguro, que el primer periodo de cupón tenga una duración de 5 días más que un periodo regular. Es una práctica extremadamente mala y peligrosa tratar de adivinar programáticamente cuál es, porque a veces tu suposición será incorrecta. En su lugar, debes obtener la primera fecha de cupón como parte de los datos indicativos de tu instrumento y pasarla al constructor programador. En Python Quantlib, la primera fecha de cupón es el siguiente argumento posicional a ql.Schedule después de EndOfMonth=False

Las fechas deberían estar en el prospecto del bono. Si obtienes los datos indicativos del bono de un proveedor de datos como Bloomberg, debería haber un campo para ello, pero deberías verificarlo - los proveedores de datos a veces fallan.

Tu comentario menciona la Base de Datos de Valores de Renta Fija de Mergent (FISD) de FTSE Russel Mergent https://www.mergentonline.com/. Personalmente nunca la he usado. La descripción de la base de datos es la siguiente:

La base de datos, diseñada para la academia, contiene detalles de emisiones sobre más de 140,000 valores de deuda corporativa, deuda corporativa MTN (nota de mediano plazo), deuda supranacional, de agencias de EE. UU. y de tesoros de EE. UU. e incluye más de 550 elementos de datos. Mergent FISD proporciona detalles sobre emisiones de deuda y los emisores, así como transacciones realizadas por compañías de seguros.

A veces el horario completo es tan especializado que no se puede recrear utilizando un programador automático, y entonces debes pasar la lista completa de fechas como un horario personalizado. Este ejemplo no parece tan complicado como para necesitar eso. US911312BL96 parece ser un bono corporativo bastante estándar de United Parcel Service.

Mi experiencia típica con bonos de mercados más exóticos y emergentes y los datos indicativos de Bloomberg ha sido:

• se emite un bono

• Los analistas de Bloomberg en un lugar de bajo costo extraen los datos indicativos y los vuelven a escribir en sus bases de datos, a menudo con errores en el primer intento

• muchos clientes de Bloomberg revisan los datos indicativos en Bloomberg, encuentran errores y suelen informar a soporte de Bloomberg (F1 F1) cuando lo hacen

• Bloomberg finalmente corrige sus datos indicativos

Como resultado, Bloomberg es efectivamente una fuente colaborativa, y por lo tanto generalmente correcta, aunque para bonos emitidos recientemente debes tener cuidado con los errores de datos.