Date generation rule CDS2015 only works for multiples of 6M

[francisduffy]

There is documentation on the rule DateGeneration::CDS2015 given here. The document at that link is attached here also. The document has a table in section 11 describing the maturity dates of CDS with given tenors for valuation dates in six different periods using the CDS 2015 rule. If we use the code snippet below to generate this table using QuantLib, we get the table in the attached Excel workbook. The rule works for periods that are multiples of 6 months. However, the rule does not give the expected result for periods 3M, 9M, 15M, etc.

Before I start working on a fix for this, is there agreement that this is an issue and needs to be fixed or am I missing something?

The code crashes if a tenor of 0M is included but having this working with CDS2015 is more of a nice to have and could be treated as a separate issue of lesser importance.

#include <ql/termstructures/credit/defaultprobabilityhelpers.hpp>
#include <ql/termstructures/yield/flatforward.cpp>
#include <ql/time/calendars/weekendsonly.hpp>
#include <ql/time/calendars/unitedstates.hpp>
#include <ql/time/daycounters/actual360.hpp>
#include <ql/time/daycounters/actual365fixed.hpp>
#include <iostream>

using namespace QuantLib;
using namespace std;

#ifdef BOOST_MSVC
#include <ql/auto_link.hpp>
#endif

// Check CDS2015 rule against table:
// https://www.isda.org//2015/12/10/updated-faq-amend-single-name-on-the-run-frequency
int main(int argc, char** argv) {

    // Valuation dates that we wish to test
    vector<Date> dates = {
        Date(21, Sep, 2015),
        Date(21, Dec, 2015),
        Date(21, Mar, 2016),
        Date(21, Jun, 2016),
        Date(21, Sep, 2016),
        Date(21, Dec, 2016)
    };

    // CDS tenors that we wish to test
    vector<Period> tenors = {
        // 0 * Months,
        3 * Months,
        6 * Months,
        9 * Months,
        1 * Years,
        15 * Months,
        18 * Months,
        21 * Months,
        2 * Years,
        27 * Months,
        30 * Months,
        33 * Months,
        3 * Years,
        39 * Months,
        42 * Months,
        45 * Months,
        4 * Years,
        51 * Months,
        54 * Months,
        57 * Months,
        5 * Years
    };

    for (const auto& date : dates) {

        // Set the evaluation date to the date of interst
        Settings::instance().evaluationDate() = date;

        // Dummy yield term structure
        Handle<YieldTermStructure> yts(
            boost::make_shared<FlatForward>(0, NullCalendar(), 0.01, Actual365Fixed()));

        for (const auto& tenor : tenors) {
            
            // Create a CDS helper
            // Use NullCalendar here to compare with document. Should be WeekendsOnly.
            auto cdsHelper = boost::make_shared<SpreadCdsHelper>(0.0001, tenor, 1, NullCalendar(), Quarterly,
                Following, DateGeneration::CDS2015, Actual360(), 0.04, yts, true, true, Date(), Actual360(true));

            // Write out the maturity date of the CDS
            cout <<  tenor << "," << io::iso_date(date) << "," << io::iso_date(cdsHelper->latestDate()) << endl;
        }
    }

    return 0;
}

2015_isda_amend-single-name-on-the-run-frequency-faq-revised-as-of-12-10.pdf

compare_expected.xlsx

[thrasibule]

I guess there is a bug indeed. When i submitted the CDS2015 date generation convention, I didn't check with non yearly maturities, I didn't know these existed, but it makes sense to match with the official ISDA guidelines.

[benacook]

is this unit test still valid if the bug is fixed? specifically the end date.

Schedule s3 =  
        MakeSchedule().from(Date(20, March, 2017))  
                      .to(Date(20, March, 2017) + Period(5, Years))  
                     .withCalendar(WeekendsOnly())  
                      .withTenor(3*Months)  
                      .withConvention(ModifiedFollowing)  
                      .withTerminationDateConvention(Unadjusted)  
                      .withRule(DateGeneration::CDS2015);  
    BOOST_CHECK(s3.startDate() == Date(20, March, 2017));  
    BOOST_CHECK(s3.endDate() == Date(20, June, 2022));

from QuantLib\test-suite\schedule.cpp line 272

[francisduffy]

is this unit test still valid if the bug is fixed? specifically the end date.

Schedule s3 =  
        MakeSchedule().from(Date(20, March, 2017))  
                      .to(Date(20, March, 2017) + Period(5, Years))  
                     .withCalendar(WeekendsOnly())  
                      .withTenor(3*Months)  
                      .withConvention(ModifiedFollowing)  
                      .withTerminationDateConvention(Unadjusted)  
                      .withRule(DateGeneration::CDS2015);  
    BOOST_CHECK(s3.startDate() == Date(20, March, 2017));  
    BOOST_CHECK(s3.endDate() == Date(20, June, 2022));

from QuantLib\test-suite\schedule.cpp line 272

@benacook I am only getting back to look at this issue now. Yes this unit test should still pass. I have kept it in the branch that I am working on, in commit 72c6064, along with some other tests. I hope to make a pull request from this branch but I need to check a few other downstream items i.e. CDS instrument, helper and engines before doing this.