OK, looks like I lose this one. Make it optional.
-Brock
_____
From: Ira Fuchs [mailto:ifuchs@xxxxxxxxxxxxxxxxx]
Sent: Tuesday, May 03, 2005 8:39 PM
To: mwg@xxxxxxxxxxxxxxxxxxxxxx
Subject: RE: FpML-MWG40 allocations - comments on making collateral
element mandatory
I agree with this point of view. Well stated.
Ira Fuchs
_____
From: Brian Lynn [mailto:brian.lynn@xxxxxxxxxxxxxxxxxxx]
Sent: Tuesday, May 03, 2005 7:41 PM
To: mwg@xxxxxxxxxxxxxxxxxxxxxx
Subject: RE: FpML-MWG40 allocations - comments on making collateral
element mandatory
I believe that this should be optional because not all products will
require collateral at the allocation level. Some examples might include
clients that aren’t required to post collateral, products that aren’t
collateralized (e.g. securities), or products that are collateralized at
some aggregate position level rather than at an individual trade level.
While I agree that these cases may be less common than the collateralized
case, I think it’s bad style to require an element to be present just
because it’s usually required by a particular business process. If a
particular application requires this element to be present, the
application should have a business rule to enforce this.
Note that this is my opinion as a software architect, and it may be in
conflict with the approach mandated by some of my clients for standards
that I have authored.
Brian Lynn, CTO
Global Electronic Markets, <http://global-emarkets.com>
http://global-emarkets.com
High-speed FpML matching, reconciliation, and validation:
<http://fpml-mediator.com> http://fpml-mediator.com
_____
From: Marc Gratacos [mailto:MGratacos@xxxxxxxx]
Sent: Tuesday, May 03, 2005 6:29 PM
To: mwg@xxxxxxxxxxxxxxxxxxxxxx
Subject: RE: FpML-MWG40 allocations - comments on making collateral
element mandatory
Importance: High
All,
We haven’t received more feedback besides comments from Marc Teichman and
Brock.
What should we do here? Leave it mandatory or change it to optional.
Please, let me know your opinion before tomorrow afternoon.
Thanks a lot,
-Marc
_____
From: Marc Teichman [mailto:mteichman@xxxxxxxx]
Sent: Monday, May 02, 2005 6:26 PM
To: mwg@xxxxxxxxxxxxxxxxxxxxxx
Subject: RE: FpML-MWG40 allocations - comments on making collateral
element mandatory
We definitely need to allow for the case where there is no up-front
collateral.
"Arnason, Brock \(FID\)" <Brock.Arnason@xxxxxxxxxxxxxxxxx>
05/02/2005 06:05 PM
Please respond to mwg
To: <mwg@xxxxxxxxxxxxxxxxxxxxxx>
cc: (bcc: Marc Teichman/DTCC)
Subject: RE: FpML-MWG40 allocations - comments on making
collateral element mandatory
I agree that #1 is a much stronger argument than #2. Managing collateral
on a per-client rather than per-account basis is not only a poor risk
model, but fails to meet regulatory requirements. My argument for
retaining this as a required attribute reduces to its cardinal importance
to risk management.
Single trades may hold this attribute optional due to the large number of
cases where upfront collateral is irrelevant (broker trades, interdesk
trades, etc.). I don't see those cases where you deal with an allocated
(client-facing) trade.
Sincerely,
Brock
_____
From: Marc Gratacos [mailto:MGratacos@xxxxxxxx]
Sent: Monday, May 02, 2005 5:57 PM
To: mwg@xxxxxxxxxxxxxxxxxxxxxx
Subject: FpML-MWG40 allocations - comments on making collateral element
mandatory
All,
Please see comments from Marc Teichman regarding collateral element within
allocation.
I do feel strongly about collateral being optional for two reasons:
1. It is altogether optional for a trade, why should it be required
on an allocation? There may in fact not be any collateral requirement for
the deal at all. I feel that this is a very strong argument.
2. It is conceivable that collateral will be specified on the block
and allocated pro rata, obviating the need to specify this on the
individual allocations. I know that some have argued that the collateral
will always be specified only on the individual allocation but I don't
think that this practice is universal.
Let me know your comments.
Best regards,
-Marc
_____
From: Marc Teichman [mailto:mteichman@xxxxxxxx]
Sent: Monday, May 02, 2005 5:21 PM
To: Marc Gratacos
Cc: Robert Green
Subject: Re: FW: FpML-MWG40 minutes meeting 04/28
Marc,
Thanks, my vacation was great as vacations usually are!
The following should address the open items:
RequestAllocation is used to request an allocation of a previously
communicated block trade. It references the block trade and provides the
individual allocations. The expected response would have the same content
as the AllocationCreated message which is currently modeled as an A2A
Notification Message. AllocationCreated will work fine for us, though
others may want an explicit Response Message.
I do feel strongly about collateral being optional for two reasons:
3. It is altogether optional for a trade, why should it be required
on an allocation? There may in fact not be any collateral requirement for
the deal at all. I feel that this is a very strong argument.
4. It is conceivable that collateral will be specified on the block
and allocated pro rata, obviating the need to specify this on the
individual allocations. I know that some have argued that the collateral
will always be specified only on the individual allocation but I don't
think that this practice is universal.
I see that you've brought the allocationTradeId within
BlockTradeIdentifier more in-line with the allocationTradeId within
Allocation. However, I was wondering why there was still a slight
difference in that one is of type TradeIdentifier and one is of type
PartyTradeIdentifier.
Thanks and Best Regards,
Marc
"Marc Gratacos" <MGratacos@xxxxxxxx>
05/02/2005 01:03 PM
To: Marc Teichman <mteichman@xxxxxxxx>
cc:
Subject: FW: FpML-MWG40 minutes meeting 04/28
Marc,
Hope you had a very good vacation. I need to follow up with you for a
couple of items regarding the MWG meeting we had on Thursday (see minutes
below).
- “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)”.
- “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.”
Let me know your comments or post them to the mailing list. I am going to
publish the first draft for 4.2 this Wednesday so if we don’t have an
agreement we’ll make changes (if necessary) in the next draft. We are
planning to publish the next draft at beginning of June. For this draft,
RequestAllocation message is included and collateral element is mandatory.
Thanks a lot,
-Marc
_____
From: Marc Gratacos [mailto:MGratacos@xxxxxxxx]
Sent: Thursday, April 28, 2005 5:02 PM
To: mwg@xxxxxxxxxxxxxxxxxxxxxx
Subject: FpML-MWG40 minutes meeting 04/28
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
_____
This is not an offer (or solicitation of an offer) to buy/sell the
securities/instruments mentioned or an official confirmation. Morgan
Stanley may deal as principal in or own or act as market maker for
securities/instruments mentioned or may advise the issuers. This is not
research and is not from MS Research but it may refer to a research
analyst/research report. Unless indicated, these views are the author's
and may differ from those of Morgan Stanley research or others in the
Firm. We do not represent this is accurate or complete and we may not
update this. Past performance is not indicative of future returns. For
additional information, research reports and important disclosures,
contact me or see <https://secure.ms.com/servlet/cls>
https://secure.ms.com/servlet/cls. You should not use e-mail to request,
authorize or effect the purchase or sale of any security or instrument, to
send transfer instructions, or to effect any other transactions. We cannot
guarantee that any such requests received via e-mail will be processed in
a timely manner. This communication is solely for the addressee(s) and may
contain confidential information. We do not waive confidentiality by
mistransmission. Contact me if you do not wish to receive these
communications. In the UK, this communication is directed in the UK to
those persons who are market counterparties or intermediate customers (as
defined in the UK Financial Services Authority's rules).
_____
This is not an offer (or solicitation of an offer) to buy/sell the
securities/instruments mentioned or an official confirmation. Morgan
Stanley may deal as principal in or own or act as market maker for
securities/instruments mentioned or may advise the issuers. This is not
research and is not from MS Research but it may refer to a research
analyst/research report. Unless indicated, these views are the author's
and may differ from those of Morgan Stanley research or others in the
Firm. We do not represent this is accurate or complete and we may not
update this. Past performance is not indicative of future returns. For
additional information, research reports and important disclosures,
contact me or see https://secure.ms.com/servlet/cls. You should not use
e-mail to request, authorize or effect the purchase or sale of any
security or instrument, to send transfer instructions, or to effect any
other transactions. We cannot guarantee that any such requests received
via e-mail will be processed in a timely manner. This communication is
solely for the addressee(s) and may contain confidential information. We
do not waive confidentiality by mistransmission. Contact me if you do not
wish to receive these communications. In the UK, this communication is
directed in the UK to those persons who are market counterparties or
intermediate customers (as defined in the UK Financial Services
Authority's rules).
<<attachment: winmail.dat>>