Subject: FW: Issue to be resolved and acted upon
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Date: Mon, 5 Nov 2001 05:22:53 -0800 (PST)

Tana,

You're the best person I know to answer the questions Cindy has regarding financial trading. Let me know if I can add anything.

Thanks,

Debbie

 -----Original Message-----
From: 	Horn, Cindy  
Sent:	Monday, November 05, 2001 5:05 AM
To:	Brackett, Debbie R.
Subject:	FW: Issue to be resolved and acted upon
Importance:	High

Hi Debbie, hate to bother you but I know that for physicals we built the interface to Global Contracts from RA to do this so EOL customers would only have to sign their GTC's once.  How did this work for financials, was it from a Tagg feed?  Do you have any info on this I can send to Ron as I do not want to have to recreate the wheel on this one?  Thanks Cindy

 -----Original Message-----
From: 	Nolte, Ron  
Sent:	Saturday, November 03, 2001 6:09 PM
To:	Horn, Cindy; Whiting, Elaine; Timson, Sarah; Das, Sarita; Hunter, Larry Joe; Bonanno, Joann; Sorenson, Jefferson D.; Leggett, Tim; Callaghan, Shawna
Subject:	Issue to be resolved and acted upon

Workflow in DCAF II for Global Products will require a number of changes to the Way DCAF II currently works.

When a deal is received by DCAF II from MoneyPenney, DCAF II will have to determine if the deal is to be confirmed and who the confirming party is on the deal.

DCAF II determines this by taking a contract number assigned to the deal and goes to Global Contracts.  The Contract identifies who is to confirm the deal.  

Issue:  Currently MoneyPenny does not capture Global Compliant Contract Numbers.  Cindy Horn indicated her understanding is that Global Product Deals traded on EOL have a Contract Number.  While it is true that a party may agree to a GTC when logging on to EOL,  it does not mean that there  is a contract set up in Global Contracts between the parties.   My understanding is that EOL stores a Global Compliant Contract Number for those parties that have Master Agreements with Enron recorded in Global Contracts.  When a deal is traded on EOL for these parties,  the Contract Number ( e.g., 96053367 ) is provided in the XML message sent to Sitara and MoneyPenney.    This needs to be verified.

I have had discussions with Tim Legget regarding the contract number issue and he suggests the following be done.  A buyer contract and a seller contract number edit fields will be provided in the MoneyPenney Capture windows.  The reason there is a buyer and seller contract number is because there are two contracts when internal parties trade with each other.  MoneyPenney will not require a contract number be entered.  When MoneyPenney sends the deal message to DCAF II via DriveTrain, DriveTrain will try to determine the contract number using the GKCOM service that was developed for this purpose.  The problem with this is that there may be a significant number of deals where this service cannot determine the contract for.  GKCOM uses the internal party, the external party, the product, the document type (e.g., Master Purchase Sale Firm ), the start and end date of the deal to try and find a contract.  

First of all,  who is going to tell GKCOM what kind of Contract Agreement to look for.  There a gazillion different types of contract agreements.   If MoneyPenney does not know what contract is covering the deal, how would it know to tell GKCOM what contract agreement type to look for?

Second,  a contract has to exist which matches the product on the deal.  There are a gazillion products traded in the Global Products world.  Every product has to be set up ( See ** ) under the contract that the counterparty could possibly trade.   Also,  there may be a need to set up several contracts for the same party.  Remember, DCAF II looks to the contract to determine who is confirming the deal.  For London deals, if the deal is  Petchems or MTBE, Enron confirms.  For some products, if it is a Brokered sale, then the Broker confirms - if it is a Brokered Purchase from Stasco, BP, Texaco, or Exxon/Mobile, then the Counterparty confirms - For all other Liquids, a Brokered Purchase is confirmed by the Broker.  Currently,  it is impossible to implement these business rules in Global Contracts.  Global Contracts does not have the ability to indicate 
that the broker is confirming if it is brokered versus someone else if the deal is not brokered.

**  You can  indicate in Global Contracts that the product is "Any".  But "Any" could conflict with contracts that need to be set for Gas, Power, and Industrial Markets.  That is, you can't indicate to Global Contracts that "Any" means "Any Global Product" ;"Any" means "anything".  

OK, so it is very likely that GKCOM cannot  provide a contract for all deals.  If that is the case, then the transaction will be kicked out - will not get to DCAF II - until someone becomes aware that the deal kicked out of DriveTrain and determines what the contract is and enters it into MoneyPenney.  If this happens, it is unlikely that the confirm will go out within 24 hours.  

Even if a contract is determined by DriveTrain,   there will a significant number of deals for which the confirming party designation is not correct.

Please note that TAGG does not use contract numbers.  As such,  someone has to eyeball every deal and determine who is confirming the deal and if Enron is, which template format out of the hundreds available should be used.  The value in  DCAF can only be realized if the "someone" is removed from the processing. 

Bottom Line:  DCAF II  needs a way to determine who the confirming party is on every deal, the correct Governing Law, Arbitration,  and Jurisdiction .  For gas deals ,  the contract provides the relevant information.  The Global Products world is much more complicated.  

Decision:  If DCAF II is to use Global Contracts, there needs to be a project staffed by one or more persons 	      who spend the next couple of months working on the following responsibilities:

	1)	Determining and implementing  what upgrades to Global Contracts are required to support 
		Global Products

	2)	Making sure that the appropriate contracts are set up for all Houston and London trading 
		partners. 

	3)	Defining the business rules required to populate  the XML message with the appropriate 
		Contract Agreement Type  needed by GKCOM to determine the contract number.

	4)	 Defining a procedure that is executed when the deal kicks out of DriveTrain to determine what 
		the contract on the deal should be and enable it to be entered into MoneyPenny.

	5)	Setting up a means for testing this process prior to and as part of the User Acceptance Test.