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

RE: FpML-RPTWG Re: FpML-BP Cash flow Matching, Netting and Settlement Guidelines



Sreedhar,
 
Do you think it would be possible to create a complete example message?
 
Thanks,
Marc
 

From: owner-rptwg@xxxxxxxx [owner-rptwg@xxxxxxxx] On Behalf Of Sreedhar Segu [ssegu@xxxxxxxx]
Sent: Monday, June 07, 2010 5:20 PM
To: Sreedhar Segu
Cc: bpwg@xxxxxxxx; rptwg@xxxxxxxx
Subject: FpML-RPTWG Re: FpML-BP Cash flow Matching, Netting and Settlement Guidelines

Hi All,
As agreed in our previous BP/RPT WG discussion we will go with Option 1 approach. However it requires minor modification

Option 1 approach:

  • Added NettedTradeCashflows.model in fpml-reconciliation-4-8.xsd. (tradeIdentifyingItems will be defined unbounded in this structure).
  • Added NettedTradeCashflowsAsserted complex type in the fpml-reconciliation-4-8.xsd which will have similar structure as TradeCashflowsAsserted except TradeCashflows.model is replaced with NettedTradeCashflows.model
  • Added PartyTradeIdentifierReference complex type in fpml-shared-4-8.xsd
  • Added partyTradeIdentifierReference element of type PartyTradeIdentifierReference  in GrossCashflow complex type  in the fpml-reconciliation-4-8.xsd
(Please see fpml-reconciliation-4-8_NettedTradeCashflowsAsserted.xsd, fpml-shared-4-8_NettedTradeCashflowsAsserted.xsd schemas).

(See attached file: fpml-reconciliation-4-8_NettedTradeCashflowsAsserted.xsd)(See attached file: fpml-shared-4-8_NettedTradeCashflowsAsserted.xsd)

Thanks,
Sreedhar.
------------------------------------------------------------
The Depository Trust & Clearing Corporation
DTCC : Business Analysis & Design
55 Water Street - New York, NY 10041
Office : 212 855 2364

Inactive hide details for Sreedhar Segu/DTCCSreedhar Segu/DTCC


          Sreedhar Segu/DTCC

          06/02/2010 03:36 PM


To

bpwg@xxxxxxxx

cc

rptwg@xxxxxxxx

Subject

Re: FpML-BP Cash flow Matching, Netting and Settlement GuidelinesSreedhar Segu
Hi All,
In continuation with the previous BP/RPT WG meeting discussion, I am attaching modified schemas to implement NettedTradeCashflowsAsserted.
As proposed and agreed by the WG members changes to the existing TradeCashflowsAsserted structure are kept minimum.

Following are the required changes to implement NettedTradeCashflowsAsserted.

Option 1:

• Added NettedTradeCashflowsAsserted complex type in the fpml-reconciliation-4-8.xsd which will have similar structure as TradeCashflowsAsserted.
• Added PartyTradeIdentifierReference complex type in fpml-shared-4-8.xsd
• Added partyTradeIdentifierReference element of type PartyTradeIdentifierReference in GrossCashflow complex type (fpml-reconciliation-4-8.xsd).
(Please see fpml-reconciliation-4-8_NettedTradeCashflowsAsserted.xsd, fpml-shared-4-8_NettedTradeCashflowsAsserted.xsd schemas).

Option 2:

• Added NettedTradeCashflowsAsserted complex type in the fpml-reconciliation-4-8.xsd which will have similar structure as TradeCashflowsAsserted.
• Added partyTradeIdentifier element of type PartyTradeIdentifier in GrossCashflow complex type in the fpml-reconciliation-4-8.xsd
(Please see fpml-reconciliation-4-8_NettedTradeCashflowsAsserted_partyTradeIdentifier.xsd schema).

As suggested by Harry, Option 1 looks more promising than option 2.

Harry, in your suggestion below to implement NettedTradeCashflowsAsserted, why do we need to "Create a group NettedTradeCashflows.model, identical to TradeCashflows.model except for multiple (unbounded) occurrence of tradeIdentifyingItems". "partyTradeIdentifier" element in tradeIdentifyingItems is already unbound. So probably we can use one tradeIdentifyingItems element and multiple partyTradeIdentifier elements. Your thoughts?

Also attaching initial DTCC proposal to add tradeId element in the GrossCashflow section as well as ISDA Cashflow Matching, Netting and Settlement Guidelines for reference.


(See attached file: FpML Proposal.docx)(See attached file: stratcashflowfinal111604.pdf)

Thanks,
Sreedhar.
------------------------------------------------------------
The Depository Trust & Clearing Corporation
DTCC : Business Analysis & Design
55 Water Street - New York, NY 10041
Office : 212 855 2364

Inactive hide details for Sreedhar Segu/DTCCSreedhar Segu/DTCC


          Sreedhar Segu/DTCC

          05/28/2010 01:45 PM


To

bpwg@xxxxxxxx

cc

mgratacos@xxxxxxxx

