1. 1 Move-In Move-Out Task Force Update to RMS May 15, 2003

2. 2 Solution to Stacking Solution to Stacking Design Stacking  A method that allows CRs, ERCOT, and TDSPs to accept (and process) multiple, non- sequential transactions concurrently on a single ESI ID.  Requires new business rules to sequence multiple transactions.  May require system changes for market participants  The design approach for the solution to stacking involves using the current market structure to support the solution.  Whenever possible, operating logic is designed at ERCOT to help with consistent execution of the operating rules across the market and to centralize the development and implementation effort.

3. 3 Solution to Stacking Solution to Stacking Design Benefits expected  Significant reduction in NFI rejects  Significant reduction in need for Safety Net Move-Ins  Better manages customer expectations (Dates, billing, etc.)  Fewer backdated clean up efforts  Fewer Cancel/Re-bills  Helps keep systems in sync  Reduces UFE  Reduces transaction volume  Expedites connecting and billing the customers by the correct CR  Improves transaction reliability

4. 4 Solution to Stacking Business Problem Existing NFI logic forces an unreasonable amount of dependency on labor intensive workarounds. Execution of workarounds are causing synchronization issues between market participants. Lack of synchronization leads to improper billing and mismanagement of customer expectations Solution All valid transactions will be accepted and processed based on a set of market rules. Drop notifications will be sent at a point in time where the proper recipient can be positively identified. Rule based cancellations are sent on a pre- determined timeline with enough time for the recipient to react. Summary of Changes: Manage customer expectations by accepting and processing all valid requests. Impact Level Efficiency Communication Competition

5. 5 MIMO Solution to Stacking Schedule 3/26/03High-level Requirements Specifications Finalized 3/28/03Requirements distributed to market for comment 4/17/03End of comment period 4/22/03Joint meeting between MIMO and Tx SET 4/24-25/03MIMO team comment review –Clarifications made to high-level requirements –Responses to comments drafted 5/7/03Market Educational Seminar 5/9/03Responses to comments distributed 5/15/03RMS vote on High Level Requirements 5/20-21/03MIMO team begin work on PRR Early JuneFirst meeting of Market Coordination Team

6. 6 Request for Vote Vote Requesting Vote from RMS –High Level Requirement Specifications –Market coordination team Made up of Market Participants (IT Project managers, developers, analysts, etc.) Maintain schedules and develope implementation timeline –Checkpoints in timeline »Production processing schedules for TDSPs and ERCOT distributed to market coordination team and RMS list serve »Details around Exception queue processing at ERCOT distributed to market coordination team and RMS list serve Manage scope change Clarifications

7. 7 Next Steps Requesting Vote from RMS in June –Approval of an anticipated May 2004 production implementation (Prior to summer) Task Force efforts –Continue coordinating with Tx SET on change controls –Protocol revisions Market Coordination Team –Meeting first time in early June