FpML - Financial products Markup Language - ISSUES

0000984: Unused isFloating and hasInitialStub in IRD rules

The IRD rules define two conditions: isFloating and hasInitialStub, but they are not used in the rules themselves.

I am looking at FpML 4.6.4 LCWD-1.

For example, I suggest to change rule ird-59 from:

XPath Description:
Context: InterestRateStream (complex type)
[exists(resetDates)]
id(resetDates/calculationPeriodDatesReference/@href) is calculationPeriodDates

to:

XPath Description:
Context: InterestRateStream (complex type)
[isFloating]
id(resetDates/calculationPeriodDatesReference/@href) is calculationPeriodDates

All rules should be looked at to see if similar changes are necessary.

0001017: shared-27 should it be kept? modified?

shared-27 currently reads as follows:

Context: Document (complex type)
All timezones must be the same. +00:00, -00:00, and Z are considered equivalent.

Comment: This rule ensures that date and datetime comparisons behave as expected because they're expressed in the same timezone. NB That the XSD specification uses the term "timezone", but that they are not really timezones as they are fixed durations to represent time offsets. Subsequent to publishing XSD the W3C changed its position to clarify this: http://www.w3.org/TR/2005/NOTE-timezone-20051013/#d2e226.

Andrew J noted that imposing all the dates in an instance document to use the same timezone may be too restrictive.

Should this rule be be changed to allow the use of multiple timezones in the same document?

0001018: Should dates indicate the timezone when also businessCenter is present?

When Andrew J raised the related issue about time zones, Tony Coates noted that perhaps the timezone should not be indicated in a date when also businessCenter is present.

0000942: CD Conditions

The Credit Derivatives "Conditions" are derived values added to new Nodes (elements and attributes) defined by the condition.

For example:
"
Condition: ISDA1999Credit
(context: Trade) (context: Contract) At least one of documentation/contractualDefinition element and documentation/masterConfirmation/masterConfirmationType element exists and contains the string "ISDA1999Credit".

