From: Kao, Tony
Sent: Tuesday, April 10, 2007 1:19 AM
To: 'irdwg@xxxxxxxx'
Cc: Lamy, Pierre; Orme, Jamie
Subject: propose new finalPeriodDateAdjustment element to CancelableProvision
-
renamed unadjustedCancellationDates element to finalPeriodDateAdjustment to clarify that this new element is use to adjust the final payment period.
-
moved position of finalPeriodDateAdjustment element to the end of element list of CancelableProvision complex type
-
replaced dateAdjustments with businessDateConvention to restrict adjustment only to BDC since business center should not be overridden.
-
made businessDateConvention mandatory to simplify number of scenarios need to be supported.
-
declared swapStreamReference of type SwapStreamReference.
From: irdwg@xxxxxxxx [mailto:irdwg@xxxxxxxx] On Behalf Of harry.w.mcallister@xxxxxxxxxxxx
Sent: Wednesday, April 04, 2007 2:54 PM
To: irdwg@xxxxxxxx
Cc: Orme, Jamie; mgratacos@xxxxxxxx; IYermakova@xxxxxxxx
Subject: FpML-IRD Reminder: FpML IRD-WG Meeting Thursday April 5 0900 EST/1400 BST
Call in details:
US : +1 888 481 3032
International : +1 617 801 9600
UK : 08009047961
Participant Code: 8682747
----- Forwarded by Harry W Mcallister/JPMCHASE on 04/04/2007 19:52 -----
Harry W Mcallister/JPMCHASE 30/03/2007 14:26
irdwg@xxxxxxxx jamie.orme@xxxxxx, mgratacos@xxxxxxxx, IYermakova@xxxxxxxx Fw: FpML-IRD Swap with Cancellable Provision - Cancellation Effective Date BDC
All,
I'd like to call a meeting of the IRD Working group to discuss the proposal from Jamie Orme on leg-level cancellation date overrides for the cancelableProvision (see below).
I realise that getting everyone together in the run up to the Easter break may be difficult, but to give sufficient notice I suggest 0900 EST/1400 BST next Thursday, April 5.
Please indicate if you will be able to attend.
Best regards,
Harry McAllister
Chair, FpML IRD-WG
+44 (0)20 7325 9046
----- Forwarded by Harry W Mcallister/JPMCHASE on 30/03/2007 14:19 -----
"Orme, Jamie" <jamie.orme@xxxxxx>
Sent by: irdwg@xxxxxxxx29/03/2007 16:20
irdwg@xxxxxxxx
<irdwg@xxxxxxxx> FpML-IRD Swap with Cancellable Provision - Cancellation Effective Date BDC
IRDWG,This is a follow-up to discuss in more detail a proposal to support leg level cancellation effective date BDC's within the cancellation provision. Please find original email attached.
<<Swap with cancellable provision - Cancellation Date BDC>>
As the actual requirement itself hasn’t changed, I would like to go into more detail on potential solutions (especially now that I have had the chance to complete some more in-depth analysis).Proposal 1
Add a new element, unadjustedCancellationDates, to the cancelableProvision. The advantage of this approach is that we are not polluting a pre-existing element within the cancellation provision. However the date adjustments are detached from the element where the actual dates are defined so we will need an id/href relationship to link one to the other.
The unadjustedCancellationDates will be an un-bounded optional element. It provides a reference to the relevantUnderlyingDate (found in the applicable exercise node it contains the actual unadjusted cancellation dates). It will also include a link to a swapStream so we can determine which leg the date adjustments are for along with the appropriate period end date BDC. By also having an optional dateAdjustments element here as well we can override the BDC as required (so within a leg the period end date BDC and cancellation effective date BDC can differ).
This allows the following situations to be modelled:
- The unadjustedCancellationDates element is not present. The date adjustments for the cancellation effective dates will be at the deal level and specified within the relevantUnderlyingDate element (as per existing schema).
- New unadjustedCancellationDates elements are present, one for each leg. Leg level period end date BDC's from the swapStream will be used (these will override the deal level BDC within the relevantUnderlyingDate element).
- New unadjustedCancellationDates elements are present, one for each leg. By including a dateAdjustments element we can explicitly specify a cancellation effective date BDC for a leg (which will override the period end date BDC within the referenced swapStream).
- A combination of 2 & 3 from above.
Please find the proposed schema change attached, together with a screen-shot:
<<fpml-ird-4-2.xsd>> <<proposal1.png>>
The resultant Fpml could look like the following:
The swapStream will have an id associated with it:
<swapStream id="FIXED">
</swapStream ><swapStream id="FLOAT">
</swapStream >Within the exercise type (e.g. bermudaExercise) the relevantUnderlyingDate will also have an id:
<relevantUnderlyingDate id="cancellationEffectiveDates">
</relevantUnderlyingDate>The new element within the cancelableProvision can then be built as follows:
<unadjustedCancellaionDates>
<relevantUnderlyingDateReference href="cancellationEffectiveDates"/><swapStreamReference href="FIXED"/>
</unadjustedCancellaionDates>
<unadjustedCancellaionDates>
<relevantUnderlyingDateReference href="cancellationEffectiveDates"/><swapStreamReference href="FLOAT"/>
<dateAdjustments>
<businessDayConvention>NONE</businessDayConvention>
</dateAdjustments>
</unadjustedCancellaionDates>This example shows how you could have the period end date BDC on the fixed leg, but no date adjustments on the float leg.
Proposal 2
Similar to the above, but adding the required schema functionality to the relevantUnderlyingDate itself (in a backwardly compatible way). The advantage of doing it this way is that the adjustments live alongside with the actual unadjusted dates themselves (possibly giving more clarity). The downside is that we are complicating an existing element that isn't exclusively used for cancellation effective dates.
A new unbounded element, swapStreamDateAdjustments, within adjustableDates (inside relevantUnderlyingDate) will contain a link to the relevant swapStream (leg) as well as containing a dateAdjustments element. This then gives the same flexibility as proposal one.
<<fpml-shared-4-2.xsd>> <<proposal2.png>> <<fpml-ird-4-2.xsd>>
Example Fpml snippet:
<swapStream id="FIXED">
</swapStream ><swapStream id="FLOAT">
</swapStream >The relevantUnderlyingDate now doesn’t need an id. However to model the same example from above we need to use the new swapStreamDateAdjustments element:
<relevantUnderlyingDate>
<adjustableDates>
<unadjustedDate>2006-11-27</unadjustedDate>
<unadjustedDate>2006-12-27</unadjustedDate>
<unadjustedDate>2007-01-27</unadjustedDate>
<unadjustedDate>2007-02-27</unadjustedDate>
<unadjustedDate>2007-03-27</unadjustedDate>
<swapStreamDateAdjustments>
<swapStreamReference href="FIXED"/>
</swapStreamDateAdjustments>
<swapStreamDateAdjustments>
<swapStreamReference href="FLOAT"/>
<dateAdjustments>
<businessDayConvention>NONE</businessDayConvention></dateAdjustments>
</swapStreamDateAdjustments>
</adjustableDates>
</relevantUnderlyingDate>I hope the above is clear. Please let me know if any more information is required.
Harry - Would we be able to organise a WG meeting to discuss the above?
Thanks
Jamie
----- Message from "Orme, Jamie" <Jamie.Orme@xxxxxxxxxxxxxxx> on Wed, 21 Mar 2007 10:57:09 +0100 -----
<irdwg@xxxxxxxx> Swap with cancellable provision - Cancellation Date BDC
IRDWG,We are working on an internal project to support IR Swaps with a cancellable provision.
Based on the attached email, it is the second variety we are looking to implement.
One schema issue we have come across, related to the type of trades we currently book, is that we need to model the cancellation effective date BDC at the leg level and not at the deal level. We currently store the unadjusted dates in the relevantUnderlyingDate element (of type AdjustableOrRelativeDates), which is under the relevant exercise type in the cancellation provision.
The annotation for this field is:
"The day on the underlying set by the exercise of an option. What this date is depends on the option (e.g. in a swaption it is the effective date, in an extendible/cancellable provision it is the termination date)."
Within this element we have adjustableDates which can be modified according to a trade level BDC.
The issue we have is that the period end BDC's on the swap may not match the cancellation effective date BDC's:
i.e.
It is possible to have the following:
PAY Period End BDC: FOLLOWING
REC Period End BDC: FOLLOWING
PAY Cancellation Effective Date BDC: FOLLOWING
REC Cancellation Effective Date BDC: Unadjusted (NONE)
There could be variations on this theme.
Do you know of any way we can support this without a schema change?
One possible solution could be to do the following (make the dateAdjustments unbounded):
It would mean changing the AdjustableOrRelativeDates type, but it would be backwardly compatible. We could also look to have an id/h-ref link into the swapStream if the period end and cancellation BDC's match.
I also got the following explanation "snippet" from our drafting team as to why we need to book trades that require this level of flexibility:
"…..if the option buyer exercises their right to cancel on April 9, 2007 (which happens to be Easter Monday) then fixed rate payer accrues payments till 9-Apr but the float rate payer accrues payments up until the following day, 10-April. These accrued payments will have to be exchanged at the end (confirm doesn't explicitly say this but apparently that's what happens.) And that's why it's important to state the adjustment and Business Day Convention for the Effective Date of Cancellation. Most of the time, this adjustment and BDC coincide with that of the Payments adjustment and BDC but there is always a possibility that traders could agree to something different upfront….."
Although not defined within the ISDA template, we believe that this could well be an industry wide requirement. And as mentioned above we do see trades like this.
Any insight you could provide on this would be much appreciated!
Thanks
Jamie
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.