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
Attachment:
FpMLMethodsOfCorrectingATrade.xls
Description: application/msexcel
Attachment:
ATT3599761.txt
Description: Text document