|
Randy / All – see my comments below regarding
the Lot Level processing After
reviewing this document regarding Identifying Swaps at the Lot Level,
I do not believe that the process you describe warrants identifying Swaps at
the lot level. This is simply an increase to the original contract. Some
questions/comments to several of the points within the document - Narrative
point #6 - references the use of a ContractCreate. The ContractIncrease
event/message is more appropriate, as you indicate that all of the Swaps
attributes are consistent with the original ContractCreate. IM
should send a ContractIncrease
message here. Narrative
point #7 - here you indicate the dealer is assigning a new ID to the
allocation (123001 in your example). To me this is inconsistent use of
the data point. In Narrative point #3, the dealer is creating ids in
their system at the Allocation level, and is assigning their own Contract
ID, which is understood. But in point #7, it seems the dealer is needing
to separate this transaction/event from the original, and is trying to do it
with a new Contract ID. But the Contract ID is not changing here.
If the dealer needs to recognize this event as a new event
("transaction") on the internal systems, the dealer should reference
the versioned contract id to recognize this as a new event on the existing
contract. They should not create a new contract id here. One
note on the Assertions: As a general question - in a perfect world
- after a contract has been created, and subsequently had an increase event...upon
the next payment period, wouldn't there still be only one payment made at the
allocation level between counterparties? Thus
regarding assertion #2 - Why would two payments be made here for Fund A? All comments welcome. Norman Papazian State Street Corporation p 617-937-6430 c 617-888-2012 norman.papazian@xxxxxxxxxxxxxxx From:
im-custodian@xxxxxxxx [mailto:im-custodian@xxxxxxxx] On Behalf Of Magdaluyo, Randy C All, Per item #2, here is a write-up that
explains the tax lot issue. First, if we understand and agree the need to
identify swaps at the lot level, then later we can focus on the solution
– i.e., how the contractId should be represented, whether the FpML schema
should be extended, whether recipients should convert the sender’s
contractId of any length, and what the downstream impact would be on operations
and systems. This will also be posted in the SWIFTNet
FpML space on swiftcommunity.net. Please have a look so we can discuss at
the 5 March meeting. Regards, ___________________________ Randy C.
Magdaluyo Vice President Investor
Technology Services State Street
Corporation W:
+1.949.932.1644 M:
+1.949.232.5330 E: rcmagdaluyo@xxxxxxxxxxxxxxx From: Us: 888 481 3032 Non US: 617 801 9600 Code: 28413758 Agenda ====== 0) New chairs 1) Re-statement
of scope of this WG and relationship with other FpML WGs. 2) Tax lot information
in notification messages. 3) Adding an
optional notional amount to the ContractFullTermination message 4) Clean or
dirty pricing processing indicator in a trade notification. Only
"clean" pricing allows interest accrual calculations at custodians.
"Dirty" pricing, for example, can relate to contracts involving
Developing Country currencies. 5) Recommended
elements in a long-form contract notification. 6) Comment on
proposal to use a fixed party->account->accountIdScheme on SwiftNet FpML
to identify the account number at the custodian. 7) Frequency of
conference calls. 8) AOB From: Dial in details for the meeting on Wednesday February 20 at
11:00 a.m. Us: 888 481 3032 Non US: 617 801 9600 Code: 28413758 Agenda ====== 9) New chairs 10) Re-statement
of scope of this WG and relationship with other FpML WGs. 11) Tax lot
information in notification messages. 12) Adding an
optional notional amount to the ContractFullTermination message. 13) Frequency of
conference calls. 14) AOB Best Regards, -Marc +13472846531 **************************************************************************************************************************
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 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. ************************************************************************************************************************** |