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

["Danielle Cauthen" <dcauthen@xxxxxxxx>]

--- In fpml-fx@xxxxxxxxxxxxxxx, Rick Schumacher 
<rick.schumacher@...> wrote:

Guy's response.

-----Original Message-----
From: Guy Gurden [mailto:guy.gurden@...]
Sent: Thursday, November 29, 2001 9:06 AM
To: fpml-coord@xxxxxxxxxxxxxxx
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/

--- 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