Update from ERCOT Retail Market Services to RMS June 12, 2003

1. Update from ERCOT Retail Market Services to RMS June 12, 2003

2. Retail Market Update Topics • FasTrak Update • Flight Test 0703 Update • SCR727 – Day to Day and Data Extract Variance Stats • 2002 Data Clean-up Process • Cancellation Requests for Drop to AREP • Market Synch Project - status • Default Profile Analysis

3. FasTrak Seminar Update

4. FasTrak Seminar Update • ERCOT hosted a FasTrak Seminar on May 22, 2003. • Participation: • 13 Competitive Retailers • 5 TDSPs • ERCOT • Total of 46 attendees • Topics covered: • Origination of FasTrak • Functionality, design, and extensibility of FasTrak • How enhancements to FasTrak can better serve the user

5. FasTrak Seminar Update Follow Up: • Concerns and questions are being addressed by the FasTrak Business team • Suggestions/requests for enhanced functionality are currently being coded into the FasTrak development area in preparation for release. • If anyone has further concerns that were not addressed at the FasTrak seminar, the FasTrak Business Team can make arrangements to discuss concerns which should be detailed in an email to your Retail Account Manager.

6. Flight 0703 Planning Update

7. Flight 0703 Planning Update 24 CRs signed up for Flight 0703 • 5 new CRs signed up to test as part of their REP Certification • 19 current CRs signed up to test in other TDSP areas, functionality or additional DUNS numbers PEC is testing in Flight 0703, following the IOU TDSP model for transaction flow. • A total of 13 CRs have elected to test with PEC. • One CR has volunteered to test all scripts with PEC to test PEC’s ability to transact with ERCOT, CRs and the market. • Remainder of CRs who have elected to test with PEC will test a shortened list of scripts (approved by TTPT script sub-team).

8. Flight 0703 Planning Update Connectivity Kick-Off call was held on Friday, June 6. • 100% participation by Market Participants and/or Service Providers. • >75% of MP already had scheduled their connectivity testing • An update call will be held on Friday, June 20 to check progress. Frame 01 of transactions is scheduled to begin July 14. Flight scheduled to end Sept. 5.

9. FasTrak • Day to Day Stats • Data Extract Variance Stats

10. FasTrak 2003 “Day to Day”Stats (as of 06-11-2003) • Of the 343 In Progress with ERCOT, 131 are resolved and awaiting other party resolution check off • 6 remaining issues for 2002 are not included in the numbers to the left • 1 is in progress pending a response from the CR • 5 are in progress pending a response from the TDSP

11. FasTrak 2003 Data Extract VarianceStats (as of 06-11-2003) • Of the 130 Service History Issues In Progress with ERCOT, 5 are resolved and awaiting other party resolution check off • 290 total issues submitted to ERCOT affecting Jan/Feb’02 trade month • 84 are in progress with ERCOT • 9 are in progress Pending a response from the TDSP • 10 are in progress Pending a response from the CR • 187 were Resolved or Rejected • 65 issues affecting Jan/Feb’02 trade months were received by ERCOT after the resettlement date

12. Pre-TX SET 1.5 Data Clean-up

13. Pre-TX SET 1.5 Data Clean-up Process In-Review - currently 207 (Original Quantity = 863) Remaining 207 have a meter reads • 113 can be reprocessed (TDSP Data was submitted after expiration) • 94 ERCOT to reset expiration row and TDSP send transaction (No 814_04 or 814_25 present at ERCOT) Scheduled - currently 11,038 (Original Quantity =17,676) No Meter Reads present Process: • ERCOT to provide TDSPs updated list of ESI IDs by COB, Wednesday June 18th • TDSP give OK to cancel or provide 867 to complete process • ERCOT requests response to cancel transaction or confirmation that the 867 will be sent to complete by July 12th. • If no response is provided to ERCOT by July 12th, ERCOT will cancel the transactions

14. Pre-TX SET 1.5 Data Clean-up Process Cancelled with Exception - currently 1,618 with Meter Reads present Process: • Provide TDSPs updated list of ESI IDs • TDSP give OK to remain cancelled or coordinate transaction submittal to ERCOT • ERCOT requests response to cancel transaction or confirmation that the 867 will be sent to complete by July 12th. • If no response is provided to ERCOT by July 12th, the service orders will remain cancelled. Issue: These outstanding situations are causing NFI, out-of-sync issues and ultimately settlement issues. Recommend RMS request TDSPs and ERCOT to respond by July 12th for approval of cancellation or completion of transactions. Recommend RMS request TDSPs and ERCOT to resolve these issues by August RMS meeting. ERCOT will report at RMS July 12th meeting an update of the Pre-TX Set 1.5 Clean-up Process

