Subject: ConfirmLogic Issues
From: [email-masked]
To: [email-masked], legal <[email-masked]>, [email-masked], [email-masked]
Cc: [email-masked], [email-masked]
Date: Tue, 7 Aug 2001 10:07:26 -0700 (PDT)

ConfirmLogic will revolutionize the current method of confirming power transactions.  While the paperless confirmation process will generate much that is positive, it also creates certain legal concerns for the power group.  Historically, the confirmation process has been used by the power group to address contractual inadequacies and ambiguities in product terms.  ConfirmLogic is designed to confirm the basic commercial terms of standard transactions.  It is not intended as a vehicle for confirming unique transactions, addressing additional contractual terms or clarifying transaction terms.  Thus, we must employ appropriate guidelines to ensure that (1) only standard power transactions are confirmed via ConfirmLogic and (2) necessary additional terms and conditions of confirmation are agreed to with a counterparty prior to the implementation of ConfirmLogic with such counterparty.  

I.	Confirmation of Standard Transactions 

We need to ensure that ConfirmLogic is used to confirm only standard power transactions.  If a transaction would  require a special confirmation template or otherwise include special terms and conditions (e.g., an unusual product such as 10-minute spinning reserve), such transaction is not appropriate for confirmation via ConfirmLogic.  There are a number of steps we could take to help ensure that only appropriate transactions are confirmed by ConfirmLogic.  (1) I proposed that EnPower and analogous deal entry systems include a field where the trader designates whether the deal should be confirmed by ConfirmLogic.  If the default were "No", the traders would be required to proactively designate if ConfirmLogic could be used.  Melissa Murphy has indicated that the traders would strongly resist such a process.  Alternatively, Melissa and I discussed a two-step process whereby (a) we create a Special Handling flag for the deal entry system so that if a trader has a trade with special terms and conditions, the trade is flagged and will not flow to ConfirmLogic; and (b) the documentation group runs regular reports throughout the day listing all trades with comments added to the "Comment" section by the trader and pulls any trades from the ConfirmLogic website that require special handling (with the risk of the counterparty accepting the confirmation or automatic matching of the confirmation prior to the time the trade is pulled off the web.)   The success of this process would turn upon adequate education of the traders and consistent monitoring by the documentation group. (2)  According to Melissa Murphy, I believe we could also code certain products types, e.g., 10 minute spinning reserve, so that they could not be confirmed by ConfirmLogic.  As new products were created, we would need to decide whether to code the product to allow confirmation by ConfirmLogic. (3)  We could build a delay into the ConfirmLogic process to ensure that the documentation group had time to review the deals flowing to ConfirmLogic before the counterparty can confirm the transaction.  For instance, if a deal with special terms was sent through ConfirmLogic, the documentation group could flag the transaction with the "Inquiry" status and notify the counterparty that the transaction should be confirmed in writing to memorialize special terms and conditions.  However, CommodityLogic will likely oppose this suggestion because they have marketed ConfirmLogic as "real time".

II.	Additional Terms and Conditions of Confirmation
 
	Attached below please find the Form of Agreement Relating to Power Transactions Confirmed by ConfirmLogic (the "Confirmation Agreement").  This is the type of document that we need to finalize with each power counterparty before transactions are confirmed by ConfirmLogic.  The CommodityLogic website contains private and public folders that may be utilized by Enron to post the Confirmation Agreement electronically.

	We must be prepared to address changes in product terms and other contractual issues with each counterparty using ConfirmLogic.  Thus, we should maintain a Confirmation Agreement database to track such counterparties.  We would need to update the Confirmation Agreements as changes to the product terms occur.  Moreover, as we negotiate new master agreements with such counterparties, we must be aware of the terms of the Confirmation Agreement and address whether to conform the new master to the Confirmation Agreement or incorporate the terms of the Confirmation Agreement into the new master and thus supersede the Confirmation Agreement.  

	While ConfirmLogic will post summaries of EnronOnline transactions, EnronOnline transactions will not be confirmed on ConfirmLogic.  The ConfirmLogic documentation makes clear that EOL transactions are posted for information purposes only will not be confirmed.  This is consistent with the direction we have been going for all EnronOnline transactions.  Janet Moore has been involved in a project to discontinue the confirmation process for all EOL transactions with certain counterparties.   Enron will enter into agreements with certain counterparties whereby the parties agree (1) that EOL transactions need not be confirmed, notwithstanding any terms in the underlying master agreement to the contrary, and (2) to additional terms of the transaction previously captured by the confirmation process (the "EOL Agreement").   If we have already entered into an EOL Agreement with a counterparty, we need not address EOL trades in the Confirmation Agreement.  However, if we have not yet entered into an EOL Agreement with a counterparty, we can address all EOL issues in the Confirmation Agreement itself and thus obviate the need for two separate agreements. 

	I look forward to any questions or suggestions you have relating to the issues raised in this e-mail.

Thanks,

Leslie