Re: FpML-VAL cd-26 unhandled case

[ANDREW JACOBS <andrew.jacobs@xxxxxxxxxxxxxx>]

The relative effective/termination dates where added to support swaptions and relative instruments for pricing curves (I think) after last review of the IRD rules. A confirmable swap should never contain a relative dates.

We have been adding similar guards to other rules and should here for consistency.

The optionality in the credit model will be a real pain to sort out. By allowing lots of different underlyings (e.g. single name, basket, index, mortgage, loan, etc.) to be referenced in the same product the model for other parts of the product have become over generalised. At the moment its a 'data bucket' rather than a structured product model.

A better model would split the different underlying products out into different types of credit default swap so that each can have a stricter model with less coupling to other products. (Something I've suggested several times now). As it stands every time a change is made to the credit model a large percentage of the CD rules are broken - No wonder firms are reticent to implement validation in production systems!

Andrew Jacobs
Director, HandCoded Consulting Ltd.
Director, HandCoded Software Ltd.
Mobile +44 (0)7710 304239


--- On Tue, 21/4/09, Christian Nentwich <christian@xxxxxxxxxxxxxxxx> wrote:

> From: Christian Nentwich <christian@xxxxxxxxxxxxxxxx>
> Subject: Re: FpML-VAL cd-26 unhandled case
> To: valwg@xxxxxxxx
> Date: Tuesday, 21 April, 2009, 10:05 AM
> 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
> 
> 
> Matthew D Rawlings wrote:
> > 
> > Dear VWG –
> > 
> > cd-26 does not handle the effectiveDate being
> optional.
> > 
> > cd-26 today is:
> > "
> > Context: CreditDefaultSwap (complex type)
> > [exists(feeLeg/singlePayment/adjustablePaymentDate)]
> > feeLeg/singlePayment/adjustablePaymentDate gt
> generalTerms/effectiveDate/unadjustedDate
> > "
> > 
> > There is a guard on paymentDate, there should also be
> a guard on effectiveDate. I propose the new rule be:
> > "
> > Context: CreditDefaultSwap (complex type)
> >
> [exists(feeLeg/singlePayment/adjustablePaymentDate)][exists(generalTerms/effectiveDate)]
> > feeLeg/singlePayment/adjustablePaymentDate gt
> generalTerms/effectiveDate/unadjustedDate
> > "
> > 
> > I do not know the scenarios under which
> generalTerms/effectiveDate may be optional. The schema fails
> to document what it means when the field is not present. We
> should also get the schema documentation fixed up to state
> what it means when the element is not present.
> > 
> > This is logged as issue:
> http://www.fpml.org/issues/view.php?id=926
> > 
> > Matthew +44 7917 596 827
> > 
> >
> ------------------------------------------------------------------------
> > 
> > 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 European 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