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