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

[harry.mcallister@xxxxxxxxxxxxxxxxx]

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.

Attachment: stratcashflowfinal111604.pdf
Description: Binary data

Attachment: fpml-reconciliation-4-7.NettedTradeCashflows.xsd
Description: Binary data