From: lavorato@enron.com
To: jean.mrha@enron.com
Cc: ted.murphy@enron.com, frank.hayden@enron.com
Date: 2001-02-05 13:11:40+00:00
Subject: FW: Bridgeline Sleeve

JEAN

WHY ARE WE STILL SLEEVING DEALS FOR BRIDGELINE.  UNLESS WE ARE GETTING COMPENSATED FOR THIS I DON'T WANT TO DO IT.

 -----Original Message-----
From: 	Murphy, Ted   On Behalf Of Ted Murphy/HOU/ECT@ECT
Sent:	Monday, February 05, 2001 1:38 AM
To:	Hayden, Frank
Cc:	Port, David; Gorny, Vladimir; Lavorato, John J.; Neal, Scott
Subject:	Re: Bridgeline Sleeve

Frank,
I think that you are handling it appropriately.  Lavorato and other ENA sr. mgmt should be apprised of the facts and the your opinion of the potential risks and solutions.  After they have made the decision, then we need to make sure that the procedures/processes/ and risk capture are consistent with the business expectations.  Please make sure that the Energy Operations staff is aware of this as well as credit so that they may adjust their behaviour accordingly.
As a house-keeping item, I do not think that it is appropriate for me to be CRO of Bridgeline.  I would nominate you or Vlady.
Ted


   
 	Enron North America Corp.  From:  Frank Hayden @ ENRON                           02/03/2001 12:17 AM	
		


To:	Ted Murphy/LON/ECT@ECT
cc:	David Port/Market Risk/Corp/Enron@ENRON, Vladimir Gorny/HOU/ECT@ECT, John J Lavorato/Corp/Enron, Scott Neal/HOU/ECT@ECT 
Subject:	Bridgeline Sleeve


Ted,
A little background regarding this email.  Sometime back a ENA "sleeving" arrangement was set up for Bridgeline, addressing Bridgeline's poor credit rating.   Upon execution with the broker, confirms would be sent to Bridgeline/ENA and ENA/counterparty.  Evidently, a majority of these deals were short term in nature and dealt primary with intramonth gas daily markets.

Today, Bridgeline has a larger budget and is striving to trade larger, consequently the sleeving arrangement is being used more frequently.  I spoke with Brad Horn regarding this and told him that it would be far more appropriate to trade using EOL instead of the sleeving arrangement.  He resisted this idea because of the EOL "haircut", and difficultly getting market data if not transacting in the "real" world.  

This potentially creates a legal issue, as well as may cause ENA to wear unnecessary execution and market risks.  I say this because, at times, in order to execute the trade, Bridgeline has to represent themselves as Enron, and basically tell the broker that the deal is done with so and so on the 32nd floor. (Think of what would happen should the counterparty "walk" on an in-the-money deal because Brad wasn't an authorized trader --admittedly, this hasn't happen and the deal is still sleeved.....  An additional note is that I spoke with Brad regarding the situation and he promised never again to represent himself as an ENA employee.  (He recognized his error...)

I apprised Scott Neal and John Lavorato of the issue and at present it is my understanding that they are working on a solution. I have recommended that either the sleeving arrangement become formalized (written and reviewed by legal) or that transactions be directed through EOL.

Let me know your thoughts.

Frank 

 
---------------------- Forwarded by Frank Hayden/Corp/Enron on 02/02/2001 05:39 PM ---------------------------
   
 	  From:  Frank Hayden                           02/02/2001 11:26 AM	
		


To:	Vladimir Gorny/HOU/ECT@ECT
cc:	Brant Reves/HOU/ECT@ECT, Brad Horn/HOU/ECT@ECT 

Subject:	Bridgeline Sleeve


Vlady,
I spoke with Brad regarding the current situation.  In summary, we agreed that the present relationship between ENA and Bridgeline, allowing deals to be sleeved needs to be formally documented (satisfying legal concerns/issues) and/or trades need to be directed through EOL.  Specifically, directing trades through EOL presents problems for Bridgeline, from wide bid/ask spreads to "stagnant" market information.  (i.e. knowing that El Paso is active in the market helps them better manage/optimize their system)


Frank
5/8341

 






<Embedded Picture (Device Independent Bitmap)>
<Embedded Picture (Device Independent Bitmap)>