15. Cancellation Requests for Drop-to-AREP

16. Canceling Drop-to-AREP Transactions Scenario/Situation: ERCOT has received requests to cancel pending Drop-to-AREP transactions. Scenario 1: A CR indicated the drop to AREP was submitted in error. Scenario 2: While a drop to AREP is pending at ERCOT, the TDSP receives a safety net move in. TDSP cancels the drop in their system and allows the move in to process thereby avoiding dropping the new customer to the AREP. Scenario 3: A drop to AREP and switch are both concurrently processing at ERCOT. ERCOT’s system determines that the drop to AREP should win because it is scheduled sooner and cancels the switch. The TDSP completes the switch and cancels the drop. The TDSP requests that ERCOT cancel the drop and complete the switch to match their system.

17. Canceling Drop-to-AREP Transactions Issue/Problem: Protocols Section 15.1.2 Drop to Provider of Last Resort or Affiliate REP “A Drop by a CR is binding on the CR and cannot be cancelled or rescinded.” Caveat: ERCOT would like to note that this request is a short-term solution for the interim until the approval of Customer Protection Ruling 25574. Question for RMS: Are there times when it is appropriate for ERCOT to manually cancel a Drop-to-AREP transaction?

18. Canceling Drop-to-AREP Transactions Proposed Solution: Scenario 1: RMS approve ERCOT canceling Drop-to-AREP transaction submitted in error by a CR provided the CR obtains TDSP and AREP approval and submits a FasTrak issue with appropriate documentation. Scenario 2: RMS approve ERCOT canceling Drop-to-AREP provided the TDSP obtains dropping CR and AREP approval and submits a FasTrak issue with appropriate documentation. Concerns: • Move-in date does not match Drop-to-AREP date – extended liability for dropping CR? Scenario 3: RMS approve ERCOT canceling Drop-to-AREP and completing the switch provided the TDSP obtains dropping CR and AREP approval and submits a FasTrak issue with appropriate documentation. Concerns: • This will definitely extend the liability for the dropping CR because by the concurrent processing logic the switch would have only been cancelled if it was scheduled further in the future than the Drop-to-AREP.

19. Market Sync Project

20. Market Sync Project as of 06-10-03 ERCOT requests that RMS approve closing out the Market Sync Project

21. Default Profile AnalysisRMSJune 12, 2003ERCOT - Austin

22. Objectives • Identified gap in SCR 727 Usage provided to CRs • Define NIDR default profiles and their use in the settlement process • Report recent ERCOT findings regarding the use of default profiles in various settlement conditions • Review statistics regarding TDSP and REP allocation of default profiles • Define IDR default profiles and their use in the settlement process • Discuss the impact of NIDR-to-IDR profile changes

23. SCR 727 Usage data provided to CRs • CRs receive usage for an ESI ID only for the period where they are the REP of Record • Difficult for a CR to always know with certainty what usage was used to scale a profile in the aggregation process • CRs should not assume that historical usage they receive from a TDSP has been successfully loaded into Lodestar • Difficult for a CR to determine from the 727 extract if a default profile will be used in settlements

24. NIDR Default Profiles • Used when actual data is not present within six months of trade date • Based on existing models (Shape vs. Magnitude) • Registration issues (“Active” status…) • TDSP updates to correct invalid profile assignments

25. Percentage of NIDR ESIIDs Using Default Profiles from Recent Settlements (by TDSP) .

26. Percentage of NIDR ESIIDs Using Default Profiles by Profile Type from Recent Settlements .

27. Percentage of NIDR ESIIDs Using Default Profilesby Profile Type from Recent Settlements .

28. Percentage of Default Profiled NIDR ESIIDsby CR from Recent Settlements .

29. IDR Default Profiles • Used when actual data is not present within eight weeks of trade date • Based on existing model (Shape vs. Magnitude) • Registration issues (“Active” status, invalid IDR assignment…) • 814_20 updates to change profile assignments

30. Proposed Resolutions CR knowledge of when default profile is used:Option 1ERCOT provide 12 month historical usage for any CR change (sort of a “switchers extract”)Option 2ERCOT provide report of ESI IDs for each settlement run that were settled with default profile (report by TDSP & CR)How ERCOT deals with IDR default profiles systematically:– Nine options discussed in stakeholder meetings last JuneResult:– Group agreed to scale existing IDR default profile– Created PRR 352 to address looking back beyond 8 weeks in estimating IDRs (not yet implemented)Possibly should revisit some of the other options (scaling IDR profile with NIDR usage, etc) because PRR 352 won’t address all issues .

31. Questions