FpML-FXWG-Legacy Fwd: Re: [fpml-fx] FW: [fpml-coord] Question regarding usage of strategy, tradeId, a nd linkId tags

["Danielle Cauthen" <dcauthen@xxxxxxxx>]

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



For the portfolio  ...

For starters we could change the definition of the <FpML> root 
element to
allow multiple occurrences of <trade>, and to add an optional 
element or
two to label the portfolio.  I.e. the portfolio would be implied not
explicit.

e.g.

<FpML version="3-0" ... >
     <docname "TestPortfolio">
     <trade> ... </trade>
     <trade> ... </trade>
     <trade> ... </trade>
</FpML>

This wouldn't support nested portfolios and portfolios containing
references to trades, but it's a start.  (Maybe the docname attribute
should actually be an element

For a more elaborate scheme,  you could add an optional id attribute 
to the
<trade> element and then add optional <portfolio> elements containing
<tradeReference> elements to the <FpML> root element....

That would let you define portfolios like this:

<FpML version="3-0" ... >
     <docname "TradingBook"/>
     <trade id="#t1"> ... </trade>
     <trade id="#t2"> ... </trade>
     <trade id="#t3"> ... </trade>
     <trade id="#t4"> ... </trade>
     <trade id="#t5"> ... </trade>

     <portfolio>
          <portfolioName "Portfolio1" />
          <tradeReference href="#t1" />
          <tradeReference href="#t2" />
     </portfolio>
     <portfolio>
          <portfolioName "Portfolio2" />
          <tradeReference href="#t3" />
          <tradeReference href="#t4" />
          <tradeReference href="#t5" />
     </portfolio>
</FpML>

Presumably the reference notation would also allow the trade to be 
define
in a deferent FpML doc from the portfolio, e.g.
<tradeReference 
href="http://www.jpmorgan/swaps/tradedb/2001_01_03#t5"; />

But maybe TWIST has a better way.

- Brian






rick.schumacher@... on 11/29/2001 05:39:48 PM

Please respond to fpml-fx@xxxxxxxxxxxxxxx

To:   fpml-fx@xxxxxxxxxxxxxxx
cc:
Subject:  [fpml-fx] FW: [fpml-coord] Question regarding usage of 
strategy,
      tradeId, a         nd linkId tags


FYI ... Brian's comments.  Seems like we've created some more work 
for the
Cross Products group.  I think I'll study Bill's TWIST work, because 
I
think
some of this is naturally covered there.  Bill ... if you want to 
make any
comments, that would be great as well.

Rick


-----Original Message-----
From: brian.lynn@... [mailto:brian.lynn@...]
Sent: Thursday, November 29, 2001 9:57 AM
To: fpml-coord@xxxxxxxxxxxxxxx
Subject: RE: [fpml-coord] Question regarding usage of strategy, 
tradeId,
a nd linkId tags



Some excellent points in this discussion.  I will chime in with some 
not
particularly useful observations:

1) I think we will need a way of assigning trade IDs for each of the
products in a strategy, as well as at the top level ... many systems 
will
book them individually, and we will want to remember how we booked 
them.

2) The portfolio concept will be a key, not only for the purpose 
that Rick
mentions, but also for:
     - risk management applications
     - collateral matching (and general reconciliation purposes)
     - reporting applications
     - net settlement applications
     - etc.
Fortunately, I think it should be pretty easy to implement at least 
a basic
version of this.  I think it would be very useful to put some basic 
version
into version 3.0.  Do you think we can do this without creating a 
lot of
controversy and extra work?  Beyond the trade contents of the 
portfolio,
about the only info that I can immediately think of standardizing 
includes:
- portfolio name
- portfolio owner (maybe) and/or some concept of parent/child 
portfolios
- some kind of type or purpose code (maybe not)
Not very much, in other words.

Any volunteers for either of these?

- Brian




guy.gurden@... on 11/29/2001 09:05:43 AM

Please respond to fpml-coord@xxxxxxxxxxxxxxx

To:   fpml-coord@xxxxxxxxxxxxxxx
cc:
Subject:  RE: [fpml-coord] Question regarding usage of strategy, 
tradeId, a
      nd linkId tags


Rick,

Here's some of the thinking behind the original FpML 1.0 elements:

tradeId

The reason for allowing multiple trade Ids to be assigned per party 
was to
allow for the case where a trade may be assigned different 
identifiers as
it
passed between different systems/environments.  For example, a good 
case in
point is what happens with SwapsWire.  SwapsWire assigns a unique 
trade id
to each trade executed on the SwapsWire platform. In the FpML we 
send to
the
two parties we put the same trade id in the tradeId element for both
parties. The corresponding default tradeId Scheme URI identifies the
tradeId
as being one assigned by SwapsWire.

tradeIdSchemeDefault="http://www.swapswire.com/spec/2001/trade-id-1-
0">

<tradeHeader>
  <partyTradeIdentifier>
    <partyReference href="#partyA"/>
    <tradeId>2891</tradeId>
  </partyTradeIdentifier>
  <partyTradeIdentifier>
    <partyReference href="#partyB"/>
    <tradeId>2891</tradeId>
  </partyTradeIdentifier>
  <tradeDate>2001-11-27</tradeDate>
</tradeHeader>

