FpML-FXWG-Legacy Fwd: Re: [fpml-fx] RE: More on portfolios and trade references within a s trategy

["Danielle Cauthen" <dcauthen@xxxxxxxx>]

--- In fpml-fx@xxxxxxxxxxxxxxx, brian.lynn@... wrote:



1.  While in general I agree with Steven's comments, there is perhaps
another (maybe quite common) case to consider.  That is a strategy 
that is
confirmed as a single unit (hence has a single trade id)  but that is
booked into a risk management system as multiple (possibly unlinked)
trades.  I'm not clear whether the proposed approach will allow you 
to
record the risk management system's trade IDs on each of the 
components.
This isn't strictly essential, but could be very useful.  Many 
systems
distinguish between a "deal" or a "transaction" and a "trade", where 
the
deal/transaction is the unit that is confirmed, but the trade is the 
unit
that is understood by the trading system as the primary unit for risk
management.

2. (Party).  A couple of comments on the unique party ID problem:
a) As I understand it, party IDs are arbitrary IDs assigned by the 
writer
of the FpML document, not by the DTD.  The convention of using a 
party ID
that corresponds to the firm's name is just something that we have 
done to
make reading the examples easier.  As far as I know there is nothing
stopping a FpML document writer to have the same party twice with 
different
IDs.  If you were planning to put the party identifier in on every 
trade,
you should therefore do something to ensure that duplicates were 
avoided.
One possibility is to use a trade-id prefix for every party id (e.g.
#trade1-party1).  Another is to use a random or sequential ID.

b) As far as making party mandatory, remember that we won't just be 
using
FpML to send trades between counterparties.  We will also be using 
it to
represent a wide variety of portfolios.  In doing this, it might be
beneficial for an FpML user to create an FpML document containing 
nothing
but party definitions, possibly using some internal party 
identification
system as the basis of their party ID.  (At JPMorgan we have a number
called an SPN, standard party number.  Maybe we would always use ids 
that
are SPNs.)  Then other FpML documents could omit any party 
definitions and
just reference the standard document.   (You could even imagine 
referencing
some kind of database query using the id as a key.)

So therefore while I understand that some people might be confused by
making party entirely optional, and it may make certain kinds of 
validation
more difficult, I think that requiring party to always be defined 
within
an FpML document is overly restrictive.  The only requirement on a 
party
reference should be that it be resolvable when the document is 
validated.
(This is something you need to do anyway, since the DTD doesn't 
guarantee
that party references in the products correspond to the parties that 
are
identified in the trade.)

It seems to me that by keeping the party optional at both levels you 
a)
preserve compatibility with the existing spec, and b) create much 
more
flexibility in how parties can be represented.  The cost would be 
forcing
people to consider that party references might be outside of the FpML
document, and possibly developing validation accordingly.

- Brian




rick.schumacher@... on 12/05/2001 06:56:25 PM

Please respond to fpml-fx@xxxxxxxxxxxxxxx

To:   fpml-fx@xxxxxxxxxxxxxxx, fpml-coord@xxxxxxxxxxxxxxx
cc:
Subject:  [fpml-fx] RE: More on portfolios and trade references 
within a s
      trategy


Steven/Brian/everyone,

Ned and I have discussed Steven's ideas.  Here's what we think:

1. We agree that Steven's comments regarding tradeReference, and 
that a
trade by definition is an wholly atomic unit (and confirmed on it's 
own) is
reasonable.  We will abandon this idea and keep as is.

2. We believe that Steven's approach is reasonable as well for 
portfolios
and is simple.  By defining a portfolio in a simple way as being a
collection of trades (which can be used for a variety of purposes), 
this is
a good feature without burdening us too much in terms of workflow 
(which
will be difficult to standarize).

That being said, we still believe that "party" must sit outside of 
trade.
Otherwise, according to Ned, you are going to have a unique id 
problem
where
if you have multiple trades within a portfolio with the same party, 
the
parser will complain about the duplicate id's across trades.  In 
other
words, if you have #BRIAN in trade1 and #BRIAN in trade2, you will 
have
problems, we believe.

The problem with Brian's idea of having this optional at both levels 
is
that
you run the risk of not sending any parties at all on an FpML 
document.
This may not sit well with a lot of people.

We do acknowledge that Ned's idea was a fairly dramatic change.  We 
were
trying to easily identify a trade within a collection of trades 
without
having to read through each trade to find the trade you were looking 
for
and
felt that this might optimize this search.  However, based upon 
initial
reaction, it seems like it may not be worthwhile to do this type of
overhaul
for something that we're not sure how it's going to be used anyway.

So, I think Steven's idea is pretty good ... the only thing that I 
need
needs further discussion is how we bring the "party" outside of the 
trade
...

Rick




-----Original Message-----
From: Rick Schumacher
Sent: Wednesday, December 05, 2001 5:20 PM
To: Ned Micelli (E-mail)
Subject: FW: [fpml-coord] More on portfolios and trade references 
within
a s trategy


See Steven's and Brian's comments below.

1. Is Steven correct or not regarding ambiguity of trade?  Doesn't 
having
tradeReferenceId allow for this?
2. Is Steven's simpler approach (see .gif file) make it easier?

Rick


-----Original Message-----
From: brian.lynn@... [mailto:brian.lynn@...]
Sent: Wednesday, December 05, 2001 8:41 AM
To: fpml-coord@xxxxxxxxxxxxxxx
Subject: RE: [fpml-coord] More on portfolios and trade references 
within
a s trategy



