FpML Issues Tracker

813: fx-10 only works on Day Periods.

September 12, 2008

closed

Minor

Always

Validation Rules

Admin

mgratacos

Summary

fx-10 is currently defined as:

" fx-10 (Mandatory) Context: FxAverageRateObservationSchedule (complex type) The observation period defined by observationStartDate and observationEndDate should be an integer multiple of the calculationPeriodFrequency. "

This calculation only makes sense where /FpML/trade/fxAverageRateOption/averageRateObservationSchedule/calculationPeriodFrequency/period is a day. It does not make sense to divide days by months, years, or anything else.

The additional guard required is given below: " fx-10 (Mandatory) Context: FxAverageRateObservationSchedule (complex type)[calculationPeriodFrequency/period = fpml:PeriodEnum('D')] The observation period defined by observationStartDate and observationEndDate should be an integer multiple of the calculationPeriodFrequency. "

The function fpml:PeriodEnum is the XPath function to construct an FpML PeriodEnum. The fpml namespace is needed because the Validation Rules set the default function namespace to be XPath 2, and this is in FpML not XPath2.

There is a second issue that the text used doesn't define the terms such as: "observation period" and "integer multiple". Rewriting the text using the FpML Specification for writing rules gives, including the FpML mathemtical notation gives:

" fx-10 (Mandatory) Context: FxAverageRateObservationSchedule (complex type)[calculationPeriodFrequency/period = fpml:PeriodEnum('D')] ((observationStartDate - observationEndDate) div xs:dayTimeDuration (concat('P', calculationPeriodFrequency/periodMultiplier, 'D'))) mod 1 eq 0 Comment: The duration between start and end of the periods must be an exact multiple of the period duration. "

Notes:

  • andrew

    09/16/08 5:55 pm

    The assertion that the observation calculation period frequency can only be days is incorrect.

    I found an example here (http://www.hsbcnet.com/treasury/foreign-exchange/fx-derivatives/average_rate_option_imp.html) in which the rate on the last business day of the month over a period on a year was used as the basis of the averaging.

    FpML can correctly represent this style of observation (e.g. start 31/1/2008, end 31/1/2009, calculation period 1 month, date roll preceding). If there is a problem in FpML it is that the observationSchedule is missing a set of business centers to accompany the the date roll convention.

  • lyteck

    09/16/08 7:35 pm

    Reviewed by Val WG on 16-SEP-2008: Agreed to raise this for discussion when Matthew Rawlings is on the call.

  • matthew

    09/16/08 8:38 pm

    “The assertion that the observation calculation period frequency can only be days is incorrect.” – where was this asserted? There is nothing in the issue about this.

    What the issue is about is that a value in days can only be divided by a duration also expressed in days. This doesn’t mean the duration can’t be expressed in something like years or months, it just means that you can’t do the check in those cases – it is a guard, not an assertion.

  • iyermakova

    12/12/08 4:48 pm

    Val WG agreed on 2008-12-09 to wait for the “financial date arithmetic paper”.

  • danieldui

    07/30/13 2:19 pm

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

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

  • rabad

    05/21/19 5:02 am

    Samples specified in the issue work properly. There is not any need to make changes. The rule work properly. Issues 813 and 814 can be closed.

  • mgratacos

    05/21/19 6:28 am

    Samples work fine and the financial date arithmetic paper addresses the issue.

  • Leave an update

    You must be logged in to post an update.