The Authority s proposed design for real-time pricing Wellington

The Authority’s proposed design for real-time pricing Wellington briefing session 24 August 2017

Introduction

Outline and agenda Introduction and brief background Stepping through proposed RTP design Lunch Implementation and timeline Updated ‘hindcast’ for winter 2017 Wrapping up 3

Real-time pricing has been developed across multiple consultations since 2013: WAG recommended Authority ‘investigate settlement based on ex ante or real-time prices’ 2015: consulted on improving the spot market, decided to further explore real-time pricing (and ahead market/forecast accuracy) April 2016: consulted on 4 real-time pricing options August 2016: decided to develop full Code amendment details of Option B: ‘look-ahead’, dispatch-based real-time pricing 4

We expect RTP would have two fundamental effects on wholesale spot prices More actionable More resource efficient • consumers and participants can trust and respond to the prices they see in real-time • consumers and participants would be much less likely to regret their decisions • prices reflect the resources actually used to run the power system at the time 5

We expect RTP would deliver significant benefits We believe these changes to spot prices would deliver significant benefits across all three limbs of our statutory objective: ● greater competition between generators and consumers ● more efficient level of reliability (can rely equally on demand bids and generator offers) ● improved operational efficiency by removing extensive manual intervention and processing after the fact Removes barriers to new technologies and new business models that require a reliable and actionable price signal in real-time 6

We expect RTP to deliver significant benefits Our assessment found a net benefit of $53 million in the base case (net present value over 15 years at 6% discount rate) ● Total benefits of $77 million ● Total costs of $24 million Net benefit is primarily driven by greater levels of demand response Breakeven test: slightly more than a 0. 1% greater demand response in total system demand in peak periods would be enough 7

JOHN CLARKE General Manager System Operations and Innovation Transpower 8

DELIVERING FOR NEW ZEALAND, TOGETHER Partnership Innovation For New Zealand 9

The details of our real-time pricing proposal

Fundamental design principle: prices are set in realtime by the dispatch process used to run the system Prices struck every time the system operator issues dispatch instructions from the dispatch schedule These dispatch prices can be set by generator offers or nominated dispatch bids Interim price for trading period determined immediately from dispatch prices published in that period 11

Dispatch prices would come from the real-time dispatch schedule (RTD) RTD solves automatically every 5 minutes ● System operator decides whether to use each schedule (issue dispatch instructions) ● Can also run solve manually Prices would take effect when they are published on WITS ● what you see is what you get Interim price calculated automatically by the clearing manager immediately ● We also intend a progressive rolling average (projecting spot price for TP) 12

Striking prices in real-time means there must always be a feasible dispatch solution Problem: SPD must always solve RTD without infeasibilities or any manual intervention — needs quantities and prices to settle the market Solution: Assign default scarcity pricing values to any load not bid by purchasers — all inputs now have price and quantity, so no more infeasibilities Principle: Scarcity pricing is needed to signal value of shortage and give incentive for demand response 13

How do we get there? What we have now How it would change under our RTP design 14

Dispatch and settlement pricing are separate today Dispatchable demand from NRS ~25 mins earlier At least one set of dispatch instructions each trading period Pricing process allows four potential provisional pricing situations, which require manual resolution. A scarcity pricing situation may be declared after interim prices are calculated. Grid owner and participants provide metering inputs RTD infeasibilities Interim prices SCADA metering ‘RTP’ Trading period Pricing error can be claimed once prices are interim HSWPS Current indicative 5 min prices TP-1 VRP scarcity pricing Next day 15

RTP would integrate them into the single process Dispatchable demand from NRS ~25 mins earlier At least one set of dispatch instructions each trading period scarcity pricing + reserve CVP Pricing prices are publishedpotential provisional pricing situations, which all Interim process allows four immediately after the trading period, derived from require manual published in A scarcity pricing situation may be declared after dispatch prices resolution. that period. interim prices are calculated. infeasibilities Grid owner and participants provide metering inputs Interim prices RTD VRP SCADA metering DD moves to dispatch schedule TP-1 Dispatch ‘RTP’ prices published to Current indicative 5 WITS min prices Trading period Pricing error can be claimed once prices are interim HSWPS scarcity pricing TP+1 Next day 16

