The maturity date of a CDS contract is unadjusted and included in the last coupon period. The FixedRateCoupon doesn't differentiate the last coupon period from the rest.
For example, a quarterly paying 1-year CDS contract on Sept 30, 2014 maturing on Dec 20th, 2015 have the following cash flow from FixedRateCoupon. The last period is missing a day.
| Payment Date | Accural Start | Accrual End | Accrual Days |
| December 22nd, 2014 | September 30th, 2014 | December 22nd, 2014 | 83 |
| March 20th, 2015 | December 22nd, 2014 | March 20th, 2015 | 88 |
| June 22nd, 2015 | March 20th, 2015 | June 22nd, 2015 | 94 |
| September 21st, 2015 | June 22nd, 2015 | September 21st, 2015 | 91 |
| December 21st, 2015 | September 21st, 2015 | December 20th, 2015 | 90 |
I used following to create the schedule for CreditDefaultSwap:
Schedule cdsSchedule =
MakeSchedule().from(effectiveDate).to(maturityDate)
.withFrequency(Quarterly)
.withCalendar(calendar)
.withConvention(Following)
.withTerminationDateConvention(Unadjusted)
.withNextToLastDate(maturityDate);
Please advice if QuantLib has a special handling on CreditDefaultSwap cash flow generation that I'm missing.
What do you mean when you say that "the last period is missing a day"? Should the dates be different, or should an additional day be counted for the same dates?
the last period should be 91 days.
12/20/2015 - 9/21/2015 + 1 = 91
Ok. The day-count convention is act/360, right? So it's just a matter of adding one day and there won't be any other strange calculations going on?
That's all. Adding 1 day to last period with terminating date unadjusted. I don't think it matters what day count it is.
As I mentioned on Github, can you please check pcaspers branch 'CDS' to check you agree with what is done there? The aim of the branch is to replicate the ISDA standard engine and this point among others is dealt with there.
Thank you
This should now be fixed by the work on the ISDA engine.