FpML Issues Tracker
closed
Minor
Always
Validation Rules
Admin
None
Summary
" (Mandatory) Preconditions: isParametric paymentDates/firstPaymentDate > calculationPeriodDates/effectiveDate/unadjustedDate. "
The problem is that some swapStreams had calculationPeriodDates/relativeEffectiveDate. How do I interpret this rule under that scenarios?
Should the rule be refined to cope with relativeEffectiveDate, or is this an additional precondition and a new rule?
Notes:
matthew
03/27/08 9:52 pm
Assigning to VWG and PF-W, as it is a Validation issue.
h_mcallister
07/15/08 2:15 pm
In answer to Pam’s query (“Should the rule be refined to cope with relativeEffectiveDate …?”), the rule could be evaluated by applying the specifed offset to the “anchor” date (the date referenced by dateRelativeTo), and comparing the result with firstPaymentDate.
However, there is no consistent scenario where the effective date is expressed as a relative date in association with an explicit firstPaymentDate, and this situation should be excluded from consideration, perhaps by applying an appropriate precondition e.g. exists(effectiveDate)
matthewdr
12/09/08 3:00 pm
Harry, please can you write out the solution for the VWG. We discussed the comments at the VWG today and were unsure.
matthewdr
12/09/08 3:01 pm
Agreed a the VWG to implement:
”
(Mandatory)
Preconditions: exists(effectiveDate)
paymentDates/firstPaymentDate > calculationPeriodDates/effectiveDate/unadjustedDate.
”
lyteck
12/10/08 9:07 pm
I think ird-6, as solved in 614, is already correct (and has more complete guards) – not making further changes. Please advise.
“ird-6 (Mandatory)
Context: InterestRateStream (complex type)
Formal Description:
[exists(paymentDates/firstPaymentDate)]
[exists(calculationPeriodDates/effectiveDate)]
paymentDates/firstPaymentDate gt calculationPeriodDates/effectiveDate/unadjustedDate
matthewdr
12/11/08 8:13 am
Closing as the resolution to #614 also solved this.