Brian,
I agree with your proposal on AllocationCancelled and AllocationAmended.
I think we should provide 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.
Without this it will be difficult for systems that handles cancels and
corrections as two separate trades.
Speaking to a group here at Lehman who handle Prime broker deals they
seem to receive the amendments from Prime brokers where the original
trade id is embedded within the message for reference purposes..
Kedar Kodlapur
Fixed Income Derivatives Technology
Lehman Brothers
212-526-1363
-----Original Message-----
From: Brian Lynn [mailto:brian.lynn@xxxxxxxxxxxxxxxxxxx]
Sent: Thursday, March 31, 2005 7:15 PM
To: mwg@xxxxxxxxxxxxxxxxxxxxxx
Subject: RE: FpML-MWG40 AllocationAmended, AllocationCancelled -
feedback
I agree with Matthew's theory - a single clean method is best in theory.
However, the issue I am having is with dealing with legacy systems that
may not be able to support linking of old versions of trades with new
versions, because all they support is cancel and rebook. It will be
necessary in these cases to provide them a hint of what is changed, at
least the ID of the old trade. In the application we have we can't
assume that the recipient can build a linking database. So the message
will need to provide this linking.
Brian Lynn, CTO
Global Electronic Markets, http://global-emarkets.com High-speed FpML
matching, reconciliation, and validation: http://fpml-mediator.com
-----Original Message-----
From: matthew.d.rawlings@xxxxxxxxxxxx
[mailto:matthew.d.rawlings@xxxxxxxxxxxx]
Sent: Thursday, March 31, 2005 6:21 PM
To: mwg@xxxxxxxxxxxxxxxxxxxxxx
Subject: Re: FpML-MWG40 AllocationAmended, AllocationCancelled -
feedback
MWG - Brian's first point should be covered by the principle agreed at
the last meeting: we always provide the option to correlate by
identifier or by the entire trade but never a partial trade that
requires matching. This supports Brian's first need. (I support it).
Marc - did this get written up in the minutes? Perhaps we need to
introduce a normative messaging artifact to capture these decisions? The
decision to put this into the Architecture spec (my suggestion
admittedly) seems to be a recipe for cross-group coordination issues.
MWG - The allocation problem Brian describes is a good example of what
happens because we don't specify normatively how to correlate messages,
the state machine for a trade lifecycle, nor the concurrent interaction
between parties. (We have 3 missing specs: correlation/identity, state
machine, messaging concurrency). I personally have found 6 different and
incompatible ways to implement amendments in the past few months - see
the attached.
(See attached file: FpMLMethodsOfCorrectingATrade.xls)
We have a choice between (1) supporting all the different
interpretations of the messages, and (2) standardizing on one
interpretation. As I understand it Brian has asked us to support
additional interpretations but to improve the situation by making the
interpretation explicit. I respectfully argue we gain more by having one
standard way of doing amendments - the systems become interoperable.
I raised this point a few weeks ago and the question was directed to the
AWG. Perhaps we bundle these items as they are the same issue at root?
I completely agree with Brian that this is a real-world issue.
Matthew
Brian Lynn
<brian.lynn@global-em To:
mwg@xxxxxxxxxxxxxxxxxxxxxx
arkets.com> cc:
Subject: FpML-MWG40
AllocationAmended, AllocationCancelled - feedback
31/03/2005 21:03
Please respond to mwg
The MWG recently created messages to create, modify, and cancel trade
allocations. I have two suggestions for enhancing these.
AllocationCancelled
===============
For the message to cancel allocations (AllocationCancelled), it would be
useful if there were a choice between supplying the whole trade and just
supplying the trade ID. (I guess we would use the
"partyTradeIdentifier" form of the trade ID). This would allow
supporting the case where the recipient of the message needs only the ID
of the trade to know what to cancel.
AllocationAmended
==============
The message to modify trade allocations (AllocationAmended) simply gives
the new trade information, and implies that the receiver should be able
to identify the modified trade based on the trade ID of the newly
modified trade. In other words, it assumes that the trade ID of the
original and the modified trade are the same.
In discussions with various prime brokers, it has become clear that
practices for handling this situation vary between PBs and across asset
classes, and even in some cases depending on timing (e.g. where the
trade is in the settlement process). In some cases, the previous trade
will be cancelled and a new one will be created, while in other cases
the previous trade will be updated and retain the same trade ID after
modification. (And in some cases the request will be rejected as it is
too late in the process). So sometimes knowing only the trade ID of the
modified trade won't let you identify the original trade.
To accommodate the various practices in use, it is essential that it be
possible to record the original trade ID (before the modification) and
it would be very beneficial to be able to record the entire original
trade details, for technologically challenged firms that man need to
have a
person find the original trade. (I have heard that this happens, but
always in someone else's firm from the person telling me about it). In
effect, for each newly modified trade, it would be useful to have a
linked previous version of the trade with similar content to the
"AllocationCancelled" message, to effectively support "cancel and
rebook" semantics.
For this reason, I propose to change the content of the
AllocationAmended message to be a series of "amendment" elements, with
content model as
follows:
amendment
originalTrade | originalTradeIdentifier
amendedTrade
Can we please discuss at the next MWG?
Brian Lynn, CTO
Global Electronic Markets, http://global-emarkets.com High-speed FpML
matching, reconciliation, and validation: http://fpml-mediator.com
---------------------------------------------------------------------
To unsubscribe, e-mail: mwg-unsubscribe@xxxxxxxxxxxxxxxxxxxxxx
For additional commands, e-mail: mwg-help@xxxxxxxxxxxxxxxxxxxxxx
------------------------------------------------------------------------------
This message is intended only for the personal and confidential use of the designated recipient(s) named above. If you are not the intended recipient of this message you are hereby notified that any review, dissemination, distribution or copying of this message is strictly prohibited. This communication is for information purposes only and should not be regarded as an offer to sell or as a solicitation of an offer to buy any financial product, an official confirmation of any transaction, or as an official statement of Lehman Brothers. Email transmission cannot be guaranteed to be secure or error-free. Therefore, we do not represent that this information is complete or accurate and it should not be relied upon as such. All information is subject to change without notice.
---------------------------------------------------------------------
To unsubscribe, e-mail: mwg-unsubscribe@xxxxxxxxxxxxxxxxxxxxxx
For additional commands, e-mail: mwg-help@xxxxxxxxxxxxxxxxxxxxxx