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

RE: FpML-CD RE: Proposal to create new version of credit seniority scheme



Hi Marc/Selma/All:
 
Again, sorry for the slow response.
 
I favor a credit seniority scheme that supports all the Markit RED Tier Codes, as Selma has proposed.
 
However, it is very common in the credit derivatives world to see a simple enumeration of  "Senior, Subordinated"  used for credit seniority (e.g. pricing runs, broker screens, etc) and that should be supported in FpML as well. The RED version and the "Senior, Subordinated" version are mutually exclusive. You can take the finer grain RED version and map it's values to the coarser "Senior, Subordinated".
 
To support both, we could have all the RED values highlighted as such in the scheme description or we could have two versions of the scheme. One with the RED values and one with the other two values. Two versions would give clarity and as Owen states "has the effect of allowing a 1:1 mapping between FpML values and Markit RED Tier Codes to simplify integration work for implementers."
 
Marc, what is the right approach from an architectural perspective?
 
Thanks,
 

Ben Lis – Head of Product Management and Integration
ICE Processing                                                 
875 Third Avenue | New York, NY 10002
Tel: 212.323.6041                              
Ben.Lis@xxxxxxxxxx
 

 


From: cdwg@xxxxxxxx [mailto:cdwg@xxxxxxxx] On Behalf Of Marc Gratacos
Sent: Friday, March 12, 2010 6:20 AM
To: cdwg@xxxxxxxx
Subject: FpML-CD RE: Proposal to create new version of credit seniority scheme

Any comments/objections to the proposal described below?
 
thanks

From: cdwg@xxxxxxxx [cdwg@xxxxxxxx] On Behalf Of Selma Laidoudi [Selma.Laidoudi@xxxxxxxxxxxxxx]
Sent: Monday, March 01, 2010 2:35 PM
To: cdwg@xxxxxxxx
Subject: FpML-CD FW: Proposal to create new version of credit seniority scheme

Ben/All,

 

Please find below a proposal for creating a new version of the credit seniority coding scheme.

 

Comments are most welcome.

 

Thanks,

 

Selma Laidoudi

+44 (0) 20 3367 0394


From: Owen King
Sent: 01 March 2010 13:02
To: Selma Laidoudi
Subject: Proposal to create new version of credit seniority scheme

 

Hi Selma,

 

In line with an open issue (http://www.fpml.org/issues/view.php?id=362) I'd like to propose to the FpML credit working group that a new version of the credit seniority coding scheme is created as follows in order to allow differentiation between secured and non-secured debt. This also has the effect of allowing a 1:1 mapping between FpML values and Markit RED Tier Codes to simplify integration work for implementers. 

 

Remove:   Senior

Add:         SeniorSec, SeniorUnSec

 

I've attached my proposed coding scheme to this email.

 

Many thanks,

 

Owen King

Vice President

Business Analysis

 

MarkitSERV

 

Cottons Centre, Level 3

Cottons Lane
London, SE1 2QL

+44 20 3367 0347    Office

+44 20 3367 0301    Fax

www.markitserv.com



The information contained in either this email and, if applicable, the attachment, are confidential and are intended only for the recipient. The contents of either the email or the attachment may not be disclosed or used by anyone other than the addressee. If you are not the intended recipient(s), any use, disclosure, copying, or distribution is prohibited and may be unlawful. If you have received this communication in error, please notify us by e-mail at isda@xxxxxxxx <mailto:isda@xxxxxxxx> then delete the e-mail and all attachments and any copies thereof. This communication is part of an ISDA process and is not intended for unauthorized use or distribution.
This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired.