FpML Issues Tracker

636: cd-33 is an algorithm not a rule

March 3, 2008

closed

Minor

Always

Validation Rules

Admin

mgratacos

Summary

cd-33 is written partially in the form of an algorithm. It should be rewritten in the form of a rule (a constraint).

The rule today is: " Context: PeriodicPayment (complex type) cd-33 (Mandatory) If both firstPaymentDate and lastRegularPaymentDate are present, then lastRegularPaymentDate must fall precisely on a date reachable by adding an integer multiple of the period in paymentFrequency to firstPaymentDate. "

I propose the following rewrite: " Context: PeriodicPayment (complex type) cd-33 (Mandatory) If firstPaymentDate exists and lastRegularPaymentDate exits, then the duration resulting from lastRegularPaymentDate minus the firstPaymentDate, modulo by the paymentFrequency duration must be zero. "

This solves the problem except for where the Period Multiplier is a Term. /FpML/trade/creditDefaultSwap/feeLeg/periodicPayment/paymentFrequency/period["T"]

This then requires us to look at the Effective Date and Termination Date to know the Term, which requires the scope to come up a a few 'notches' on the Document. See issue #610 for a discussion of this. The problem is that there is no terminationDate on a CDS.

Notes:

  • matthewdr

    03/03/08 10:07 pm

    Section 4.6.2 of the manual states:

    “http://www.fpml.org/spec/fpml-4-4-4-wd-3/html/fpml-4-4-intro.html#s4.6.2
    The evaluation of dates in the validation rules is not trivial. The optionality of including time offsets in date datatypes makes comparisons between dates more difficult since sometimes the result is indeterminate as any ISO8601 date is +/- 18 hours of timezone, and +/- 24 hours of day.

    The Validation Working Group recommends the use of the XPath 2.0 date/time comparison rules which defines a definitive true / false value even for indeterminate calculations.

    The Validation Working Group recommends that time offsets appear on all date/time values used in FpML documents.”

    Rule cd-33 contradicts those statements. Subtracting one xs:date from another xs:date will result in an xs:dayTimeDuration. Determining the difference in months between two dates is undefined because people may not agree on the answer.

    For example, if the Period was “P3M” of type xs:duration of xs:yearMonthDuration it could not participate in arithmetic with an xs:dayTimeDuration, because the operands to the arithmetic operators would be of incompatible types.

  • mgratacos

    04/22/08 1:38 pm

    In CDS, the terminationDate is named scheduledTerminationDate. If the period is a Term, the scheduledTerminationDate will be present, otherwise the example wouldn’t make any business sense.

  • matthewdr

    04/29/08 1:31 pm

    Agreed to park this issue until Daniel’s proposal for issue #664 is received. The problem is it proved impossible to discuss this issue as some in the group were focused in there discussions on the separate issue #664.

  • mgratacos

    10/21/19 11:22 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.