[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: FpML-VAL More feedback on validation rules
- To: "valwg@xxxxxxxx" <valwg@xxxxxxxx>, Andrew P Parry <andrew.p.parry@xxxxxxxxxxxx>
- Subject: RE: FpML-VAL More feedback on validation rules
- From: Matthew D Rawlings <matthew.d.rawlings@xxxxxxxxxxxx>
- Date: Tue, 24 Mar 2009 16:30:44 +0000
- Accept-language: en-US, en-GB
- Acceptlanguage: en-US, en-GB
- Dkim-signature: v=1; a=rsa-sha256; c=simple/simple; d=jpmchase.com; s=smtpout; t=1237912474; bh=CLoQ7982PhyUUzBZz8vdzY9+IurelE1d5xjdXK+ XgIQ=; h=From:To:Date:Subject:Message-ID:References:In-Reply-To: Content-Transfer-Encoding:MIME-Version:Content-Type; b=sNBWao0iBpa QcTH1wM5h10stbokpGdqNWIWCSKjiJUaqxnE4e5NtGmQv2AtnBvalFFfX4cyPt2p9HP gGqgMqa8b8c/JvSc2cZ02YBjRRxwRlc4DaDLF8fddRkUGRAIgLARRRNI86JUsWDj1cK bjjRvDrEKUDHu1rkrzA716ZAaQ=
- In-reply-to: <49C8FE7E.5030307@xxxxxxxxxxxxxxxx>
- References: <49C8FE7E.5030307@xxxxxxxxxxxxxxxx>
- Reply-to: valwg@xxxxxxxx
- Sender: valwg@xxxxxxxx
- Thread-index: AcmslqH8Abb8G6CvQZKGVj8ZBR72ZQAAYNxA
- Thread-topic: FpML-VAL More feedback on validation rules
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