FpML Issues Tracker
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.