Formal description: some $document in (//element(*, Trade) | //element(*, Contract))/documentation/(contractualDefinitions | masterConfirmation/masterConfirmationType) satisfies contains($document, "ISDA1999Credit")
"

This defines a new Node named "ISDA1999Credit" on every Trade and Contract type. It provides a derivation rule, which is included in the description.

We added a lot of clarity by adding the contexts to these definitions. Making this change was a very good thing.

There is a problem with the first two sentences: "The Validation Conditions only apply when specific rules reference them. The following conditions are always to be executed relative to the root of the FpML document being validated."

#1 The first issue is the second sentence contradicts the Context given in the definition of the Condition. I suggest it be corrected or struck out.

#2 The second issue is the first sentence is a nonsense as it seems to be trying to control the application of rules. When we validate with the validation rules, all the rules apply each time. It is the contexts which determine which rules 'fire', nothing else. I suggest this is struck out.

#3 The third issue is how do we refer to these conditions in the rules referencing them? So far we have used $ISDA1999Credit to refer to the first condition, as if it was an XPath variable. The problem with this approach is that it only works if each condition appears once. As each condition appears once per Context, and the context appears many times then we need a way to distinguish between all the different $ISDA1999Credit. I suggest that for each Conditions context we define a name, a datatype and treat it as a derived element or attribute on the context. That way when I have a Valuation with hundreds of trades the rules still work. At the moment the rules break when there is more than one trade in a message.

"
Name: isda1999Credit
Node: element

English Description:
Context: Trade (complex type), Contract (complex type)
Derivation rule: At least one of documentation/contractualDefinition element and documentation/masterConfirmation/masterConfirmationType element exists and contains the string "ISDA1999Credit".

XPath description:
Context: //element(*, Trade), //element(*, Contract)
Derivation rule: some $document in documentation/(contractualDefinitions | masterConfirmation/masterConfirmationType) satisfies contains($document, "ISDA1999Credit")
"

0000004 They are currently named conditions. I suggest they are named "Definitions" and placed in the rules-functions.xml file, as they are not defined to be specific to CDS.

In summary, these conditions need to be changed so they work when there is more than one Trade or Contract in a message.

0000999: commodity-reference-price-1-0.xml et al Code values are strings - not codes

The values used in commodity-reference-price-1-0.xml for Codes use a string and not a code value: e.g. "COCOA-GBP-EURONEXT LIFFE" and "BENZENE-CONTRACT BENZENE (FOB USGC/GAL)-GALLON-B&D"

Ditto:
floating-rate-index-2-1.xml: "CAD-ISDA-Swap Rate"
commodity-business-calendar-2-2.xml: "BM&F"
- possibly others.

Is there a technical justification for departure from a Code? I can see our internal infrastructure needing major surgery to cater for this.

Is there a characterset definition for code values? We had assumed Codes were limited to a-z, A-Z,0-9,-

--Steve

0000979: invalid examples for new shared rules

Please add at least one invalid example for the new shared rules:

shared-18
shared-19
shared-20
shared-21
shared-22
shared-23
shared-24
shared-25
shared-26
shared-27
shared-27

Currently these rules have no examples.

0001016: basketAmount

FpML supports Basket Amount, yet we can't find this in the ISDA 2002 Equity Master Definitions, nor in the ISDA Confirmations templates.

We have never seen this in ISDA documentation or otherwise, we weight on basket percentage ( relative weight ) or open units ( absolute weight ), both of which are stable expression.

We propose the Basket Amount to be deprecated and removed in the next major version.

0001015: Update of rules affected by equity option multiple exercise document

The rules concerning equity option multiple exercise need to be updated according to the content of the document that the EQD WG has produced.

TODO:
- Identify rules
- Propose updated version
- Review internally and with EQD WG

0001013: 5.0 Reporting View Validation Rules

The following validation rules were removed from Confirmation View and will be added to the Reporting View once the validation rules for Reporting View are created:
- ref-14, ref-15, ref-16, ref-17 – in reconciliation
- ref-18 – in mktenv
- ref- 19, ref-22, ref-23, ref-24, ref-36 - in valuation and riskdef
- ref- 20, ref-21 - in riskdef
- ref- 31 - in mktenv and riskdef
- ref- 37- in valuation, mktenv and riskdef

0001012: The 5-x Confirmation View Validation rules ref-10, ref-30, ref-32 need new invalid test-cases

The 5-x Confirmation View Validation rules ref-10, ref-30, ref-32 need new invalid test cases:
the existing invalid cases have the following issues:
- invalid-ref-10-01 (currently used in requestValuationReport message)
- invalid-ref-30-01 (currently used in valuationDocument message)
- invalid-ref-32-01 (currently used in fx product )

0000933: rules documentation files invalid against the XSD

The rules documentation files are invalid against the XSD.

rules-english-ref.xml contains:
"

%fpml.version.entities;
]>

"

The attribute /rules/@name is not in the XML Schema. There are many other nodes node in the XML Schema.

...
...

Please make the rules documentation valid against the XSD.

0001008: Element appears to have the wrong type

In the complex type 'FormulaTerm' the element 'partialDerivativeReference' is of type 'PricingParameterDerivativeReference' whilst in the type 'WeightedPartialDerivative' the same element name has type 'PricingStructureReference'.

Either the type is wrong or the element is misnamed in the second case.

Have not checked previous version to see how long this inconsistency has existed.

0000549: FXLeg is not a kind of product

The FpML schema states that FxLeg is a kind of Product.

A type that represents a single exchange of one currency for another. This is used for representing FX spot, forward, and swap transactions.

This is not correct. A FxSwap is a kind of Product. An FxSwap has two or more Legs.

Why is this modelled this way? If it is a bug, please fix it.

0000531: Refactor FX option products into a single product

Modeling change recommendation: Refactor FX option products into a single product with a variety of features, based on the new generic option model.

0000611: Validation rules don't apply to all views!

