Next meeting: May 12, 2005
4.2 First Working Draft will be published next week.
April 28, 2005
Attendees
---------------
Brock Arnason (Morgan Stanley)
Bill Hodgson (DTCC)
Brian Lynn (GEM)
Henri Pegeron (ISDA)
Marc Gratacos (ISDA)
Regrets
-----------
Matthew Rawlings (JP Morgan Chase)
Marc Teichman (DTCC)
Rajeev Kotyan (Sonic Software)
Review of proposals
-----------------------------
1. Allocations Linking Mechanism
Approved to be published in version 4.2 first working draft.
The only remaining issue was the support for N-Level allocations as
requested by Brian Lynn. In the previous 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. Participants in the meeting agreed on
adding blockTradeId inside BlockTradeIdentifier instead of creating a
separate type.
2. Messages for AllocationCreated, AllocationAmended, AllocationCancelled
Approved to be published in version 4.2 first working draft.
There were two remaining issues. The first one was to represent to
original trade details. Participants agreed on that. The second issue was
that the existing TradeAmended message doesn’t contain original trade
details. Participants agreed on leaving the TradeAmended message as it is
for not breaking backward compatibility but to ask for feedback regarding
this issue in the specification.
3. Allocations (“Short-form” representation)
Approved to be published in version 4.2 first working draft.
Two remaining items were discussed:
- Make collateral element optional: Brock said that we would need
to have a strong argument to make this element optional. We need to follow
up with Marc Teichman to see reasons to make it optional.
- RequestAllocation message: it looks good but we would need to
get input from Marc Teichman in order to document the context in which
this message would be used and define the expected response (if any).
4. Accounts
No discussion around it. Approved to be published in version 4.2 first
working draft.
5. TradeSide structure
Approved to be published in version 4.2 first working draft.
The agreement was to publish the proposal as it is but asking for feedback
in the specification regarding the need of deprecation of
brokerPartyReference. Since there wasn’t an agreement on doing that, we
decided that it would be good to publish the tradeSide element and ask for
feedback.
6. Option Exercise
It was not approved to be published in the 4.2 first working draft but we
would like to publish it in the second one.
Participants had the feeling that even though the proposal is a very good
start and probably contains all necessary information it still needs more
work.
Feedback:
- Naming “option” element - it’s more a reference to an
existing option trade. A suggestion was to name it “originalTrade”
- Create a container called exerciseCharacteristics containing
the timing information and whether the option exercise is full or partial.
- Do we need the information of the underlying asset if it is a
full exercise? Participants don’t think so. Asset information should be
contained inside “partial” element.
- Reuse the existing underlying asset elements instead of
creating a new asset component and add effective/termination dates if
necessary. Should these dates be adjusted or not?
- In case of physical settlement, after the option exercise
notification, should we send a message back with the updated product
information? - in case of Bermudan options the start date is relative to
the exercise date.
Best Regards,
-Marc
_____
From: Marc Gratacos [mailto:MGratacos@xxxxxxxx]
Sent: Monday, April 25, 2005 4:15 PM
To: mwg@xxxxxxxxxxxxxxxxxxxxxx
Subject: FpML-MWG40 recap - proposals to be approved
Importance: High
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>>