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

FW: [fpml-coord] minutes 2007-11-19



Hi Bhavik,

 

There were a couple of items related to the loan work discussed yesterday in the coordination committee.

  • Why has the group focused on notices and not a simple loan representation for position report or underlyers? I think we discussed this point several times in the meetings but it would be worth to clarify it.
  • The different notices should be represented as separate message types: one notification message for drawdown, another for interest payment notice, repayment notice,…to be consistent with 4.x version.
  • Andrew Parry has done some review of current model and has some schema suggestions. I am not sure whether he’ll be in the call.

 

Best regards,

Marc

 


From: coord@xxxxxxxx [mailto:coord@xxxxxxxx] On Behalf Of Marc Gratacos
Sent: Monday, November 19, 2007 7:11 PM
To: coord@xxxxxxxx
Subject: [fpml-coord] minutes 2007-11-19

 

Participants

Irina Yermakova (ISDA)

Andrew Parry (JPMorgan)

Lyteck L. (ISDA)

Brian Lynn (GEM)

Pierre Lamy (Goldman Sachs)

Robert Stowsky (Brook Path)

Karel Engelen (ISDA)

Harry McAllister (BNPParibas)

Marc Gratacos (ISDA)

Andrew Jacobs (HandCoded)

 

Apologies

Simon Heinrich (IONA)

 

1.       Multiple exchange traded instrument proposal (See Proposal Multiple exchangeId.zip and original e-mail below)

a.       Andrew Parry described the proposal from DTCC to allow multiple exchange Id for equity indices. For equity indices, exchangeId indicates the exchanges from which valuation/price of each constitutent will be based in case of disruption.

b.       Participants felt this was overloading the use of exchangeId, which is meant to represent the exchange where a stock is traded.

c.       It was suggested to add an additional element within the index underlyer called constituentExchangeId (optional, multiple occurrence) to support the business requirement but distinguish it from exchangeId.

d.       FpML underlyers should be refactored in 5.0 to make sure that elements present in an underlyer have sense from a business perspective.

Further points from Andrew Parry were discussed:

1.1   Loan WG work extends neither FpML:Product nor FpML:Underlyer. A single message type "LoanServicingNotification" is used with a choice group to select the business process, which is the functional equivalent of not using the messaging framework. See file "fpml-loan.xsd" in branch "loan", snapshot of schema directory attached

Coord feedback: We’ll need to check with Bhavik but from a business perspective, the working group felt that the first priority should be to develop the notices in FpML instead of a loan model.

Coord feedback: Regarding the messaging, the feedback will be send to the group.

Commodity WG update.We have mixed equity / commodity baskets, support for commodity underlyers in public FpML would be welcome.

Coord feedback: The Commodity Working Group hasn’t met for a while. Elaine is very busy and we may have to look for a new chair. It would be good to have support for commodity underlyers. In addition, the commodity underlyers should have enough granularity to identify different basket components.

1.3 Basket nesting. We do not allow basket nesting at present, so we cannot have a basket which contains a basket, and can only support cases such as the above, where all baskets are "flattened"

            Coord feedback: Agreement to welcome proposals on this. Andrew Parry is working on a proposal to support basket nesting. 

 

1.4 Synthetic underlyers. These are underlyers whose payoff is determined by a formula, mutualFund is the closest present FpML type. How do other group members handle synthetic underlyers and other private funds?

            Coord feedback: Robert said that he used mutualFund as well to represent such underlyers.

 

 

2.       Cancellation of Contract events. Coord feedback:

a.       The message introduces confusion between cancellation of a message and cancellation of business event. Theoretically, in FpML you could send multiple messages for the same event. The purpose of this message is to cancel the business event. In the CUG, they are equivalent but this is not true for other implementations.

b.       There shouldn’t be a single message covering all business event cancellations. In the FpML 4.x series there is a message type per business event, these cancellation messages should follow the same pattern for consistency and there should have a message per type of cancellation (ContractPartialTerminationCancelled, ContractNovationCancelled,…).

c.       The additionalData structure is not a good construct to report the original even that is being cancelled since there isn’t control over its content. The content of the business event may be referenced optionally.

d.       The proposal should be reworked accordingly.

 

 

Please, let me know if I missed anything.

 

Kind Regards,

-Marc

+13472846531

 

 

************************************************************************************************************************** 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 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. **************************************************************************************************************************