[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: FpML-MWG40 tradeSide issue




Marc T - this was discussed this at the time tradeSide was created and reviewed.

To your first point: Your usage scenario falsely assumes that any party will only ever be on one side or the other and never both. A party may be on both sides in some capacity.

To your second point: If you identify a single party in the tradeSide then this is equivalent to the payer/receiver pointing directly at the party. But changing the FpML model (the nagivations and associations) on a dynamic basis according to the data is complex to process. Having payer/receiver always point to tradeSide which always points to parties is simpler than changing it based upon your perspective of the trade.

Matthew Rawlings
+44 791 539 7824



Marc Teichman <mteichman@xxxxxxxx>

21/03/2006 21:15
Please respond to mwg

       
        To:        mwg@xxxxxxxxxxxxxxxxxxxxxx
        cc:        mwg@xxxxxxxx, MGratacos@xxxxxxxx
        Subject:        RE: FpML-MWG40 tradeSide issue




Marc,


I've got the following usage question around tradeSide, and was interested in feedback.


The expected usage as demonstrated in the published samples, is to point from buyer/seller and payer/receiver to the relevant tradeSide which in turn points to the relevant party. This is a usage change from the days prior to tradeSide when buyer/seller and payer/receiver would point directly to the relevant party. It also introduces some additional complexity because of the additional level of indirection.


It would seem that including the tradeSide elements in the message without pointing directly to them, would still accomplish the same benefit without the usage change and additional complexity. The usage would be as follows: Point from buyer/seller and payer/receiver to the relevant party elements, and include the tradeSide elements in the message for the purpose of grouping the parties by role as they relate to a particular party who is named as the creditor.


Given the above, I would further question whether it would be sensible to send only one tradeSide in a message which includes one side of the trade, or whether it would always make sense to include two tradeSide elements regardless. (This question would not apply with the tradeSide usage as shown in the sample messages, since there would have to be two tradeSide elements because there are two parties of the trade represented on the message even when there is only one side of the trade that is being submitted).


Best Regards,

Marc


"Marc Gratacos" <MGratacos@xxxxxxxx>

02/08/2006 10:55 AM

Please respond to
mwg@xxxxxxxxxxxxxxxxxxxxxx

To <mwg@xxxxxxxxxxxxxxxxxxxxxx>
cc
Subject RE: FpML-MWG40 tradeSide issue







As I mentioned I suggest limiting the occurrence of tradeSide to 2 and
publish it in this third working draft. I don't see a strong reason for
not doing that. If someone comes up with a case needing more than 2
sides, we'll go back to maxOccurs=unbounded.


-----Original Message-----
From: Marc Gratacos [mailto:MGratacos@xxxxxxxx]
Sent: Thursday, January 26, 2006 9:35 AM
To: mwg@xxxxxxxxxxxxxxxxxxxxxx
Subject: RE: FpML-MWG40 tradeSide issue


Andrew,


I don't think so. Example 16 is a list of trades (I am attaching it).
Within each trade there are only two trade sides.


Best Regards,
-Marc
+1-212-901-6028



-----Original Message-----
From: andrew.p.parry@xxxxxxxxxxxx [mailto:andrew.p.parry@xxxxxxxxxxxx]
Sent: Friday, January 20, 2006 2:34 AM
To: mwg@xxxxxxxxxxxxxxxxxxxxxx
Subject: RE: FpML-MWG40 tradeSide issue


Marc


Note our own examples already show usage with trade side greater than 2
(
ie ) msg_ex16_fx_single_leg_roles_accounts.xml


Regards


Andrew Parry
+44 20 7325 1486
IBML Product Manager
http://ibml.jpmorgan.com






"Marc Gratacos" <MGratacos@xxxxxxxx>
19/01/2006 16:43
Please respond to mwg



To:     <mwg@xxxxxxxxxxxxxxxxxxxxxx>
cc:
Subject:        RE: FpML-MWG40 tradeSide issue



What should do on this?


I personally think we should limit it to 2. I don't see a strong reason
for not doing that. If someone comes up with a case needing more than 2
sides, we'll go back to maxOccurs=unbounded.


What do other people think?


Best Regards,
-Marc
+1-212-901-6028


From: matthew.d.rawlings@xxxxxxxxxxxx
[mailto:matthew.d.rawlings@xxxxxxxxxxxx]
Sent: Thursday, January 12, 2006 3:38 PM
To: mwg@xxxxxxxxxxxxxxxxxxxxxx
Subject: RE: FpML-MWG40 tradeSide issue



Maybe we need to be clearer that additional fees aren't legs?




Matthew Rawlings
+44 791 539 7824




Brian Lynn <brian.lynn@xxxxxxxxxxxxxxxxxxx>
11/01/2006 20:37
Please respond to mwg


To:        mwg@xxxxxxxxxxxxxxxxxxxxxx
cc:        matthew.d.rawlings@xxxxxxxxxxxx
Subject:        RE: FpML-MWG40 tradeSide issue




Usually a swap with three streams or more will still involve the same
two
sides.  On the other hand, sometimes there are additional fees or
payments
with a different party, and this might involve additional sides.
(Occasionally firms will represent these additional payments as
additional
streams, contradicting my first comment).  For this reason I think that
you can't necessarily constrain the number of sides, though it would be
reasonably rare that you would need more than two.


Brian Lynn, CTO
Global Electronic Markets, http://global-emarkets.com
High-speed FpML matching, reconciliation, and validation:
http://fpml-mediator.com





From: Marc Gratacos [mailto:MGratacos@xxxxxxxx]
Sent: Wednesday, January 11, 2006 3:25 PM
To: mwg@xxxxxxxxxxxxxxxxxxxxxx
Cc: matthew.d.rawlings@xxxxxxxxxxxx
Subject: FpML-MWG40 tradeSide issue


All,


See tradeSide issue reported by Matthew Rawlings:


"The cardinality of tradeSide under trade ( //trade/tradeSide), should
be
"0..2". Currently the cardinality is 0 to unlimited."
http://www.fpml.org/issues/view.php?id=158


Wouldn't be possible to have a swap with, for example, three or more
streams, each one having a different tradeSide?


Let me know your opinion on this.


Thanks a lot,
-Marc




---------------------------------------------------------------------
To unsubscribe, e-mail: mwg-unsubscribe@xxxxxxxxxxxxxxxxxxxxxx
For additional commands, e-mail: mwg-help@xxxxxxxxxxxxxxxxxxxxxx



---------------------------------------------------------------------
To unsubscribe, e-mail: mwg-unsubscribe@xxxxxxxxxxxxxxxxxxxxxx
For additional commands, e-mail: mwg-help@xxxxxxxxxxxxxxxxxxxxxx