[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: FpML-VAL More feedback on validation rules



Matthew,

eqd-31 and eqd-32 are the more generic ones, so I had assumed these would be the ones to keep. Either that, or 23 and 30 need to be more generic. Andrew also indicated that the rule should apply to all products.


As for cd-37, I suggest rephrasing from:

If condition quotationAmount is true, and if condition minimumQuotationAmount is true, and if both amounts have the same-currency, then quotationAmount/amount must be greater or equal to minimumQuotationAmount/amount

to:

If quotationAmount exists and minimumQuotationAmount exists and if both amounts have the same-currency, then quotationAmount/amount must be greater or equal to minimumQuotationAmount/amount

In addition, the quotationAmount and minimumQuotationAmount "conditions" should be removed from the rule file.


For ln-21, I cannot quite follow - I thought the rule was restricting the entries in the interest accrual schedule, to force certain elements to be mandatory in all steps, *if* such a schedule is used inside InterestPaymentNotice (the rule context). That would make sense to me. To say "at least one (random) step has a rate defined", as the XPath would imply, made rather less sense. Caveat emptor: I have never used the syndicated loan definitions, so I am speculating.

Christian


Matthew D Rawlings wrote:
Thanks for contributing, it is very useful.

Eqd-23 and eqd-31 are expressed differently, but with the FpML schema appear to amount to the same thing. I'd agree with removing one, but which? I have raised an issue: http://www.fpml.org/issues/view.php?id=918.

Raised an issue for eqd-30 and eqd-32 to track this: http://www.fpml.org/issues/view.php?id=919. Yes, definitely a bug in eqd-31 and eqd-32 with the missing effectiveDate: http://www.fpml.org/issues/view.php?id=920 and http://www.fpml.org/issues/view.php?id=921. 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. http://www.fpml.org/issues/view.php?id=922
cd-37 - yes, you're correct. How would you structure the rule?


Matthew +44 7917 596 827


-----Original Message-----
From: valwg@xxxxxxxx [mailto:valwg@xxxxxxxx] On Behalf Of Christian Nentwich
Sent: 24 March 2009 15:39
To: valwg@xxxxxxxx; 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:

- eqd-23 ("every option has effective date after trade date") seems to be made redundant by eqd-31 ("anything deriving from EquityDerivativeBase has effective date after start date")
- eqd-30 seems to be made redundant by eqd-32, for the same reason
- The XPath in eqd-31 and eqd-32 is missing equityEffectiveDate after $equityDerivativeBase, in the > comparison of the path

**

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.

I expressed the rule as follows in NRL (note the "in each", instead of "in at least one") and would appreciate your feedback:

Context: InterestPaymentNotice
Rule "ln-21"
In each interestAccrualSchedule.interestRatePeriod the following are present: interestRate, allInRate, indexTenor and in each interestAccrualSchedule.interestRatePeriod the following are present: margin, interestDayBasis **

Rule cd-37: it doesn't make a lot of sense to define quotationAmount and minimumQuotationAmount as "conditions" just for one rule. These are just simple existence checks, the conditions should probably be removed (or you will be swamped, if you adopt this approach across the board).

**

Rule ird-12. A word is missing in the description: "the frequency specified in calculationPeriodFrequency must divide the __calculation period___ precisely". This rule is insufficiently formalised. It does not point to, or define, what the "start date" or "end date" of the period is. You could probably do that by pointing to the definitions at the top.

Alternatively, it is possible to formalise this rule by breaking into four different stub scenarios, for example in NRL (which you can strip of syntax and use as English if you wish):

If no firstRegularPeriodStartDate is present and no lastRegularPeriodEndDate is present then the [frequency defined by] the effectiveDate.unadjustedDate and the terminationDate.unadjustedDate
[is an integer multiple of] the calculationPeriodFrequency

Similar rules applies for the other stub scenarios, with the respective stub dates substituted.

regards,
Christian

-------------------------------------------------------------------------------
To unsubscribe: Email majordomo@xxxxxxxx with a blank subject line
In the body include the line: unsubscribe valwg youremail@address
To view archives: http://www.fpml.org/_wgmail/_valwgmail/threads.html
-----------------------------------------
This communication is for informational purposes only. It is not
intended as an offer or solicitation for the purchase or sale of
any financial instrument or as an official confirmation of any
transaction. All market prices, data and other information are not
warranted as to completeness or accuracy and are subject to change
without notice. Any comments or statements made herein do not
necessarily reflect those of JPMorgan Chase & Co., its subsidiaries
and affiliates.

This transmission may contain information that is privileged,
confidential, legally privileged, and/or exempt from disclosure
under applicable law. If you are not the intended recipient, you
are hereby notified that any disclosure, copying, distribution, or
use of the information contained herein (including any reliance
thereon) is STRICTLY PROHIBITED. Although this transmission and any
attachments are believed to be free of any virus or other defect
that might affect any computer system into which it is received and
opened, it is the responsibility of the recipient to ensure that it
is virus free and no responsibility is accepted by JPMorgan Chase &
Co., its subsidiaries and affiliates, as applicable, for any loss
or damage arising in any way from its use. If you received this
transmission in error, please immediately contact the sender and
destroy the material in its entirety, whether in electronic or hard
copy format. Thank you.

Please refer to http://www.jpmorgan.com/pages/disclosures for
disclosures relating to UK legal entities.

-------------------------------------------------------------------------------
To unsubscribe: Email majordomo@xxxxxxxx with a blank subject line
In the body include the line: unsubscribe valwg youremail@address
To view archives: http://www.fpml.org/_wgmail/_valwgmail/threads.html


-------------------------------------------------------------------------------
To unsubscribe: Email majordomo@xxxxxxxx with a blank subject line
In the body include the line: unsubscribe valwg youremail@address
To view archives: http://www.fpml.org/_wgmail/_valwgmail/threads.html