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

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

REMINDER - We'll have a call today Friday, July 2nd at 11am New York / 4pm London
 
From: owner-rptwg@xxxxxxxx [owner-rptwg@xxxxxxxx] On Behalf Of Lyteck Lynhiavu [LLynhiavu@xxxxxxxx]
Sent: Tuesday, June 29, 2010 12:17 PM
To: bpwg@xxxxxxxx
Cc: rptwg@xxxxxxxx
Subject: FpML-RPTWG Teleconference July 2 Friday @ 11am New York / 4pm London

We'll have a call this Friday, July 2nd 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 continue the discussion on Cash Flow matching and Payment message types.

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

 

Draft Agenda:

-          DTCC's Gross Cash Flow proposal (schema, example, documentation) (see: Harry’s email 6/4)

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

-          AOB

 


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

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

--- Begin Message ---
Participants
Sreedhar Segu (DTCC)
Brian Lynn (GEM)
Christian Unger (BBH)
Lyteck Lynhiavu (ISDA)
John Avery (Sungard)
Marc Gratacos (ISDA)
Peter Stockman (DTCC)

Apologies
Matt Simpson (CME)
Harry McAllister (BNPParibas)
Jonathan Viljoen (Standard Bank)

DTCC's proposal
  • Sreedhar went through the example. Participants were ok with it. There were some comments on how users wold report for multi-currency trades, whether it would be reported with a message per currency or multiple currencies in the same message. It will probably depend on implementations.
  • In the previous call, Peter Stockman suggested adding an optional element to indicate how the netting for multiple trades is being done, by unit (commodity trades), by currency, by counterparty, etc.
  • Documentation needs to be added to clarify the use of the Netted cashflows vs. current trade cashflows messages.
  • Response, exception, and retraction messages need to be added for completion.
  • Sreedhar pointed that they only allow messages up to 100k so for reconciliation processes, they'd like to have a way to express whether all messages have been submitted for reconciliation and how many to expect (message number / total of messages). There is current a flag in the portfolio rec messages to indicate whether the submission is complete but not how many messages to expect.
  • The proposal of the messages will probably be included in 4.9 and 5.1.
  • Action: To create more samples (Sreedhar), documentation and remaining messages (Marc), to propose type of netting element (Peter)
CME's proposal
  • Brian took a look at the exiting payment types (SimplePayment, PaymentMatching, etc.). It seems feasible to be able to combine the existing content of the types using xsd:groups to create a model for the CME proposal.
  • Action: Brian to send existing payment types to see design of cashflow for Position Reporting.
AOB
  • In the FXWG there was an interest to create a file containing the XPath expressions of the elements to be reported in different types of reports. 
  • Action: The Reporting WG should discuss it.


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.

--- End Message ---