A bank receiving the FpML and wishing to continue using FpML as a 
data
transmission format may well assign their own internal trade id to 
the
trade. They could do this by adding a further tradeId element with a
corresponding Scheme URI.  For example:

<tradeHeader>
  <partyTradeIdentifier>
    <partyReference href="#partyA"/>
    <tradeId>2891</tradeId>
    <tradeId
tradeIdScheme="http://www.megabank.com/system-x/trade-id
">123456789</tradeId
>
  </partyTradeIdentifier>
  <partyTradeIdentifier>
    <partyReference href="#partyB"/>
    <tradeId>2891</tradeId>
  </partyTradeIdentifier>
  <tradeDate>2001-11-27</tradeDate>
</tradeHeader>

linkId

We envisaged linkId being used in much the way you described, e.g. a
cancellable swap may be broken up into 2 separate trades - a swap 
and a
swaption. These might go down different processing routes within an
organization and be assigned different trade ids. The linkId could 
be used
to reference any related trades, i.e. the swap could have the 
swaption's
trade id in the link id field and vice versa.

Obviously these ideas pre-date the strategy introduced in FpML 2.0 
so I
agree there are now many ways of effectively doing the same thing. 
One
question your note triggered in my mind was does the existing FpML 
2.0
structure allow the different product legs in a strategy to be 
assigned
different trade ids - I think the answer is no but should it?

I agree on your last point that FpML needs to prescribe a standard 
way of
representing a portfolio of FpML trades.

Hope this helps. Let me know if I missed anything in your note.

Guy



-----Original Message-----
From: Rick Schumacher [mailto:rick.schumacher@...]
Sent: Thursday, November 29, 2001 1:27 AM
To: fpml-fx@xxxxxxxxxxxxxxx; fpml-coord@xxxxxxxxxxxxxxx
Subject: [fpml-coord] Question regarding usage of strategy, tradeId, 
and
linkId tags


Ned Micelli of Reuters and I have been causing trouble once again 
and have
some questions regarding implementation of "tradeId" and "linkId" 
within a
"strategy."  Obviously, this is all inherited from the IRD folks and 
the
original FpML designers, so I'm sure that some of you can assist 
with the
logic behind how these elements are intended to be used, and how 
strategy
should be used in general.

Ned has been working on creating a few examples using the "strategy"
element, which is used to define multiple financial instruments into 
a
single FpML trade document.  As has been noted in the FpML 2.0
specification, a trade " is an agreement between two parties to 
enter into
a
financial contract and the trade component in FpML contains the 
economic
information necessary to execute and confirm that trade."  My 
assumption
has
always been that if there is one physical execution of a trade, but 
there
are multiple financial instruments within that trade, then this 
would be
considered a strategy.  For example, someone might purchase a 
straddle (buy
a call and buy a put on the same underlying), and this could be 
considered
as one single trade, meaning that it would have one single trade
identification number, but have multiple product legs underneath.

Others might consider each financial leg within a "strategy" to be a 
trade
in its own right, where each leg would have its own reference number 
and be
executed and confirmed independently.  This might be because the 
trades
weren't executed at the same time (e.g., someone might do a delta 
hedge and
initiall do, for example, purchase an option, but then subsequently 
[albeit
very shortly thereafter] execute a spot trade to hedge the delta of 
the
option).  While this might occur at virtually the same time, if they 
are
executed via two different product specialist networks (one for the 
option,
one for the spot deal), while the customer might identify this as a
specific
strategy, if there are multiple trade id numbers involved, then this 
would
have to be sent as two separate FpML trade documents and confirmed
independently.  I suppose that if these were somehow linked together 
as
part
of an overall hedging strategy (but are nevertheless executed and 
confirmed
separately), then you could use the linkId field to link the two 
trades
together.

So, it seems like there is a lot of flexibility here to either send
multiple
financial products together in one document or individually as 
separate
documents, depending upon the trade execution venue and the 
confirmation
required for the instruments.

The one thing that neither Ned nor I could understand is why there 
are one
or more occurrences of tradeId within FpML_PartyTradeIdentifier.
Initially,
Ned was thinking that this could be used in such a way where if 
there were
3
financial instruments in a strategy, for example, then you could 
have a
tradeId for each of the the transactions, but include them in one 
FpML
document.  I don't believe that FpML is intended to be used this way 
and
would like confirmation that this is the case.  That being said, we 
were
having a difficult time understanding why there are multiple 
occurrences of
tradeId allowed within a party (in fact, in the element description, 
it is
noted that "for external communication of a trade there will only be 
one
tradeId sent in the document per party").  If someone could explain 
the
reasoning behind this and confirm that our understanding of this is
correct,
that would be quite helpful.

One thing that this has highlighted is that, at some point, there 
will need
to be an easier way for systems to send each other a batch of trades 
at one
time.  Although not necessarily as elegant, in practice there will be
requirements for customer to want to do something like "send me all 
of the
trades that I executed today," and would want that information from 
the
execution venue as one single FpML document, if possible, with 
mutiple
trades within the document.  Andrew Jacobs discussed this at our X-
Products
WG meeting in September, and I can definitely see this requirement 
popping
up in the future as the specification gets implemented.

Anyway, my intention in writing this up and distributing to both the 
FX WG
and the Coordination Group is to ensure that our understanding of 
how this
all hangs together is correct.

Comments welcome, as always ...

Regards,
Rick



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/


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.


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/









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.



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