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

RE: FpML-CD Proposal for Single-name CDS up-front payment direction.



I agree that it would be preferable to have only one structure, but also that it would be a hassle for folks to change, and hence any change should be rolled in slowly.

 

As an interim measure, couldn’t the sign of the single payment be set to negative to indicate a payment in the reverse to usual direction?  This might require changes to business rules, but I think that the schema should work as is.

 

- Brian

 


From: cdwg@xxxxxxxx [mailto:cdwg@xxxxxxxx] On Behalf Of Guy Gurden
Sent: Tuesday, August 08, 2006 11:46 AM
To: cdwg@xxxxxxxx
Subject: RE: FpML-CD Proposal for Single-name CDS up-front payment direction.

 

It’s debatable. I’d think given the existing implementation base it probably doesn’t make sense to deprecate singlePayment since in the majority of cases singlePayment would continue to work just fine. Although it would be cleaner since then you’d just have initialPayment to cover all situations.

 

Guy

 


From: cdwg@xxxxxxxx [mailto:cdwg@xxxxxxxx] On Behalf Of Ben Lis
Sent: Monday, August 07, 2006 6:18 PM
To: cdwg@xxxxxxxx
Subject: RE: FpML-CD Proposal for Single-name CDS up-front payment direction.

 

Guy:

 

If we were to go with the idea of using initialPayment, would you also suggest we deprecate singlePayment? 

Ben Lis
Integration Team Global Head
 
T +1 212 323 6041
www.tzero.com
 

 

 


From: cdwg@xxxxxxxx [mailto:cdwg@xxxxxxxx] On Behalf Of Guy Gurden
Sent: Monday, August 07, 2006 5:24 PM
To: cdwg@xxxxxxxx
Subject: RE: FpML-CD Proposal for Single-name CDS up-front payment direction.

Henri,

 

Rather than modify singlePayment I’d suggest an alternative which is in such circumstances to use the initialPayment structure (currently intended only to be used for the upfront fee on index trades). The initialPayment and singlePayment structure differ only in the payerPartyReference/receiverPartyReference elements.

 

An argument I’d put forward in favour of this approach is that initialPayment includes the element paymentAmount (of type Money) whereas singlePayment includes the element fixedAmount (also of type Money). fixedAmount is intended to correspond to the ISDA defined term Fixed Amount which is defined as “an amount that is payable by the Fixed Rate Payer…” so it would seem wrong to subvert the singlePayment structure and use it for payments that are payable by the Floating Rate Payer.

 

Guy

 


From: cdwg@xxxxxxxx [mailto:cdwg@xxxxxxxx] On Behalf Of Henri Pegeron
Sent: Monday, August 07, 2006 2:49 PM
To: cdwg@xxxxxxxx
Subject: FpML-CD Proposal for Single-name CDS up-front payment direction.

 


Ben/All,

This was mentioned briefly during the VALWG a few weeks back, but I would like to propose the ability to optionally specify the payer and receiver on a single name CDS up-front payment.

The usual case scenario (albeit almost always) where there buyer of protection is the payer to the seller of protection, is sometimes not the case.

DTCC has come across deals, in which the seller of protection pays a fee to the buyer, for example, in exchange for an agreed upon modification to the first period start date.  In this case, the deal bilaterally removes the concept of a short first period in exchange for an altered fee.  In these particular cases, the singlePayment structure can not accommodate this transfer of money unless slightly misused or made negative.  

One possible proposal would be to add an optional PayerReciever.model to the current singlePayment structure in the FpML feeleg.  The documentation for this could state that these fields (Payer and Reciever) may be specified for scenarios in which the buyer of protection is not paying the seller of protection.  If it is the status quo, then the payer and reciever would simply not be specified.  The TIW backloading initiative is also uncovering other CDS deals in which some participants are requesting the ability to change the direction of this payment.


I'd appreciate it if this could be briefly discussed as an additional CDWG item on the Wednesday call.


Thanks and Regards,
Henri Pegeron: DTCC
Business Analyst: ADM

+1 212 855 1682


________________________________________________________
DTCC DISCLAIMER: This email and any files transmitted
with it are confidential and intended solely for the use of the
individual or entity to whom they are addressed. If you have
received this email in error, please notify us immediately and
delete the email and any attachments from your system. The
recipient should check this email and any attachments for the
presence of viruses. The company accepts no liability for any
damage caused by any virus transmitted by this email.

This is a commercial communication sent by SwapsWire Limited.

 

This message contains confidential information and is intended only for the individual named.  If you are not the named addressee you should not disseminate, distribute or copy this e-mail.  Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses.  The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission.  If verification is required please request a hard-copy version.

 

Please contact info@xxxxxxxxxxxxx if you no longer wish to receive commercial communications from us, identifying the email addresses to which you no longer wish commercial emails to be sent.

This is a commercial communication sent by SwapsWire Limited.

 

This message contains confidential information and is intended only for the individual named.  If you are not the named addressee you should not disseminate, distribute or copy this e-mail.  Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses.  The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission.  If verification is required please request a hard-copy version.

 

Please contact info@xxxxxxxxxxxxx if you no longer wish to receive commercial communications from us, identifying the email addresses to which you no longer wish commercial emails to be sent.