Not all validation rules apply to all views. They should be split up.

0000927: ird-14 needs to handle relative dates

ird-14 handles effectiveDate but not relativeEffectiveDate

The rule today is:
"
Context: CalculationPeriodDates (complex type)
terminationDate/unadjustedDate gt effectiveDate/unadjustedDate
"

We can either put a guard on the context to limit the rule to effectiveDate, or we can also evaluate the relativeEffectiveDates

With a guard:
"
Context: CalculationPeriodDates (complex type)[exists(effectiveDate)]
terminationDate/unadjustedDate gt effectiveDate/unadjustedDate
"

Handling just the relativeEffectiveDate would be:
"
Context: CalculationPeriodDates (complex type)[exists(relativeEffectiveDate)][not(exists(relativeEffectiveDate/dayType))]
terminationDate/unadjustedDate gt (id(relativeEffectiveDate/dateRelativeTo/@href) + interivalDuration(relativeEffectiveDate/periodMultiplier, relativeEffectiveDate/period))
"
The guard [not(exists(relativeEffectiveDate/dayType))] is necessary because we cannot do dayType calculations. We should check with Harry the rule applies before dayType calculations, not afterwards as I am unsure of this.

The two cases (relativeEffectiveDate and effectiveDate), could be combined into one rule.

-----Original Message-----
From: valwg@fpml.org [mailto:valwg@fpml.org] On Behalf Of Christian Nentwich
Sent: 21 April 2009 10:06
To: valwg@fpml.org
Subject: Re: FpML-VAL cd-26 unhandled case

Matthew,

if the rules need to be complete with respect to optionality, you'll
find quite a few others where this is not the case - because they were
not originally written with that in mind.

For example ird-14:

terminationDate/unadjustedDate gt effectiveDate/unadjustedDate

A swap might have a relativeEffectiveDate instead of effectiveDate...
Anybody got a fine tooth comb handy?

Christian

0000922: ln-21 freely or bound interpretation

There are many clauses in ln-21 should they be used freely or bound? Should the clauses be split into separate rules?

-----Original Message-----
From: valwg@fpml.org [mailto:valwg@fpml.org] On Behalf Of Christian Nentwich
Sent: 24 March 2009 15:39
To: valwg@fpml.org; Andrew P Parry
Subject: FpML-VAL More feedback on validation rules

All,

I am posting this here again because this group will be much more aware
of what has previously been flagged as an issue. Either way, I hope you
find it useful as an additional check-point:
...
...
**

Rule ln-21 (and potentially others, but only spotted it here): The XPath
description makes statements like
"exists(interestAccrualSchedule/interestRatePeriod/interestDayBasis)"
whereas the English states
"interestAccrualSchedule/interestRatePeriod/interestDayBasis must
exist". Interpreting the rule freely, it is likely that the English
version means "an interestDayBasis must exist in EVERY rate period" -
but that is not what the XPath expresses.

MDR response (abbreviated) -

There were many problems with Loans. In the end we agreed to suspend work on Loans Validation until the schema settled. I can see the problem you have identified. When you use the term "freely", I presume you mean that in the mathematical sense of an unbound variable rather than the vernacular sense of willy-nilly? Whether I interpret the rule bound or freely it still makes no business sense to me. Why would all these clauses be combined into ln-21 if we were to interpret them freely? The clauses should be split up to provide the maximally free expression under a single valid context.

0000849: The term regular Period as a function

The term "regularPeriod" can be written out as a function as per the Validation Architecture.

The reason why the function is so much better is that the context of all the item is no longer ambiguous - it becomes explicit.

The XQuery equivalent is included for comparison only. The proposal does not advocate XQuery, it is included for information only.
"
declare function fun:regularPeriod($cpd as element(*, CalculationPeriodDates)) as element(period)
(: The regular period of a set of calculation period dates is the period between a start date and an end date. 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. :)
{
validate strict {
element period {
element startDate {
if (exists($cpd/firstRegularPeriodStartDate))
then data($cpd/firstRegularPeriodStartDate)
else
data($cpd/effectiveDate/unadjustedDate)
},
element endDate {
if (exists($cpd/lastRegularPeriodEndDate))
then data($cpd/lastRegularPeriodEndDate)
else
data($cpd/terminationDate/unadjustedDate)
}
}
}
};
"

