FpML Issues Tracker
closed
Minor
Always
Equity Derivatives
Admin
apparry
Summary
The rule today:
" Context: Trade (complex type) eqd-1 (Mandatory) //equityExercise/equityAmericanExercise/commencementDate/adjustableDate/unadjustedDate must be equal to tradeHeader/tradeDate. "
The problem is that not every Trade has a //equityAmericanExercise. For example IRS and CDS Trades will not have an equityAmericanExercise.
Solution 1 is to put a filter on the context. In XPath the filter is: " Context: Trade (complex type)[//equityAmericanExercise] eqd-1 (Mandatory) //equityExercise/equityAmericanExercise/commencementDate/adjustableDate/unadjustedDate must be equal to tradeHeader/tradeDate. "
If we removed the FpML changes to XPath and went to genuine XPath this would be: " Context: //element(*, Trade)[//equityAmericanExercise] eqd-1 (Mandatory) //equityExercise/equityAmericanExercise/commencementDate/adjustableDate/unadjustedDate must be equal to tradeHeader/tradeDate. "
Solution 2 is to add a clause to the rule:
" Context: Trade (complex type) eqd-1 (Mandatory) If //equityAmericanExercise exists then //equityExercise/equityAmericanExercise/commencementDate/adjustableDate/unadjustedDate must be equal to tradeHeader/tradeDate, otherwise true(). "
The problem with solution 2 is that it would fire (because the context is matched), even when there is no equityAmericanExercise. For example it would fire and return true() for every IRS Trade. For this reason solution 1 is preferred.
This issue arises from implementing the improvements to the rules in FpML 4-4-5 (LCWD).
The same problem occurs for eqd-2, eqd-4, eqd-5, eqd-12, eqd-13, and eqd-14. The solution chosen for eqd-1 can also be applied to these other rules.
Notes:
mgratacos
05/09/08 1:50 pm
EQDWG 2008-05-09: agreement to remove this rule. It’s not right from business perspective.
iyermakova
05/15/08 8:26 pm
Rule eqd-1 has been removed. The change has been committed to trunk and branchesFpML-5-0.
Eqd WG needs to agree which solution to use for eqd-2, eqd-4, eqd-5, eqd-12, eqd-13, and eqd-14
matthewdr
05/16/08 10:25 am
The solution for eqd-2, eqd-4, eqd-5, eqd-12, eqd-13, and eqd-14 was determined by the EQDWG to follow the same pattern. The result of following the same pattern is below:
(for $trade in //element(*, Trade)[equityOption/equityExercise/equityAmericanExercise]
return val:pretty-result(“eqd-2”, $trade/equityOption/equityExercise/equityAmericanExercise/expirationDate/adjustableDate/unadjustedDate ge $trade/tradeHeader/tradeDate, $trade, “See issue http://www.fpml.org/issues/view.php?id=672“))
,
(for $trade in //element(*, Trade)[equityOption/equityExercise/equityBermudaExercise]
return val:pretty-result(“eqd-4”, $trade/equityOption/equityExercise/equityBermudaExercise/commencementDate/adjustableDate/unadjustedDate ge $trade//tradeHeader/tradeDate, $trade, “See issue http://www.fpml.org/issues/view.php?id=672“))
,
(for $trade in //element(*, Trade)[equityOption/equityExercise/equityBermudaExercise]
return val:pretty-result(“eqd-5”, $trade/equityOption/equityExercise/equityBermudaExercise/expirationDate/adjustableDate/unadjustedDate ge $trade/tradeHeader/tradeDate, $trade, “See issue http://www.fpml.org/issues/view.php?id=672“))
,
(for $trade in //element(*, Trade)[equityOption/equityExercise/equityEuropeanExercise]
return val:pretty-result(“eqd-12”, $trade/equityOption/equityExercise/equityEuropeanExercise/expirationDate/adjustableDate/unadjustedDate ge $trade/tradeHeader/tradeDate, $trade, “See issue http://www.fpml.org/issues/view.php?id=672“))
,
(for $trade in //element(*, Trade)[equityOption/equityPremium/paymentDate/unadjustedDate]
return val:pretty-result(“eqd-13”, $trade/equityOption/equityPremium/paymentDate/unadjustedDate ge $trade/tradeHeader/tradeDate, $trade, “See issue http://www.fpml.org/issues/view.php?id=672“))
,
(for $trade in //element(*, Trade)[brokerEquityOption/equityPremium/paymentDate/unadjustedDate]
return val:pretty-result(“eqd-14”, $trade/brokerEquityOption/equityPremium/paymentDate/unadjustedDate ge $trade/tradeHeader/tradeDate, $trade, “See issue http://www.fpml.org/issues/view.php?id=672“))
lyteck
07/17/08 8:48 pm
implemented as proposed: eqd-1, eqd-2, eqd-4, eqd-12, eqd-13, eqd-14 (for context=”trade”)
– used “>=” instead of “must be greater than or equal to”
– did not update eqd-5 since it is deprecated
issue 675 mandates the addition of “contract” as context (see http://www.fpml.org/issues/view.php?id=675). However, existing rules cannot be shared because header content model is different between trade and contract. As a result, rules have been split, resulting in the creation of eqd-2b, eqd-4b, eqd-12b, eqd-13b, eqd-14b (specific to context=”contract”) (test cases pending)
matthewdr
08/12/08 5:22 pm
Accepting the resolution.