All,
We will have a call next Thursday April 28, 2005 at 10:00 AM as usual.
On Monday, the coordination committee approved the publication of a
working draft for 4.2 by the end of this month. This Working Draft will be
published in order to include all proposals agreed by the MWG. Publication
of a working draft I think is good in order to get attention and feedback
from other FpML participants.
These are the proposals I think we could include in this first working
draft:
1. Allocations Linking Mechanism (also called long form allocations)
- this was approved 4 months ago by the MWG in order to support allocation
confirmation. See Allocations_Linking_Mechanism_v50.doc
a. Including support for N-Level allocations as requested by Brian
Lynn. In the last meeting, we mentioned that we could use the proposed
BlockTradeIdentifier type to accommodate both, references to the allocated
trades and references to the block trades instead of creating a separate
type. Do we agree on this? Or do we prefer a separate type to handle the
N-Level situation as Brian proposed initially? Reviewing this I think it
would be clearer to have a separate type for this.
2. Messages for AllocationCreated, AllocationAmended,
AllocationCancelled - See Allocations_Generic_Messages_v30.doc
a. Providing the flexibility to specify tradeId of the original trade
or the original trade details in order to identify in recipient's system
for amendments and cancels. See file AllocationAmended.jpg. This was
requested by Brian Lynn. In the FpML training course, speaking with an
attendant from a hedge fund, he requested the same thing. Matthew Rawlings
said that he detected different ways to implement the process and that
this reduced interoperability. On the other hand, Kedar Kodlapur (Lehman)
agrees on Brian’s proposal according to feedback received by internal
implementations.
i. If
we agree to represent to original trade details, the question is then,
what about the existing TradeAmended message? Should we provide the
information about the original trade as well? Right now, they just detail
the new trade information.
3. Allocations (“Short-form” representation) - agreed to represent
this within the trade definition in order to use this form of
representation across the different post-trade messages. Some minor
changes have been made using feedback from the last meeting. See
trade-allocations.jpg Treatment of fees is not very explicit right now but
maybe we need to work on this in the future.
a. Marc Teichman is proposing a message using Brock’s “short-form”
representation with a reference to the trade instead of sending the whole
trade details. He has some valid suggestions regarding the Allocation
type. See RequestAllocation.jpg
4. Accounts - agreed on representing them within the party
information. No discussion around.
5. tradeSide structure (roles) - See trade-tradeSide.jpg file. It has
been discussed for three months. Agreed to represent it within the trade
definition. Please, look at the description of the different roles.
Examples have been distributed to the WG.
a. New tradeSide structure could replace the existing
brokerPartyReference elements. I think the new tradeSide actually improves
the existing brokerPartyReference. Why? You are allowed to specify
multiple brokerPartyReference elements but there is not a relationship
expressed between the broker and the associated party. On the other hand,
tradeSide allows us to do that. The remaining issue is whether we should
deprecate the brokerPartyReference element.
6. Option Exercise - Matthew sent a proposal about Option Exercise.
See OptionExerciseNotification.jpg. Guy Gurden sent some feedback and the
proposal was updated. We haven’t discussed this proposal yet in a formal
meeting but it would be worth trying to incorporate it in the working
draft. Please, look at the proposal and send your comments to the group.
We’ll discuss this in the next meeting.
I am attaching a schema and examples including ALL proposals described
above (xml.zip).
If you don’t agree with any of these proposals, please send your comments
to the list and try to put together an alternative proposal. Otherwise,
these proposals will be published in the first working draft.
Best Regards,
-Marc
+1-212-901-6028
<<attachment: winmail.dat>>