Subject

Re: FpML-BP Cash flow Matching, Netting and Settlement GuidelinessSreedhar Segu
Harry,
Your proposal looks interesting and make sense to me. I will try to work using this approach.

Thanks for your thoughts.

Thanks,
Sreedhar.
------------------------------------------------------------
The Depository Trust & Clearing Corporation
DTCC : Business Analysis & Design
55 Water Street - New York, NY 10041
Office : 212 855 2364

Inactive hide details for harry.mcallister@xxxxxxxxxxxxxxxxxharry.mcallister@xxxxxxxxxxxxxxxxx


          harry.mcallister@xxxxxxxxxxxxxxxxx
          Sent by: bpwg@xxxxxxxx

          05/28/2010 01:18 PM

          Please respond to
          bpwg@xxxxxxxx


To

bpwg@xxxxxxxx

cc

mgratacos@xxxxxxxx

Subject

Re: FpML-BP Cash flow Matching, Netting and Settlement Guideliness


All,

Please see attached a (very) draft proposal for a revised "NettedTradeCashflowsAsserted" message structure, to support assertion of cashflows netted across multiple trades. The proposal is presented in the expectation of criticism and further modification (I don't lay any claims to expertise in the cashflow matching domain).

Changes to the existing TradeCashflowsAsserted structure are kept to a minimum, consistent with supporting the extended functional requirement:
    • Created group NettedTradeCashflows.model, identical to TradeCashflows.model except for multiple (unbounded) occurrence of tradeIdentifyingItems
    • Created complex type PartyTradeIdentifierReference, a reference element intended to point to an instance of PartyTradeIdentifier (almost surprised we don't have this in the standard already ...).
    • Modified complex type GrossCashflow, adding optional element partyTradeIdentifierReference, following cashflowId.
I considered specialising GrossCashflow to restrict the existence of partyTradeIdentifierReference to the "Netted" message, but this would require creation of new types for each component of the PaymentMatching/CalculationDetails/GrossCashflow type hierarchy, with little obvious benefit (the presence of an optional, single-valued grossCashflow/partyTradeIdentifierReference within the non-netted message is not obviously harmful).

In the proposed use, a single tradeIdentifyingItems block would be produced for each trade against which payments are asserted for reconciliation, for example:

<tradeIdentifyingItems>
<partyTradeIdentifier id="aardvark">
<partyReference href="DTCC00006440"/>
<tradeId tradeIdScheme="TradeRefNbr">0000000001000000</tradeId>
</partyTradeIdentifier>
</tradeIdentifyingItems>
    • Note the addition of the id attribute on partyTradeIdentifier - I have used a nonsense value to emphasise that the id/href value must not be processed as business content - in practice, the id would likely be auto-generated from the trade identifier, for ease of implementation and to guarantee uniqueness.

Then a cashflow referencing the identified trade as its parent would look like:

<grossCashflow>
<cashflowId>Trade1354248_2318819</cashflowId>
<partyTradeIdentifierReference href="aardvark"/>
<payerPartyReference href="abcref"/>
<receiverPartyReference href="xyzref"/>
<cashflowAmount>
<currency>USD</currency>
<amount>41.13</amount>
</cashflowAmount>
<cashflowType cashflowTypeScheme="http://www.fpml.org/coding-scheme/cashflow- type">AssignmentFee</cashflowType>
</grossCashflow>

This is a little neater than producing a full partyTradeIdentifier block within each grossCashflow.

I attach a copy of the modified schema (lazy implementation, all in one file - PartyTradeIdentifierReference properly belongs in fpml-shared).

Best regards,
Harry






__________________________________________________________________________

Harry McAllister
| Information Architect | Fixed Income Architecture | BNP Paribas
4R223 | 10 Harewood Avenue | London NW1 6AA

tel
: +44 (0)20 7595 3416 | email : harry.mcallister@xxxxxxxxxxxxxx


Internet
ssegu@xxxxxxxx

Sent by: bpwg@xxxxxxxx

28/05/2010 16:11

Please respond to
bpwg@xxxxxxxx

To
bpwg@xxxxxxxx
cc
rptwg@xxxxxxxx
Subject
FpML-BP Cash flow Matching, Netting and Settlement Guideliness





Thanks,
Sreedhar.
------------------------------------------------------------
The Depository Trust & Clearing Corporation
DTCC : Business Analysis & Design
55 Water Street - New York, NY 10041
Office : 212 855 2364

_____________________________________________________________

DTCC DISCLAIMER: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error, please notify us immediately and delete the email and any attachments from your system. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.

___________________________________________________________
This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is prohibited.

Please refer to
http://www.bnpparibas.co.uk/en/information/legal_information.asp?Code=ECAS-845C5H  for additional disclosures.
(See attached file: fpml-reconciliation-4-7.NettedTradeCashflows.xsd)



_____________________________________________________________
DTCC DISCLAIMER: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error, please notify us immediately and delete the email and any attachments from your system. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.


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.