FpML Issues Tracker
closed
Major
Always
Validation Rules
Admin
None
Summary
Following the last VWG Pam asked me to raise an issue for this. The question had already been put to Harry, who may respond.
FpML defines an Interval using a period of type PeriodEnum. One of the values of PeriodEnum is "T", which is short for "Term". When I see the Interval contains a Term period I don't know which Term it is. There are many dozens uses of Interval or a descendant-type of Interval in FpML.
An example is Exercise Period, from the IRD part of FpML.
ExercisePeriod contains two elements of type Interval. These each contain a period that may be a Term. When the period is a Term, which Term is it? How would I know?
There are many users of this PeriodEnum. I would need an answer that works for every use in FpML.
Notes:
matthewdr
01/28/09 9:28 pm
The VWG discussed either adding a hard rule to the schema, so you always knew which Term it was; or instead adding an IDREF to a specific Term.
matthew
02/02/09 7:12 pm
There was a long and thorough discussion between Harry, Marc, and Matthew at the end of the Coord Committee meeting today. What we agreed is that for every context in which there may be an Interval of Term that the definition of which term it was must be provided in the schema definition.
We agreed that for each WG a separate issue would be raised so the tracking of contexts would be by WG. This issue would act as the parent issue.
mgratacos
02/03/09 11:06 am
Hi Matthew,
I’ll start at the end; your mail closes with the compound question: When the period is a Term, which Term is it? How would I know?
Let’s refer to the annotation for the “T” member of PeriodEnum:
Term. The period commencing on the effective date and ending on the termination date. The T period always appears in association with periodMultiplier = 1, and the notation is intended for use in contexts where the interval thus qualified (e.g. accrual period, payment period, reset period, …) spans the entire term of the trade.
The term is construed as the period between an effective and a termination date – the identity of these dates is implied by the context, so if the context is an instance of InterestRateStream, the Term is the interval between calculationPeriodDates/effectiveDate/unadjustedDate and calculationPeriodDates/terminationDate/unadjustedDate. This immediately raises the question of how to construe “Term” where the context does not contain an “effective” or “termination” date. Without verifying the hypothesis, I’d suggest that it is possible to identify date elements which serve the roles of “effective” and “termination” date in any context where “1T” is meaningful.
The example of ExercisePeriod is instructive because it illustrates the subtly different usages of Interval; earliestExerciseDateTenor is an example of Interval-as-Duration – it describes an offset (time interval to the start of the exercise period), so “T” is not an appropriate value of period in this context. However exerciseFrequency describes a recurring time interval – it is an example of Interval-as-Frequency, so period might take the value “T”, meaning once in the whole term of the trade (although this would not make business sense in the context of ExercisePeriod); note that periodMultiplier is strictly positive in this usage.
In summary:
period = T is not meaningful, in business terms, in the context of ExercisePeriod.
if it did have a legitimate usage (only in the context Interval-as-Frequency), the meaning would be “the term of the related InterestRateStream” (however that relationship is construed)
for legitimate usages, the Term can be construed from context (a frequency, within an InterestRateStream having effective- and termination-Dates)
I don’t subscribe to the idea of replacing “T” with a reference to dates; the idiom is well understood within the IRD community – changing the protocol would impose an unacceptable implementation penalty on message consumers, for zero business benefit.
However, I’m sympathetic to the idea of re-factoring the schema to distinguish between the uses of Interval-as-Frequency and Interval-as-Duration (or Offset), and proposed this recently in response to issue #642 (see http://www.fpml.org/issues/view.php?id=642, notes #1547 & #1556):
the “Frequency” type permits “T” as a value of period; Duration does not (there may also be some “Frequency” contexts where “T” is not legitimate)
Frequency/periodMultiplier is a strictly positive integer; Duration/periodMultiplier may be positive, negative, or zero.
Best regards,
Harry McAllister
Fixed Income Architecture
BNP Paribas
Internet
Matthew Rawlings
28/01/2009 11:52
To Harry MCALLISTER
cc Marc Gratacos, mark addison
Subject working out which Term the PeriodEnum refers to
Hi Harry –
I am working on implementing the FpML date rules. There is just one last big issue left that I don’t understand. The VWG couldn’t help either. I am hoping you can explain it to me.
FpML defines an Interval using a period of type PeriodEnum. One of the values of PeriodEnum is “T”, which is short for “Term”. When I see the Interval contains a Term period I don’t know which Term it is. There are many dozens uses of Interval or a descendant-type of Interval in FpML.
An example is Exercise Period, from the IRD part of FpML.
ExercisePeriod contains two elements of type Interval. These each contain a period that may be a Term. When the period is a Term, which Term is it? How would I know?
Regards –
Matthew Rawlings
matthewdr
04/07/09 1:27 pm
Agreed at the VWG that Irina will produce a list of all uses of “T” for the VWG.
matthewdr
07/28/09 1:10 pm
Attached Marc Gratacos’ spreadsheet to split the enumerations and the proposed new enumerations.
matthewdr
07/28/09 1:11 pm
Discussed at VWG. We agreed to wait for further feedback from the Coordination Committee to confirm Marc’s proposal.
mgratacos
10/14/09 8:50 am
The first working draft for version 4.7 http://www.fpml.org/spec/fpml-4-7-1-wd-1/ has implemented the PeriodEnum proposal:
* Split the PeriodEnum enumeration into two separate enumerations, one containing the value ‘T’ for Term, named PeriodExtendedEnum, and another without the value ‘T’, named PeriodEnum.
* Replaced the Interval complex type by two new complex types: Frequency and Period. Period contains a period element of type PeriodEnum while Frequency contains a period element of type PeriodExtendedEnum.
* Elements of type Interval are now of type Frequency or type Period depending on the applicable business values.
Best Regards,
Marc
matthew
10/14/09 9:08 pm
Very good news. Thank you.