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

FpML-IRD Swap with Cancellable Provision - Cancellation Effective Date BDC



Title: 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:

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

--- Begin Message ---
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


 

Attachment: RE FpML-IRD Swap Cancellable and Extendable modifications.oft
Description: RE FpML-IRD Swap Cancellable and Extendable modifications.oft


--- End Message ---

Attachment: fpml-ird-4-2.xsd
Description: fpml-ird-4-2.xsd

Attachment: proposal1.png
Description: proposal1.png

Attachment: fpml-shared-4-2.xsd
Description: fpml-shared-4-2.xsd

Attachment: proposal2.png
Description: proposal2.png

Attachment: fpml-ird-4-2.xsd
Description: fpml-ird-4-2.xsd