Three general themes to keep in mind Things we don’t need any more Things we must change to make RTP work Enhancements that strengthen the benefits 17

No more ‘situations’ High spring washer: not needed; default scarcity pricing and demand bids act as a limit Infeasibilities: removed by definition; RTD now has price and quantity for all inputs Metering: not used in dispatch SCADA: input automatically changes to next highest priority source in SDV Scarcity pricing: fully incorporated in dispatch schedule (no ex-post adjustment) 18

No more separate final pricing schedule, so no role for pricing manager Final pricing schedule ceases to exist — no separate ex-post pricing process No longer any role for a pricing manager ● Calculating interim prices from dispatch prices is a simple database function (clearing manager) ● We propose system operator undertakes any manual error claim process (Current indicative 5 -min ex-post ‘RTPs’ also discontinued) 19

Scarcity pricing would be fully incorporated into the forecast and dispatch schedules We propose the system operator assigns default scarcity pricing values to all load not bid explicitly by purchasers Split over three blocks using the scarcity pricing values under current Code provisions Proportion of un-bid load 20% of load reflects reasonable limit of distributor load control Value first 5% $10, 000/MWh next 15% $15, 000/MWh last 80% $20, 000/MWh These blocks can set dispatch prices, triggering instructed emergency load shedding 20

Why default scarcity pricing blocks at 5% and 15%? First 5% block: load shedding and scarcity prices spreads from affected GXP to others in the affected region (as seen today in $500 k deficit generation CVPs) ● Avoids shedding load entirely at the first constrained GXP if usingle block (or large proportion) ● Generation-weighting in current scarcity pricing provisions also spreads the price effect ● 5% of national or island load is significant quantity Other blocks: costs should rise with quantity of forced load shedding, reflecting severity 21

Scarcity pricing would be fully incorporated into the forecast and dispatch schedules The system operator would assign default scarcity pricing values at all GXPs to all load not bid* by purchasers (full details in Appendix G) PRS *Jargon buster Any bid can set the price in the PRS (shows stated intent in response to price) • only forecast load NRS dispatch • all forecast load • nondispatch bids *Jargon buster Only dispatchable bids can set dispatch prices. Anything else is a ‘non-dispatch bid’ Default scarcity pricing blocks are proportional — not used if all load at GXP bid by purchasers 22

Scarcity pricing blocks likely appear in forecast schedules before instructing emergency load shedding Scarcity pricing block(s) not fully supplied in forecast schedules Outside gate closure: issue Warning Notice GEN Generators and dispatchable demand providers can change offers/bids inside gate closure Inside gate closure: issue Grid Emergency Notice Emergency provisions under Technical Code B, Schedule 8. 3 Not fully supplied in RTD: instruct emergency load shedding to balance supply 23

Scarcity pricing blocks trigger instructed emergency load shedding in dispatch Scarcity pricing provides clear and actionable signal of shortage, and the value of demand response ● Strong incentives to maximise generation (supply) and reduce discretionary load (demand) ● Warning and Grid Emergency notices call for revisions to generation offers and dispatchable demand bids — load shedding signalled ahead of time could be avoided ● But scarcity pricing applies if load in those blocks not fully supplied, preventing inefficient price suppression 24

GEN process — load shed • No expectation of increased occurrence • No change to processes at go-live • Future state? • Transpower preference: electronically direct to EDB • Electronic Dispatch Facility (EDF) Phase 3 25

Break for questions

We would still relax reserve cover before invoking emergency load shedding Currently, reserve cover can be relaxed in dispatch if supply cannot otherwise meet expected demand ● Prices are manually adjusted ex-post to account for this, but only an approximation Objective: prices should signal the long term value of not meeting reserve requirement ● Investment in a unit of capacity should have equal value for energy or reserve 27

A unit of capacity should be equally valued for energy and reserve We propose to apply a reserve shortage CVP in the dispatch schedule ● CVPs for both FIR and SIR separately and combined ● If marginal this reserve shortage CVP would set the dispatch price Relaxing reserve should be a rare contingency measure But used before emergency load shedding, and should signal equal value of capacity Set CVP just below first default scarcity pricing block ($10, 000/MWh) 28

