FpML Issues Tracker

842: ird-36 date arithmetic in days and weeks only

September 17, 2008

closed

Minor

Always

Validation Rules

Admin

danieldui

Summary

The problem with ird-36 is that it is currently undefined in how to do calculations that mix days and weeks.

The rule today is: " ird-36 (Mandatory) Context: PaymentDates (complex type) [exists(firstPaymentDate)] [exists(lastRegularPaymentDate)] The period defined by the dates firstPaymentDate and lastRegularPaymentDate must be an integer multiple of paymentFrequency. "

The problem is that one date minus another gives a duration in days. We need a specified convention to deal with all the types of payment frequencies that work against the schedule

Given two dates, and the duration between them we need to know how to compare that duration in days for payment frequences: * days * weeks * months * years

For example, given the dates 1/1/2007 and 31/1/2008 how do I compare this to: * 365 days * 52 weeks * 12 months * 1 year

Notes:

  • mgratacos

    10/21/08 1:47 pm

    Ask Daniel on status of this.

  • matthewdr

    10/21/08 1:48 pm

    Agreed at the VWG to add a definition as a function of how to do the calculation without guards. Agreed Marc Gratacos to ask Dan Dui for a definition.

  • h_mcallister

    10/27/08 10:24 pm

    This is only an “issue” if we (1) fail to take into account market conventions on date calculations (2) insist on a specific implementation of the validation rules.

    What the rule says is that we can move from firstPaymentDate to lastRegularPaymentDate in an integer multiple of steps equal to the paymentFrequency. Typically that frequency has units of months, so we use the conventions applied when adding a number of months to a date.

    Nowhere does the English expression of the rule imply that a date difference calculation (“one date minus another”) is required – it isn’t.

    It is up to the VWG to decide whether defining date calculation conventions is within its scope (a note on the topic might be a useful adjunct to the Standard), however I recommend that this issue (as currently expressed) should be rejected.

  • mgratacos

    11/18/08 2:25 pm

    AJ to present a paper describing calculation conventions.

  • mgratacos

    11/25/08 2:56 pm

    Agreed to adopt Matthew’s solution as technical description. AJ to add the English description.

  • h_mcallister

    12/03/08 10:38 am

    The proposed technical solution is not acceptable:
    (i) it attempts to address an issue which only arises from a particular (incorrect) implementation approach
    (ii) the additional guard excludes most of the cases where the rule might usefully apply

  • matthewdr

    12/03/08 2:26 pm

    Please propose a solution that covers all cases.

  • adingwal

    02/16/09 4:00 pm

  • h_mcallister

    02/23/09 6:30 pm

    In short, yes: the roll convention is implicit.

    First, note the schema annotation for firstPaymentDate and lastRegularPaymentDate which states, for both elements: “This date will normally correspond to an unadjusted calculation period start or end date.” This is enforced by rules ird-3 and ird-4.

    Next, note that paymentDates/payRelativeTo takes the value “CalculationPeriodEndDate”. Note also paymentDates/calculationPeriodDatesReference, whose href attribute points to the calculationPeriodDates component of the parent InterestRateStream.

    So the payment dates are linked to the period end dates of the schedule defined by calculationPeriodDates; and first- and lastRegular- PaymentDate correspond to unadjusted, regular period dates, which by definition are consistent with calculationPeriodDates/rollConvention.

    Note 1: ird-36 is automatically valid only in the case where payRelativeTo= CalculationPeriodEndDates. Since firstPaymentDate is produced only in the presence of an initial stub, then in the admittedly unusual case of upfront payment (i.e. payRelativeTo= CalculationPeriod*Start*Date), firstPaymentDate would correspond to the unadjusted effectiveDate (contravening ird-6, BTW). Then the period between firstPaymentDate and the following payment date would be irregular, and the period defined by firstPaymentDate and lastRegularPaymentDate would not be an integer multiple of paymentFrequency, so invalidating rule ird-36. It follows that the guard condition for the ird-36 should be refined to stipulate payRelativeTo=CalculationPeriodEndDate (and the same for ird-6).

    Note 2: This rule is relevant only to a small minority of swap trades having a stub period at both start and end. This is the only situation (that I can think of) where it is possible to make a statement about the relationship between some parametric dates in terms of the payment frequency (as opposed to the calculation period frequency) – however this doesn’t make the rule useful (IMO).

  • danieldui

    07/30/13 2:20 pm

    The “financial date arithmetic paper” should address the issue.

    Action for DD: to check and possibly close the issue.

  • mgratacos

    10/21/19 11:14 am

    Added the link to the Dates Calculation paper in the Definitions section of the Validation rules.

    The change will be published on version 5.11 Trial Recommendation.

  • Leave an update

    You must be logged in to post an update.