From: brent.hendry@enron.com
To: sara.shackleton@enron.com
Date: 2000-10-16 11:39:00+00:00
Subject: Re: FX Issues

----- Forwarded by Brent Hendry/NA/Enron on 10/16/2000 11:41 AM -----

	Janine Juggins@ECT
	10/12/2000 08:36 AM
		
		 To: Dale Neuner/HOU/ECT@ECT
		 cc: Amita Gosalia/LON/ECT@ECT, Justin Boyd/LON/ECT@ECT, Brent 
Hendry/NA/Enron@Enron, Sara Shackleton/HOU/ECT@ECT, William 
Stuart/HOU/ECT@ECT, Jeff Blumenthal/HOU/ECT@ECT, Shane Dallmann/LON/ECT@ECT, 
Jason Althaus/Corp/Enron@Enron, Mark Dilworth/LON/ECT@ECT, Sheri 
Thomas/HOU/ECT@ECT, Jennifer deBoisblanc Denny/HOU/ECT@ECT, Robert B 
Cass/HOU/ECT@ECT, Melba Lozano/HOU/ECT@ECT
		 Subject: Re: FX Issues

Tax:
The Enron entity executing the FX transaction as principal is ENA. 

However, note that for tax/legal the FX desk in London is run by Enron Europe 
Finance & Trading Limited ("EEFT") as agent for ENA. Our position is that ENA 
does not have a place of business in London. Therefore all the transactions 
managed by the London FX desk are arranged by EEFT as agent for ENA.

Because of this there is a need to identify which FX desk arranged the 
transaction and a possible solution to this is to have separate logins and 
logoffs for each FX desk during their hours of responsibility. This would 
enable transaction reports to be run which identify those transactions which 
took place during the period for which each FX desk was responsible for 
managing the FX positions. 

Regards
Janine




Dale Neuner
11/10/2000 22:31
To: Amita Gosalia/LON/ECT@ECT, Justin Boyd/LON/ECT@ECT, Brent 
Hendry/NA/Enron@Enron, Sara Shackleton/HOU/ECT@ECT, William 
Stuart/HOU/ECT@ECT, Jeff Blumenthal/HOU/ECT@ECT, Shane Dallmann/LON/ECT@ECT, 
Jason Althaus/Corp/Enron@Enron, Mark Dilworth/LON/ECT@ECT, Janine 
Juggins/LON/ECT@ECT
cc: Sheri Thomas/HOU/ECT@ECT, Jennifer deBoisblanc Denny/HOU/ECT@ECT, Robert 
B Cass/HOU/ECT@ECT, Melba Lozano/HOU/ECT@ECT 

Subject: FX Issues


This e-mail is admittedly long, so I have classified the issues:

Legal/Tax Issue:

I have been told by the FX group here in Houston that London traders are able 
to act on the behalf of the US FX Desk because the transactions they do are 
for hedging purposes only (no proprietary trading). For example, the FX 
transactions that are done by Trena McFarland in London are done on the 
behalf of our Houston office, so Houston books the transaction, manages the 
risk, and writes the Confirmation in the name of ENA.

This being the case, (i) can we apply the same logic on the internal FX 
transactions that will be managed by both the US and UK traders and have the 
transacting entity as ENA (ii) if we do does it gives us the necessary tax 
relief, or (iii) should we stick the Metals structure where the transactions 
are offered by Enron North America, acting through it's agent, Enron Europe 
Finance and Trading Limited. While this may be an Internal Only Product Type 
today, what effect, if any, would the choice of trading entities have on our 
ability to offer these Products externally.

Technology Issue:

David - Stuart has explained to me that the US FX Desk now views these 
currency exchange products as financial products. This is contrary to 
previous discussions where we felt that any currency exchange involving an 
Index would be considered financial, while any 'strict exchange' would be 
considered a physical transaction. The change is based on conversations 
Stuart has had with the Metals traders wherein they would like to see this 
exchange product as a financial product. If we accept this logic, (i) do I 
need to create a Deal Type for 'Par Forward Swap' for the first FX Index 
Product Type that we did as well as a 'Forward Swap' for these transactions, 
or is it acceptable to leave these both as swaps, and (ii) regardless of the 
Deal Type classification discussed in (i), I will need to create a new 
Product Type for the 'strict exchange' - either as a physical or financial 
product. Additionally, if I set this up as Financial Product, I have the 
Index attribute in the template to contend with, because there is no Index; 
and if I set this up as a Physical Product, I have the Location attribute to 
contend with, because there is no Location. Naturally we can put something 
cheesy in to fill the gap since it's internal, but if we ever decide to go 
external we will need a new template - and from experience with the PJM Power 
(Weather Desk) Product Type, templates requires an 'and if' statement are 
hard to develop.

Dale