FpML Issues Tracker
closed
Minor
Always
Equity Derivatives
Admin
lyteck
Summary
Section 4.6.1 of the FpML Manual states:
" 4.6.1 Implementations
For the purposes of precision, extensibility, and robustness to change the structure of the Validation Rules is profiled. The rules of the profile are:
* The context for a validation rule must always be a type. * The paths from the context should be node names rather than types wherever posssible. For example "equityAmericanExercise" is preferred to "element(*, EquityAmericanExercise)". * The context of the rule must be defined such that incorporates everything referred to in a rule. The rule must not use the ancestor or parent axis, or use them in cojunction with any other axis. For example "../../tradeHeader" is precluded. "
The problem is that eqd-23 uses the parent axis.
The rule today is: " Context: EquityDerivativeBase (complex type) eqd-23 (Mandatory) If equityEffectiveDate exists then: equityEffectiveDate >= ../tradeHeader/tradeDate Comment: The equityEffectiveDate exists only in the case of a forward starting option. "
The solution is to move the context up one level, so the parent axis is not needed.
The proposed rule is: " Context: (Trade (complex type), Contract (complex type), Strategy (complex type))[equityOption/equityEffectiveDate] eqd-23 (Mandatory) equityOption/equityEffectiveDate ge tradeHeader/tradeDate Comment: The equityEffectiveDate exists only in the case of a forward starting option. "
In XQuery this is:
(for $trade in (//element(*, Trade)|//element(*, Contract)|//element(*, Strategy))[equityOption/equityEffectiveDate]
return
Notes:
mgratacos
05/09/08 1:28 pm
EQDWG 2008-05-09: agreement to adopt the proposed resolution.
iyermakova
05/14/08 8:04 pm
– The above proposed works only if the context is “Trade”.
“Context: Trade (complex type)
eqd-23 (Mandatory)
If equityOption/equityEffectiveDate exists then: equityOption/equityEffectiveDate >= tradeHeader/tradeDate
Comment: The equityEffectiveDate exists only in the case of a forward starting option.
– If the context is “Contract”, there is no “tradeHeader/tradeDate”, only “header/contractDate”
“Context: Contract(complex type)
eqd-23 (Mandatory)
Comment: The equityEffectiveDate exists only in the case of a forward starting option.
If equityOption/equityEffectiveDate exists then: equityOption/equityEffectiveDate >= header/contractDate
Comment: The equityEffectiveDate exists only in the case of a forward starting option.
– If the context is “Strategy” (complex type), “tradeHeader/tradeDate” or “header/contractDate” is outside of this structure since the “strategy” is a product itself.
matthewdr
05/16/08 1:50 pm
Revised proposal following EQDWG:
”
Context: Trade (complex type)[equityOption/equityEffectiveDate]
eqd-23 (Mandatory)
equityOption/equityEffectiveDate >= tradeHeader/tradeDate
Comment: The equityEffectiveDate exists only in the case of a forward starting option.
Context: Contract (complex type)[equityOption/equityEffectiveDate]
eqd-30 (Mandatory)
equityOption/equityEffectiveDate >= header/contractDate
Comment: The equityEffectiveDate exists only in the case of a forward starting option.
”
iyermakova
05/22/08 8:45 pm
mgratacos
05/23/08 12:52 pm
If we move the context one level up, we need to take into account the fact that this rule may be applied to other products, not only equityOption. I am thinking about equityOptionTransactionSupplement, brokerEquityOption…
matthewdr
06/06/08 1:53 pm
Discussed at the EQDWG. It needs to support all kinds of Option for Equities, as well as Strategies. An updated proposal is needed.
Agreed Matthew to propose guards on product types.
matthewdr
06/06/08 2:23 pm
There was a small mistake in Irina’s example where the rule for Strategies, was used for Trades. There was a more significant mistake in my example where the forms of EQD options other thank Equity Option were omitted in error.
The rule is revised so it works for all forms EquityDerivativeBase.
For Trades:
”
Rule: eqd-31 (Mandatory)
Context: Trade (complex type)[element(*, EquityDerivativeBase)/equityEffectiveDate]
element(*, EquityDerivativeBase)/equityEffectiveDate >= tradeHeader/tradeDate
Comment: The starting date of an equity option must be after the trade date.
”
matthewdr
06/06/08 2:27 pm
The correct form for Contracts:
”
Rule: eqd-31 (Mandatory)
Context: Contract (complex type)[element(*, EquityDerivativeBase)/equityEffectiveDate]
element(*, EquityDerivativeBase)/equityEffectiveDate >= header/contractDate
Comment: The starting date of an equity option must be after the contract date.
”
matthewdr
06/06/08 2:54 pm
The two previous solutions can be extended to cope with Strategies:
For Trades (including plain products and Strategies):
”
Rule: eqd-31 (Mandatory)
Context: Trade (complex type)[//element(*, EquityDerivativeBase)/equityEffectiveDate]
every $equityDerivativeBase in //element(*, EquityDerivativeBase)[exists(equityEffectiveDate)] $equityDerivativeBase >= tradeHeader/tradeDate
Comment: The starting date of an equity option must be after the trade date.
”
For Contracts (including plain products and Strategies):
”
Rule: eqd-31 (Mandatory)
Context: Contract (complex type)[//element(*, EquityDerivativeBase)/equityEffectiveDate]
every $equityDerivativeBase in //element(*, EquityDerivativeBase)[exists(equityEffectiveDate)] $equityDerivativeBase >= header/contractDate
Comment: The starting date of an equity option must be after the contract date.
”
lyteck
07/16/08 8:51 pm
implemented eqd-23 and eqd-30 as proposed.
need guidance on eqd-31: Should it actually be split into eqd-31 (trade/strategies) and eqd-32 (contract/strategies)? (since the rule definitions are different)
matthewdr
07/22/08 9:28 am
In answer to Lyteck’s question – yes, it should be split into two separately numbered rules.
lyteck
07/22/08 8:51 pm
notes:
– expressed rule in English rather than Xpath as proposed.
(re: “Every…”
– capture coverage (products+strategies) directly in context
(i.e., “(including plain products and strategies)”)
implemented eqd-31 and eqd-32 as:
eqd-31 (Mandatory)
Context: Trade (including plain products and strategies) (complex type)
[if //EquityDerivativeBase/equityEffectiveDate exist]
Every EquityDerivativeBase/equityEffectiveDate must be >= tradeHeader/tradeDate.
Comment: The starting date of an equity option must be after the trade date.
eqd-32 (Mandatory)
Context: Contract (including plain products and strategies) (complex type)
[if //EquityDerivativeBase/equityEffectiveDate exist]
Every EquityDerivativeBase/equityEffectiveDate must be >= header/contractDate.
Comment: The starting date of an equity option must be after the contract date.
matthewdr
08/12/08 5:14 pm
“(including plain products and strategies)” – this documentation and shouldn’t be part of the rule text to evaluate because it is imprecise. It wasn’t part of what the EQDWG agreed.
“[if //EquityDerivativeBase/equityEffectiveDate exist]” – this is incorrect because it finds elements by name rather than by type. What was agreed by the EQDWG was “[//element(*, EquityDerivativeBase)/equityEffectiveDate]”. The EQDWG correct form gives the correct results.
The problem is that //element(*, XYZ) finds everything of type XYZ whereas //element(XYZ) finds everything of name XYZ.
lyteck
08/13/08 8:43 pm
fixed EQD-31, EQD-32 as proposed
matthewdr
08/19/08 5:16 pm
Closing after testing resolution.
matthewdr
08/20/08 3:18 pm
Reopening the issue because upon review it is not resolved.
The unique contexts section of the rules does not show eqd-17 under ShortFormDerivativesBase (complex type):
“Unique contexts:
* Trade (complex type): eqd-2 eqd-4 eqd-12 eqd-13 eqd-14 eqd-23 eqd-31
* Contract (complex type): eqd-2b eqd-4b eqd-12b eqd-13b eqd-14b eqd-30 eqd-32
* EquityAmericanExercise (complex type): eqd-3
* EquityBermudaExercise (complex type): eqd-6 eqd-7 eqd-8 eqd-9 eqd-10
* EquityExerciseValuationSettlement (complex type): eqd-15
* EquityOption (complex type): eqd-17 eqd-18 eqd-19 eqd-20
* CalculationAgent (complex type): eqd-21
* EquityDerivativeBase (complex type): eqd-22
* AveragingSchedule (complex type): eqd-24
* BrokerEquityOption (complex type): eqd-25
* EquityMultipleExercise (complex type): eqd-26 eqd-27 eqd-28 eqd-29
* Deprecated rules
* Removed rules
”
Yet the rule says it is:
”
eqd-17 (Mandatory)
Context: EquityOption (complex type)
EquityDerivativeShortFormBase (complex type)
”
The “unique contexts” section of the rules is wrong.
Either the “unique contexts” section is fixed or we dispense with this section altogether. I am quite happy to eliminate this section.
lyteck
08/20/08 3:43 pm
noted. It seems when there’s a list of contexts, only the first context is processed and added to the ‘unique contexts’ section, and subsequent context(s) are discarded (XSLT issue)
lyteck
08/26/08 6:06 pm
Can this issue actually be closed as it will be solved by # 778?
(the source code is already updated to fix eqd-31,32 when 778 is solved.)
matthewdr
09/17/08 10:16 am
Closed after testing.