My concern with this is the word "trade" is overloaded. It is used for
both the "block trade" and the "trade allocation".
We can't use the word "trade" for both (block) trade and trade
(allocation) - it is too confusing to have two different concepts with the
same name. We should set the terminology and use it consistently
throughout FpML.
1. As a group we aren't clear about whether the relationship between
the (block) trade and the (trade) allocation is one of composition or one
of extending a common base type. We should clarify this first. I've made
an assertion in UML below.
2. Secondly we should clarify what happens when a trade with only one
allocation is made. I assert that following the UML below it is a trade
with one allocation, not a trade without allocations.
There shouldn't be any need to use names like "blockTradeIdentifier" nor
"allocationTradeId". Just the simple "tradeId" and "allocationId" should
be enough.
Matthew Rawlings
Prime Brokerage Strategy & Architecture
+44 791 539 7824
Marc Teichman <mteichman@xxxxxxxx>
22/04/2005 21:16
Please respond to mwg
To: mwg@xxxxxxxxxxxxxxxxxxxxxx
cc:
Subject: Re: FpML-MWG40 minutes meeting 04/07
Attached is a proposal and sample message for the short form
allocation which references the trade, as mentioned in the minutes below.
I also propose the following changes to the Allocation type:
1. Make collateral optional.
2. Change the partyAllocationIdentifier element of type
AllocationIdentifier to allocationTradeId of type TradeIdentifier. This
would align the allocation reference within the Allocation type to the
allocation reference within the BlockTradeIdentifier type. It would also
obviate the need for the new AllocationIdentifier type.
"Marc Gratacos" <MGratacos@xxxxxxxx>
04/14/2005 06:20 PM
Please respond to mwg
To: <mwg@xxxxxxxxxxxxxxxxxxxxxx>
cc: (bcc: Marc Teichman/DTCC)
Subject: FpML-MWG40 minutes meeting 04/07
No meeting this week. I'll send an e-mail with details for next
meeting.
April 7, 2005
Attendees
---------------
Kedhar Kodlapur (Lehman Brothers)
Ira Fuchs (XML Associates)
Brock Arnason (Morgan Stanley)
Marc Teichman (DTCC)
Robert Stowsky (BrookPath)
Brian Lynn (GEM)
Rajeev Kotyan (Sonic Software)
Henri Pegeron (ISDA)
Marc Gratacos (ISDA)
Regrets
-----------
Matthew Rawlings (JP Morgan Chase)
Robert Stowsky (BrookPath)
AllocationAmended Message
------------------------------------------
The proposed message to modify trade allocations (AllocationAmended) 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. Brian sent an e-mail requesting to record the original trade ID
(before the modification) and to record the entire original trade details,
for technologically challenged firms that man need to have a person find
the original trade.
Matthew Rawlings sent an e-mail to the list raising the following point
"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."
So we have to make a decision between accommodating different ways of
modeling the process or supporting only one way to do it.
People agreed on having a week for reviewing the proposal and make
comments about it.
N-Level Allocations
----------------------------
Brian presented a proposal to model N-Level Allocations. This basically
means the ability to allocate a block trade to multiple allocation trades,
and then allocate these in turn to other allocation trades (and so on if
desired).
The initial proposal was to create a new type called
"BlockAndAllocationTradeIdentifier" that would include the
allocationTradeId element from BlockTradeIdentifier and the blockTradeId
element from AllocationTradeIdentifier. After some discussion, people felt
that it was simpler to add a blockTradeId in the BlockTradeIdentifier type
and document clearly that the element would be used for N-Level
allocations. People agreed on this change.
Proposal on short-form allocations
-------------------------------------------------
Some changes were suggested:
* Make approvals element optional and approval element mandatory
* Provide a choice between accountReference and partyReference.
There were some comments regarding fees and how to represent them as
allocated/non-allocated. Brock's example doesn't seem to be very explicit
but there weren't alternative proposals made. It's an open issue.
Marc Teichman made the suggestion of having a short form representation
plus a reference to the original trade. Proposal needs to be submitted.
Examples on Trade Side
------------------------------------
Marc Gratacos put together an example of how to model brokerPartyReference
with the new tradeSide structure.
Marc Teichman raised the concern that this is adding more complexity into
the schema. He said that he would look into the proposal and will post
comments in the mailing list.
Action items
------------------
- Marc G. will create an example with tradeSide/Accounts and
Allocations
- Marc G. will update Brock's proposal incorporating feedback.
- All should review Brian's proposal on AllocationAmended.
Please, post your comments on the mailing lists.
---------------------------------------------------------------------
To unsubscribe, e-mail: mwg-unsubscribe@xxxxxxxxxxxxxxxxxxxxxx
For additional commands, e-mail: mwg-help@xxxxxxxxxxxxxxxxxxxxxx
#### Proposal to add RequestAllocation message.doc has been removed from
this note on April 24 2005 by Matthew D Rawlings
#### msg_ex_request_allocation.xml has been removed from this note on
April 24 2005 by Matthew D Rawlings
<<attachment: winmail.dat>>