ResetFrequency more frequent than CalculationPeriod Frequency on InterestRateStream

[garyjkennedy]

Is there anywhere in the documentation that describes in detail the date generation associated with reset and fixing dates, perhaps similar to Andrew Jacobs document “Financial Date Calculations in FpML” I was looking at the case when reset frequency is more frequent than calculation period frequency, for example reset frequency=1M calculation period frequency=3M, and suppose ResetRelativeTo=CalculationPeriodStartDate Does one start with calculation period unadjusted start and end dates, generate unadjusted “sub calculation period” which is possible since validation rule ird-5 guarantees that “sub calculation periods” will fit evenly into the calculation period. Then focusing in the start date of the “sub calculation period”, adjust according to resetDateAdjustments, and finally determine fixing dates from the reset dates. Also, there is a vagueness in the documentation on resetFrequency, it says “If the reset frequency is greater than the calculation period frequency then this implies that more than one reset date is established for each calculation period and some form of rate averaging is applicable”, I wonder if there is somewhere else that can be more precise about the form of averaging? Finally, when determining the fixing date from the reset date (often 2 business days) is it assumed there fixing business centers are a subset of the reset date adjustment business centers as is often the case, I don’t see a validation rule on this? If it is not required, then suppose we have a reset date which is not a good day w.r.t to the fixing date business centers, and the fixing lag is 2 business days, does one start with the reset date adjust it (preceding) until we find a good fixing business day calendar, and then count 2 business days, or just count 2 business days from a non-business day. This is a boundary case which I think doesn’t happens in practice, however I am writing a date generator, so I wonder about these details.

[Author]

Posts