We propose to relax reserve before dispatching generation or reserve offered above the shortage CVP We propose to relax reserve (CE risk) even if generation or reserve offers are available at a price above the reserve shortage CVP ● This is a change from current practice where all offers are likely to be used — current CVP for reserve shortfall infeasibility is $100, 000/MWh If this is not enough to balance demand, default scarcity pricing would become marginal and trigger emergency load shedding Scarcity pricing is assigned by default — purchasers can choose to bid their demand at a higher price 29

Illustrating the dispatch order of system resources Dispatch price under RTP $$$ higher-priced (dispatchable) demand bid Demand reveals preference Demand bids indicate willingness to pay; if dispatchable, allow prices to rise above scarcity value higher-priced generation offer 3 rd default scarcity pricing block 2 nd default scarcity pricing block Emergency load shedding Load not bid explicitly by purchasers 1 st default scarcity pricing block reserve shortage CVP ‘normal’ generation offers $ 30

In practice, we do not expect significantly different outcomes under RTP than seen today Very few reserve offers above $10, 000/MWh (only 2 since 2013) It is preferable to relax security on rare occasions than use all resources no matter their cost Again, (dispatchable) demand bids can reveal purchasers’ willingness to pay for higher-priced resources 31

No more cumulative price limit for scarcity pricing Currently, scarcity pricing does not apply if average price for last week exceeds $1, 000/MWh ● sometimes referred to as the cumulative price threshold or limit ● ‘normal’ pricing applies instead But normal prices could be lower or higher than scarcity prices (depending on specific circumstances) 32

No more cumulative price limit for scarcity pricing We propose deleting the threshold under RTP because: ● any intervention after the fact reduces certainty of real-time prices ● it could encourage strategic behaviour if cumulative prices are close to threshold ● RTP would encourage transition from emergency conditions (system operator instructing distributors to manage load) to contracted arrangements between retailers and distributors (ie, no need for instructed load management) ● rolling outages likely to be used if curtailment needed repeatedly in real-time UTS provision remains available 33

Break for questions

What happens in a market system outage? • System operator may have to use SAD • Comms failure to WITS • Something else? Dispatch prices must be actionable: the price you can see (on WITS) is the one that counts • Last dispatch price good till replaced • Fall back to PRS if outage extends past trading period • Interim price calculated on what was visible 35

Dispatchable Demand (DD) • Creates a 2 -sided market • Un-signalled demand response less efficient • Currently ‘pre-dispatched’ from the NRSS • Intention to move DD to the dispatch schedule • 5 min dispatch cycle for load • EDF 3 • RTP means less obligations for DD participants 36

Dispatch schedule — current GXP load • All non-bid load is a forecast – next 5 min • Manual or automated • Currently ‘top-down’ • Total load = generation – losses • Distributed to region • Island Distributed to GXP Region GXP 37

Dispatch schedule — RTP GXP load • All non-bid load is a forecast – next 5 min • manual or automated • Proposal is ‘bottom-up’ • GXP load = current metering + ‘forecast’ Island Region GXP 38

Changes to load inputs — ION meters • Grid Owner revenue quality ION meters are ‘real-time’ • Include ION meter data as primary source of GXP load • Fall-back options as now • SCADA data validation (SDV) 39

Disconnected nodes • Challenge is matching 30 -min transmission outages to dynamic load and a 5 -min schedule timeframe • ● Sensible price signals 2 options ￮ Define price by historic location factor, or ￮ Pre-defined alternate GXP list 40

Break for questions

Introducing ‘dispatch-lite’ We want to make it easier for smaller consumers to be dispatchable ● increase accuracy and efficiency of dispatch prices ● increase competition and participation We propose dispatch-lite as an alternative to full dispatchable demand ● A form of ‘dispatch-capable load station’, using existing nominated bid types ● Deliberately and carefully minimised new terms in the Code Note: CBA doesn’t rely on it, minimal cost (eg, possibly new bid codes) 42

Dispatch-lite is a trade-off between ease of use and certainty over participation Less onerous With some consequences ● Can set dispatch price ● No constrained on or off ● No need for real-time telemetry ● ● Dispatch ‘notifications’, not full weight of instructions Participation at system operator’s discretion ● Revoked if repeatedly fail to comply with dispatch notifications ￮ No breach if choose not to comply (but must notify immediately) 43