I'm with Steven that evolutionary rather than revolutionary changes 
are
warranted.

Rather than taking sides on the debate about whether the party 
should be
moved up to the root, why don't we just make <party> optional within 
both
the trade and the root element?  Then if a user wants a standalone 
trade,
he can fill it the party elements in the trade; if he wants a 
portfolio, he
can either fill it in at the root and reference the parties from the
trades, or he keep the party elements at the trade level and just 
make sure
to use unique id refs (e.g. <trade id="trade1"> <party id
= "trade1-party1"> ...).  After all, the <party> element is in 
effect just
defining some reference data that could be defined elsewhere (even in
another document).  So eventually you could theoretically have party 
refs
like href="www.jpmorgan.com/refdata/legalentitties/#JPMSI" (though I 
grant
that this approach is unlikely to be used broadly.)

- Brian






steven.lord@... on 12/05/2001 06:51:01 AM

Please respond to fpml-coord@xxxxxxxxxxxxxxx

To:   fpml-coord@xxxxxxxxxxxxxxx
cc:
Subject:  RE: [fpml-coord] More on portfolios and trade references 
within a
      s trategy


Some comments / thoughts

1. Use Of 'TradeReference'
My understanding of trade and tradeId is:
a. A trade is meant to represent a single 'confirmation' (single 
legal
transaction). Thus if two confirmations then two fpml trades. linkId 
is
intended to be used to link two trades that are part of the same
transaction but are seperate confirmations.
b. Strategy represnets a single 'confirmation' made up of several
products - this could be something like an option and delta hedge
traded together or could be a method of representing a product (eg a
straddle as two swaptions).
c. tradeId represents a unique id for the trade allocated by some
system.
d. Mutliple tradeIds allow for different systems allocating their own
id for the same trade. So perhaps a trade would have an id allocated
from Swapswire and one allocated from an internal system. Two ids but
they are for the same trade.

My understanding of what is being said in the document is that the
tradeIdReference is being used to allocate a unique id to each 
product.
This is using the multiple tradeIds in the trade header in a way not
originally intended. This would mean that at the trade level there
could be several ids that do not relate to the trade as a whole. This
seems inappropriate (as well as potentially confusing and ambiguous).
If products require their own ids then we should add an productId
element into the product rather than reference outside the product.

2. Portfolio
a. Does this add enough to the standard to warrant the change ?
b. If we do this I think 'tradeHeader' is a bad name since this is no
longer a header to a trade it's the trade itself.
c. Having party directly under FpML means that trades are not stand
along. Does this matter ?
Do we need such a dramatic change - can't we just a portfolio element
(zero or more) under FpML and make trade one or more. See diagram
attached.

Steven

-----Original Message-----
From: rick.schumacher
Sent: 04 December 2001 21:13
To: fpml-coord
Cc: fpml-fx; rick.schumacher
Subject: [fpml-coord] More on portfolios and trade references within 
a
strategy


During yesterday's Coordination Meeting, I mentioned that Ned Micelli
had
done some work on this subject and sent a document during our call.
Today,
I reviewed this with Ned, and I think he's come up with some 
interesting
ideas to potentially support two features:

*    Allow multiple trade id's within a strategy (by allowing for a
trade
id reference within the product node)
*    Allow for a portfolio of trades

We did a bit more work on this today, and I think we have a 
reasonable
starting point for discussion.  Comments, suggestions, and/or
improvements
certainly encouraged.

Regards,
Rick

 <<TradeID Thoughts.doc>>


To unsubscribe from this group, send an email to:
fpml-coord-unsubscribe@xxxxxxxxxxxxxxx



Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/



To unsubscribe from this group, send an email to:
fpml-coord-unsubscribe@xxxxxxxxxxxxxxx



Your use of Yahoo! Groups is subject to 
http://docs.yahoo.com/info/terms/


(See attached file: portfolio.gif)

Visit our website at http://www.ubswarburg.com

This message contains confidential information and is intended only
for the individual named.  If you are not the named addressee you
should not disseminate, distribute or copy this e-mail.  Please
notify the sender immediately by e-mail if you have received this
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free
as information could be intercepted, corrupted, lost, destroyed,
arrive late or incomplete, or contain viruses.  The sender therefore
does not accept liability for any errors or omissions in the contents
of this message which arise as a result of e-mail transmission.  If
verification is required please request a hard-copy version.  This
message is provided for informational purposes and should not be
construed as a solicitation or offer to buy or sell any securities or
related financial instruments.







To unsubscribe from this group, send an email to:
fpml-coord-unsubscribe@xxxxxxxxxxxxxxx



Your use of Yahoo! Groups is subject to 
http://docs.yahoo.com/info/terms/



To unsubscribe from this group, send an email to:
fpml-fx-unsubscribe@xxxxxxxxxxxxxxx



Your use of Yahoo! Groups is subject to 
http://docs.yahoo.com/info/terms/









This communication is for informational purposes only.  It is not 
intended as
an offer or solicitation for the purchase or sale of any financial 
instrument
or as an official confirmation of any transaction. All market 
prices, data
and other information are not warranted as to completeness or 
accuracy and
are subject to change without notice. Any comments or statements 
made herein
do not necessarily reflect those of J.P. Morgan Chase & Co., its
subsidiaries and affiliates.

--- End forwarded message ---



-------------------------------------------------------------------------------
To unsubscribe: Email majordomo@xxxxxxxx with a blank subject line
In the body include the line: unsubscribe fxwglegacy youremail@address
To view archives: http://www.fpml.org/_wgmail/_fxwglegacymail/threads.html