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

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

The next call will be next Friday, July 16th 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 (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, Marc’s minutes 6/18)

·         AOB

 

Thanks,

Lyteck

ISDA


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

Please find the minutes for today’s July 2 meeting. Let me know if I missed anything.

 

Participants

1.       Brian Lynn (GEM)

2.       Sreedhar Segu (DTCC)

3.       Tom Brown (OMGEO)

4.       John Avery (Sungard)

5.       Chris Funck (Chatham)

6.       Marc Gratacos (ISDA)

7.       Irina Yermakova (ISDA)

8.       Lyteck Lynhiavu (ISDA)

 

Apologies:

1.       Matt Simpson (CME)

 

 

DTCC's proposal (Cash flow matching for multiple trades)

  • Sreedhar added new sample messages based on previous group discussions:
    • messages for Credit and Equity (see Marc’s zip sent 7/02)
    • sample for multiple trades/multi-currency trades: can express one message for each currency or multiple currencies in the same message. The model is flexible and can accommodate different implementations (including single or multiple products).
  • Marc added the schema and example messages to the FpML subversion repository
    • The \trunk is now updated for FpML 4.9
    • Note the distributed schema does not contain the usual -4-9 in the filename as it was taken directly from the \source
    • For consistency, added a couple of messages which were already in the cashflows but added them to the netted cashflows for multiple trades: NettedTradeCashflowsAsserted contains one or many tradeIdentifyingItems can be referenced in grossCashflow.

·         The proposal can be published in 4.9 WD1 before the end of July pending the à completion of additional sample response messages (results, assertion) and the creation of documentation around messages (Action Item)

    • 4.9 and 5.1 will be in sync. à Marc will add the proposal to 5.1
    • 4.9 Recommendation is planned towards the end of 2010

CME's proposal

  • Brian discussed the analysis he sent 6/23 around the existing payment types (SimplePayment, PaymentMatching) and how they could be modified accommodate CME’s proposal.

o    It seems feasible to be able to combine the existing content of the types using xsd:group to create a model for the CME proposal.

o    There are several implementation options which Brian outlined in his email (see 3.a and 3.b)

o    Another option included making use of type restriction (create a base type with optional paymentDate and restrict the model in PaymentMatching) but it is not recommended in the FpML Architecture Specification. (not all binding frameworks support restriction and break when creating jar from the schema)

  • à We’ll need to discuss whether we want to make the proposed date adjustable There would be advantages to have consistency between the SimplePayment and PaymentMatching types
    • We’ll wait until Matt Simpson can be on the call to discuss implementation further

 

Upcoming work

·         the group will focus on Option Exercise/Expiry after the DTCC and CME proposals are implemented.

 


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