Final prices: time-weighted average gives the best balance between efficiency and simplicity time-weighted mean median arithmetic mean volume-weighted mean captures effect of price extremes ü ü ü all dispatch prices have an effect ü ü ü accounts for duration of dispatch prices ü ü ü behaviour within the period affects price ü ü ü no undesirable effects on risk management contracts (reference nodes have no load) ü ü ü 44

We could keep some form of pricing error process Automated Manual claim In either option error must be material Choice means trade-offs between actionability|certainty and ability to allege errors Agree on tests in advance and fully automate when striking final prices Translate and update current process into RTP Increases certainty (final prices known quickly) Spot prices retain some uncertainty (claim may be made while interim) Code proposal is manual, but we’re keen for your thoughts (including who should do it) Limits* ability to amend any error not captured automatically Apparent errors can be challenged UTS provisions of course remain 45

We propose the system operator is best placed to manage a manual pricing error claim process We don’t consider the costs of retaining the pricing manager service provider role purely for this purpose are warranted It is not a clearing function We considered the Authority managing the process, but on balance prefer the system operator • Claims are publicly notified • The Authority has the tools and ability to critically assess the system operator’s report • Dispatch prices are set by the system operator’s processes in the first place 46

We propose allowing reoffering and rebidding within the trading period — under strict limits Currently, any revision to offers or bids within the trading period handled manually by system operator ● Reduces transparency — cannot readily distinguish from system operator exercising discretion ● Prices based on bids/offers at start of trading period We want offers and bids to reflect most accurate information ● Changes remain subject to the same strict limits as today ● Only permitted when formal notices in effect or for bona fide physical reasons 47

Constrained on and off payments would be based on the last valid bid or offer for the trading period We propose the final valid bid or offer in the trading period should apply for constrained payments 48

Break for questions

Implementation and timelines

Significant amendments to the Code are needed

Managing the Code amendment 52

Transpower system changes Simple right? • Dispatch schedule • Trading website (WITS – NZX) • What else? Biggest change sinception of current market system in July 2009 53

Transpower system changes • Changes to multiple complex domain areas of the Market System • Includes some high-impact areas Impacted capabilities in red 54

Transpower system changes • End-to-end changes • Inputs • Schedule(s) • Outputs • Few areas untouched Impacted functions in red • ( 55

Transpower delivery 56

Transpower delivery Phase 1: Scarcity • Scarcity bids • Demand/Bid Clearing in RTD • Scarcity Load Shed & Restore Phase 2: ESB/Dispatch • Scarcity Dispatch • Participant Notification of Cleared Bids • Schedule Publication Phase 3: RTP Go Live • Implementation of RTP • Dispatch of Dispatchable Demand • Awareness for Secure Operation • Operator training Phase 4: Decom • Decommissioning • Remove FP & current 5 -min prices 57

Transpower delivery • Changes to WITS • ‘like-for-like’: • • • 5 min prices now dispatch prices Final prices More information published from dispatch schedule • Lots of communication/time to go yet. 58

Updating the ‘hindcast’ for winter 2017

Indicative price effects from RTP Consultation paper includes ‘hindcast’ estimate of potential RTP effect on spot prices and charges to consumers ● RTP initial on year one, vs. full effect ● Substituted first scarcity pricing value ($10 k/MWh) in place of infeasibilities RTP initial effect is unrealistic, downside scenario using conservative assumptions ● Nobody prepares for or changes behaviour in response to RTP in any way Updated hindcast with prices from recent dry winter (April 2015–July 2017)

Updating the RTP ‘hindcast’ for winter 2017 61

Updating the RTP ‘hindcast’ for winter 2017 Previous RTP initial effect Updated RTP initial effect Previous RTP full effect Updated RTP full effect Unresponsive industrial 1. 1% 1. 2% 0. 0% Unresponsive residential 0. 6% 0. 7% 0. 1% Responsive industrial 0. 0% -1. 1% -1. 2% Responsive residential 0. 0% -0. 5% -0. 6% 62

Wrapping up

What next? Submissions close 26 September We’ll publish this presentation Working on a written Q-and-A justin. wood@ea. govt. nz 64

Thank you