Writing the function out as per the FpML Validation Specification gives:
"
Function Name = regularPeriod
Description = The regular period of a set of calculation period dates is the period between a start date and an end date. 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.
Parameter 1 = $cpd as element(*, CalculationPeriodDates) (min=1, max=1)
Result Type = element(period)
Test = 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))
"

0000842: ird-36 date arithmetic in days and weeks only

The problem with ird-36 is that it is currently undefined in how to do calculations that mix days and weeks.

The rule today is:
"
ird-36 (Mandatory)
Context: PaymentDates (complex type)
[exists(firstPaymentDate)] [exists(lastRegularPaymentDate)]
The period defined by the dates firstPaymentDate and lastRegularPaymentDate must be an integer multiple of paymentFrequency.
"

The problem is that one date minus another gives a duration in days. We need a specified convention to deal with all the types of payment frequencies that work against the schedule

Given two dates, and the duration between them we need to know how to compare that duration in days for payment frequences:
* days
* weeks
* months
* years

For example, given the dates 1/1/2007 and 31/1/2008 how do I compare this to:
* 365 days
* 52 weeks
* 12 months
* 1 year

0000841: defining "the schedule implied by"

The definition of "the schedule implied by" is itself not precise, nor complete.

The definition today is:
"
Term: the schedule implied by
The schedule defined by the effective- and termination-Date, together with the "RegularPeriod" dates which may appear optionally in the presence of stubs, and the calculation period frequency.
"

1. The first change is that this must be rewritten as function so the context is clear. For example in valid-ird-54-01.xml there are two 'effectiveDate' elements.
2. "effective-" should be replaced by the XPath "//effectiveDate".
3. "termination-Date" should be replaced by the XPath "//terminationDate".
4. The XPath for "RegularPeriod" must be given.
5. The XPath for the "stubs" must be given.
6. The XPath for the "calculation period frequency" must be given.
7. The effectiveDate has element only content, so it must be made clear whether it is the adjusted or unadjusted date that is used.
8. Same again but for terminationDate.

0000815: fx-12 needs defining completely

The current fx-12 leaves a large amount to interpretation:

"
fx-12 (Mandatory)
Context: FxAverageRateOption (complex type)
[exists(averageRateObservationSchedule)]
The values of observedRates/observationDate should match the calculated schedule dates derived from parameters defined within the averageRateObservationSchedule element and the business day calendar implied by fixingTime/businessCenter.
"

The rule must define: "match", "calculated schedule date", the derivation process in "derived", and the calculation in "implied".

At the moment it is more of a comment than a rule.

0000814: invalid-fx-10-01 does not exercise the rule

The invalid sample invalid-fx-10-01.xml does not exercise rule fx-10 because the guard on the rule only applying to periods in days rules out this sample.

The guard is added in issue 0000813.

2001-11-01
2001-11-30

4

M
NONE

The sample needs to be changed to exercise the rule.

The same problem also occurs with invalid-fx-10-02.xml

0000813: fx-10 only works on Day Periods.

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.
"

0000737: ln-6 the term period is undefined

In ln-6 the term period is undefined.

The term is not defined as an element nor a function, so it remains undefined and ambiguous. There is no element of that name in context.

The rule today is:
"
Context: InterestAccrualSchedule (complex type)
ln-6 (Mandatory)
interestRatePeriod/startDate,lenderLoanContractPeriod/startDate, interestAccrualPeriod/startDate must be equal in each period.
"

There are many interpretations of this which look plausible. This will need to go back to the Loans WG to advise on the rule.

0000664: cd-33 incorrectly assumes a fixed number of days in a month

cd-33 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.
"

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.

This is a spin-off of issue 0000636