FpML Issues Tracker

Clearly the current description does not make sense (note, the verb “divide” has no object). Please refer to earlier expressions of the rule – as recently as FpML 4-4 the rule was described as follows:
The frequency specified in calculationPeriodFrequency must divide the regular period precisely. This means that by stepping through the period from the start date at the specified frequency, it must be possible to reach the end date.

Admittedly this definition is also imperfect, but stubs are dealt with in the definition of “regular period” where:
If firstRegularPeriodStartDate exists, then the start date is firstRegularPeriodStartDate, else the start date is effectiveDate/unadjustedDate. If lastRegularPeriodEndDate exists, then the end date is lastRegularPeriodEndDate, else the end date is terminationDate/unadjustedDate.

The sense of the natural language expression of this rule has been lost in translation across versions, with the unfortunate result that in the absence of an XPath expression (intrinsically hard to define for date schedules), no meaningful definition remains.

This reinforces the point I made on today’s VWG call: the natural language expression of the rule is not a second-class artifact – it is equally as important as the “formal” definition in XPath (provided one exists), and must be conserved with equal care.

Harry McAllister

The regular-period function currently reads is:

startDate has the value of (if exists($cpd/firstRegularPeriodStartDate) then $cpd/firstRegularPeriodStartDate else $cpd/effectiveDate/unadjustedDate). endDate has the value of (if (exists($cpd/lastRegularPeriodEndDate)) then data($cpd/lastRegularPeriodEndDate) else data($cpd/terminationDate/unadjustedDate))

I guess it should change as follows to use the data() syntax consistently.

startDate has the value of (if exists($cpd/firstRegularPeriodStartDate) then data($cpd/firstRegularPeriodStartDate) else data($cpd/effectiveDate/unadjustedDate)). endDate has the value of (if (exists($cpd/lastRegularPeriodEndDate)) then data($cpd/lastRegularPeriodEndDate) else data($cpd/terminationDate/unadjustedDate))

Email from Harry McAllister dated 19 July

On the subject of issue 1042: in the context of validation rules, the term “regular period” has been used (incorrectly) to mean a single duration between the InterestRateStream effective date (or firstRegularPeriodStartDate, if it exists) and the termination date (or lastRegularPeriodEndDate). This is inconsistent with the intended meaning of regular period e.g. firstRegularPeriodStartDate means “the start date of the first regular period”. Viewed this way, the stream comprises a schedule of regular periods, possibly with a stub (irregular) period at the start and/or end. The description of the relevant validation rules should be expressed accordingly.

In the case of ird-12, this means that the natural language description should state that: The frequency specified in calculationPeriodFrequency must divide the schedule of regular periods precisely.Perhaps we need to think of a better expression for “schedule of regular periods”?

Note that ird-12 is not universally true; it is invalidated by the specialised schedules used with the CNY 7-day repo rate (CNY-CNREPOFIX=CFXS-Reuters).

Swaps on the CNY 7-day Repo rate are an exception to this rule, because the index resets every 7 days whereas the floating leg pays interest compounded over 3 months. 7 days does not always divide evenly into 3 months, with the result that floating payment periods may not comprise a whole number of calculation periods (a residual ‘broken’ accrual period may appear at the end of the payment period). Hence the interval between the start- and end- dates is not necessarily a whole number of calculation periods, and rule ird-12 is invalidated.

Note:
(1) we may need to re-visit the definition of “regular period” for such cases
(2) ird-2 is also invalidated by these swaps

See IRDWG mail thread at: http://www.fpml.org/_wgmail/_irdwgmail/msg00564.html for recent discussion of issues related to this index.

Was a proposal submitted?

Reading from here: http://www.fpml.org/_wgmail/_irdwgmail/msg00562.html

Why would we need an extra element? The suggestion by Naz Quadri to add only a “CN7REPO” enum value for rollConvention in CalculationPeriodFrequency looks OK.

… but this is a matter for the IRD-WG.

Maybe we can just update the rule to exclude the case when floatingRateIndex=”CNY-CNREPOFIX=CFXS-Reuters”.

Update from Nov 8 call:

ACTION: Daniel to check with IRD-WD if schema change is being proposed.
ACTION: Daniel to write draft validation rule with guard condition.

Discussed on Jan 24 call. We’ll wait until Jan 31st for feedback from HMcA and then add the rule as suggested in the latest document.

implemented ird-12 as outlined in the word documented (see screenshot)