FpML-BP Teleconference Friday July 30 @ 11am New York / 4pm London

FpML-BP Teleconference Friday July 30 @ 11am New York / 4pm London - Reminder

To: "bpwg@xxxxxxxx" <bpwg@xxxxxxxx>

Subject: FpML-BP Teleconference Friday July 30 @ 11am New York / 4pm London - Reminder

From: Lyteck Lynhiavu <LLynhiavu@xxxxxxxx>

Date: Thu, 29 Jul 2010 12:12:15 -0400

Accept-language: en-US

Acceptlanguage: en-US

Cc: "rptwg@xxxxxxxx" <rptwg@xxxxxxxx>

Reply-to: bpwg@xxxxxxxx

Sender: bpwg@xxxxxxxx

Thread-index: AQHLGZwNCl5dNqFA2kOCcO3TAJrKP5KooXcggAAFBVCACa6CoIAVq6XAgAADgJA=

Thread-topic: Teleconference Friday July 30 @ 11am New York / 4pm London - Reminder

Reminder – We’ll have a call tomorrow Friday, July 30^th at 11am New York / 4pm London

Dial in Details:

US Dial-in: 888-481-3032

UK Toll Free: 0800 904 7961

International Dial-in: 617-801-9600

Passcode: 28413758

We'll give an update on the Cash Flow matching deliverables, discuss implementation of the Payment message types and tackle Option Exercise/Expiry.

Members of the Reporting WG interested in these topics please join the call.

Draft Agenda:

· DTCC's Gross Cash Flow proposal (status of schema, example, documentation for publication in 4.9/5.1 wd1)

· CME's proposal on payment calculations for reporting (see: Matt’s “Payments […].doc”, Brian’s “Payment message types” email 6/23)

· Option Exercise/Expiry (see: fpml-business-events.xsd, ExerciseSettlement.png, optionExpiry.png, optionExercise.png)

Thanks,

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.

--- Begin Message ---

To: "bpwg@xxxxxxxx" <bpwg@xxxxxxxx>, "rptwg@xxxxxxxx" <rptwg@xxxxxxxx>
Subject: FpML-RPTWG Payment message types
From: Brian Lynn <brian.lynn@xxxxxxxxxxxxxxxxxxx>
Date: Wed, 23 Jun 2010 10:10:58 -0400
Reply-to: "rptwg@xxxxxxxx" <rptwg@xxxxxxxx>
Sender: "owner-rptwg@xxxxxxxx" <owner-rptwg@xxxxxxxx>
Thread-index: AcsS3eZUL9JaLyb1TeqvbRp9Djo+mg==
Thread-topic: FpML-RPTWG Payment message types

At last week’s meeting I said that I would send an email describing what I had found with the different payment message types, to show how Matt’s proposed payment type extension might fit in.

There are a couple of existing similar payment types in FpML that should be kept a consistent as possible. I’ve omitted the annotations for clarity:

SimplePayment – in fpml-shared.xsd

<xsd:complexType name="SimplePayment">

<xsd:sequence>

<xsd:group ref="PayerReceiver.model"/>

<xsd:element name="paymentAmount" type="Money"/>

<xsd:element name="paymentDate" type="AdjustableOrRelativeAndAdjustedDate"/>

</xsd:sequence>

</xsd:complexType>

PaymentMatching – fpml-reconciliation.xsd – this is the basis of Matt’s proposal.

<xsd:complexType name="PaymentMatching">

<xsd:sequence>

<xsd:element name="identifier" type="PaymentId"/>

<xsd:group ref="PayerReceiver.model"/>

<xsd:element name="paymentAmount" type="Money"/>

<xsd:element name="calculationDetails" type="CalculationDetails" minOccurs="0" maxOccurs="unbounded"/>

</xsd:sequence>

</xsd:complexType>

Matt proposes to add “adjustedPaymentDate” to the Payment Matching structure.

To keep these as similar as possible, to be consistent with the existing types:

1) the payment date should appear after the payment amount

2) to make it more consistent with SimplePayment, it should perhaps be called “paymentDate” and allow adjustable dates as well as or instead of just adjusted payment dates. (we should perhaps discuss this)

3) there’s some opportunity for reusing the definitions. Some possibilities include:
a) create a PaymentMatchingBase type that holds the first 3 elements/groups, and extend from that
b) create a PaymentMatchingModel group that also holds the same 3 elements, and us that in both type definitions.

--- End Message ---

Attachment: Payments for Position Reporting Proposal.doc
Description: Payments for Position Reporting Proposal.doc

Attachment: optionExercise.png
Description: optionExercise.png

Attachment: optionExpiry.png
Description: optionExpiry.png

Attachment: ExerciseSettlement.png
Description: ExerciseSettlement.png

Attachment: fpml-business-events.xsd
Description: fpml-business-events.xsd