Settlements & Billing / Version: 5.0
Configuration Guide for: Convergence Bidding HASP Energy, Congestion, and Loss Settlement / Date: 1201/31/131

Settlements & Billing

BPM Configuration Guide:Convergence Bidding HASP Energy, Congestion, and Loss Settlement

CC 6053

Version 5.0

CAISO, 2018 / Page 1 of 11
Settlements & Billing / Version: 5.0
Configuration Guide for: Convergence Bidding HASP Energy, Congestion, and Loss Settlement / Date: 1201/31/131

Table of Contents

1.Purpose of Document

2.Introduction

2.1Background

2.2Description

3.Charge Code Requirements

3.1Business Rules

3.2Predecessor Charge Codes

3.3Successor Charge Codes

3.4Inputs – External Systems

3.5Inputs - Predecessor Charge Codes or Pre-calculations

3.6CAISO Formula

3.7Output Requirements

4.Charge Code Effective Date

1.Purpose of Document

The purpose of this document is to capture the requirements and design specification for a SaMC Charge Code in one document.

2.Introduction

2.1Background

On September 21, 2006, FERC issued an Order directing “…the CAISO to file tariff language for our review for the implementation of convergence bidding within 12 months after the effective date of MRTU Release 1..” FERC recognized that, although Convergence Bidding was important, implementing it simultaneously with MRTU Release 1 would impede the CAISO’s ability to timely implement MRTU. By implementing Convergence Bidding and other elements of Markets and Performance (“MAP”) in a phased approach following implementation of MRTU, the CAISO should be able to successfully balance the need to timely implement and stabilize the “base” MRTU design while gaining the benefits of adding market efficiencies within a reasonable time after MRTU Go Live.

The California ISO (the CAISO) became engaged in an on-going stakeholder process to develop the key features for convergence bidding that began in summer of 2006. The ISO requested final comments from stakeholders on the Draft Final Proposal for Convergence Bidding by close of business October 14. Then, on October 21, 2009, CAISO issued a Board memo that described and presented the final policy on convergence bidding for Board approval. On October 29, 2009, CAISO Board of Governors approved the proposed market enhancement, convergence bidding, as described in the Board memo.

While the MRTU design provides a complete framework for a nodal-based electricity market that generates Locational Marginal Prices (LMPs), the elements contained within MAP will increase the efficiency and liquidity of the MRTU design by adding bidding tools, creating incentives for increased supply/reduced demand and removing impediments to bidding. These enhancements can be expected to increase participation in the CAISO market, provide more robust competition for supply and demand and, ultimately, may reduce prices paid by end users.

Convergence Bidding tends to cause DAM and RTM prices to move closer together, or "converge," thus the name Convergence Bidding. The narrowing of price differences between the two markets reduces incentives for under-scheduling Load in the DAM by reducing potential financial benefits for waiting until the RTM. In addition to reducing price disparity Convergence Bidding also provides greater market transparency by providing bids that are explicit rather than implicit. Additionally, the increased market liquidity from convergence bidding can help mitigate the market power of physical suppliers. Some market participants can use convergence bidding as a risk management tool to hedge the possibility of a generator outage.

A Virtual Bid in Convergence Bidding is defined to be either a Virtual Demand Bid or Virtual Supply Bid. A Virtual Demand Bid is a Bid submitted in the CAISO Day Ahead Market that, if cleared in the Integrated Forward Market (IFM), represents a commitment to purchase Energy at the price determined in the Day Ahead Market, and to sell any Virtual Award resulting from the Virtual Bid at the price determined in the Real Time Market. Likewise, a Virtual Supply Bid is a Bid submitted in the CAISO Day Ahead Market that, if cleared in the Integrated Forward Market, represents a commitment to sell Energy at the price determined in the Day-Ahead Market, and to buy the same quantity back at the price determined in the Real Time Market.

2.2Description

This charge code settlesinter-tie based Virtual Awards that impact the HASP energy settlement.

For a Virtual Supply Award for an import at an intertie, the charge shall be the product of the DA cleared MW multiplied by the hourly HASP LMP at the intertie; while for a Virtual Demand Award for an export at an intertie, the payment shall be the product of the DA cleared MW multiplied by the hourly HASP LMP on that node. The hourly HASP LMP at a node is the simple average of 15-min HASP Intertie LMPs at the applicable intertie for the relevant Trading hour.

This charge code will also compute a CAISO total congestion revenues calculated as DA Virtual Awards multiplied by hourly HASP MCC across all Eligible PNodes and APNodes for convergence bidding. This total congestion amount will be allocated as part of CC 6774, Real-Time Congestion Offset.For a given intertie, the hourly HASP MCC is the simple average of 15-min HASP MCCs at that node for the relevant Trading hour.The CAISO total net revenue or payment from the settlement of this charge code net of congestion revenues will be allocated as part of CC 6477, Real-Time Imbalance Energy Offset.

3.Charge Code Requirements

3.1Business Rules

Bus Req ID / Business Rule
1.0 / The settlement amount per hour per SC for its inter-tie Virtual Awardis the product of the Hourly HASP LMP at a tie point node and the DA Virtual Award liquidated in HASP.
1.1 / All inter-tie based Virtual Awards (both import and export) are to be liquidated in HASP/RT shall be settled in this charge code.
An indicator that identifies whether a Virtual Award is inter-tie based or not shall be provided by an upstream system to Settlements. (Fact)
1.2 / The CAISO will charge each Scheduling Coordinator with DA Virtual Supply Awards liquidated as demand in HASP/RT(which equates to negative DA Virtual Supply) at an Intertie an amount equal to the simply hourly average of the fifteen (15) minute HASP Intertie LMPs multiplied by the negative of Day-Ahead MWs of Virtual Supply Awards.
1.3 / The CAISO will pay each Scheduling Coordinator with DA Virtual Demand Awards liquidated as supply in HASP/RT(which equates to negative DA Virtual Demand) at an Intertie an amount equal to the simple hourly average of the fifteen (15) minute HASP Intertie LMPs multiplied by the negative of Day-Ahead MWs of Virtual Demand Awards.
1.4 / The Hourly HASP LMP is the simple average of the four 15-min HASP Intertie LMPs at Eligible PNode/APNodes. (Fact)
1.5 / This charge code follows the sign convention that a charge to the SC will be positive, and that a payment to SC will be negative. This will be reflected in the formulas.
1.6 / The hourly Settlement Amount per SC is the net of its payments and charges.
1.7 / This Charge Code shall be calculated daily on an hourly basis.
2.0 / Virtual Supply Bids and Awards and Virtual Demand Bids and Awards, as their names imply, are virtual in the sense that they are not backed-up by a physical supply resource or physical demand. (Fact)
2.1 / A Virtual Demand Bid is defined to be a Bid submitted in the CAISO Day-Ahead Market that, if cleared in the Integrated Forward Market (IFM), represents a commitment to purchase Energy at the price determined in the Day-Ahead Market, and to sell the same quantity back at the price determined in the HASP or Real Time Market, as applicable. (Fact)
2.2 / A Virtual Supply Bid is defined to be a Bid submitted in the CAISO Day-Ahead Market that, if cleared in the Integrated Forward Market, represents a commitment to sell Energy at the price determined in the Day-Ahead Market, and to buy the same quantity back at the price determined in the HASP or Real Time Market, as applicable. (Fact)
2.3 / Virtual Supply Awards are Virtual Supply Bids that are cleared in the IFM, whileVirtual Demand Awards are Virtual Demand Bids that are cleared in the IFM. (Fact)
3.0 / The Congestion revenue from DA Virtual Demand Awards liquidated in HASP as supply from inter-tie based bids for Trading Hour h shall be computed as the sum of the product of (1) negative of DA Virtual Demand Award, and (2) the Hourly HASP MCC at each inter-tie based Eligible PNode or Eligible APNode.
3.1 / The Congestion revenue from DA Virtual Supply Awards liquidated in HASP as demand from inter-tie based bids for Trading Hour h shall be computed as the sum of the product of (1) negative of DA Virtual Supply Award, and (2) the Hourly HASP MCC at each inter-tie based Eligible PNode or Eligible APNode.
3.2 / Following a sign convention change that DA Virtual Demand Award quantities in the settlement formula section are converted to negative values, the above two business rules can be combined and that the CAISO total Congestion revenue from DA Virtual Awards liquidated in HASP/ from inter-tie based bids for Trading Hour h shall be computed in this charge code as the sum of the product of (1) DA Virtual Award, and (2) the Hourly HASP MCC at each inter-tie based Pnode or Apnode.
3.3 / The Hourly HASP MCC is the simple average of the four 15-min HASP MCCs at Eligible PNode/APNodes. (Fact)
4.0 / For adjustments to the Charge Code that cannot be accomplished by correction of upstream data inputs/recalculation or operator override Pass Through Bill Charge logic will be applied.

3.2Predecessor Charge Codes

Charge Code/ Pre-calc Name
None

3.3Successor Charge Codes

Charge Code/ Pre-calc Name
CC 6477 – Real Time Imbalance Energy Offset
CC 6774 – Real Time Congestion Offset

3.4Inputs – External Systems

Row # / Variable Name / Description
1 / BAHourlyDAVirtualAwardNodalQuantity BA’aj’y’mdh / The input provides the DA Virtual Award cleared Energy quantity in association with Business Associate B, Aggregated PNode type A’, bid type a, Eligible PNode/Aggregated PNode j’, Node Location Type y’, Trading Month m, Trading Day d, and Trading Hour h. (MW)
An import tie virtual bid is represented by a virtual bid of bid type a = “SUP” and node type y’ = “TIE”. The sign of the quantity for this case is positive.
An export tie virtual bid is represented by a virtual bid of bid type a = “DMND” and node type y’ = “TIE”. The settlement formulas in the current charge code assume that for this specific type of bid, the sign of the quantity is negative. This matches the payments and charges sign convention when coming up with the settlement amounts for supply and demand virtual bids in this charge code, respectively.
2 / HASP15minFinancialNodeLMPPrice j’hc / The Locational Marginal Price (LMP) for financial node j’ that cleared in the HASP for Trading Hour h, 15-minute commitment interval c. ($/MWh)
These are mapped from Pnode and APnode LMP prices for HASP Energy.
IFM/RTM applications is expected to provide the base data for this. Whenever the financial node is not a PNode or an APNode such as a Trading Hub, then for data mapping purposes, special derivation of this value will be done by an upstream system.
3 / HASP15minFinancialNodeMCCPrice j’hc / The Marginal Cost of Congestion (MCC) for financial node j’ that cleared in the HASP for Trading Hour h, 15-minute commitment interval c. ($/MWh)
These are mapped from Pnode and APnode MCC prices for HASP Energy.
IFM/RTM applications is expected to provide the base data for this. Whenever the financial node is not a PNode or an APNode such as a Trading Hub, then for data mapping purposes, special derivation of this value will be done by an upstream system.
4 / PTBChargeAdjustmentBAHourlyHASPEnergyCBAmt BJmdh / PTB adjustment variable for this Charge Code, amount per BA ID B, identified by PTB ID J, per Trading Month m, Trading Day d, Trading Hour h. ($)

3.5Inputs - Predecessor Charge Codes or Pre-calculations

Row # / Variable Name / Predecessor Charge Code/ Pre-calc Configuration
None

3.6CAISO Formula

3.6.1BAHourlyVirtualAwardHASPSettlementAmount

BAHourlyVirtualAwardHASPSettlementAmountBmdh =

BAHourlyVirtualSupplyAwardHASPAmountBmdh

+ BAHourlyVirtualDemandAwardHASPAmountBmdh

3.6.2BAHourlyVirtualSupplyAwardHASPAmount

BAHourlyVirtualSupplyAwardHASPAmountBmdh=

BAHourlyDAVirtualAwardNodalQuantity BA’aj’y’mdh * HourlyHASPEnergyFinancialNodeLMPPricej’h

where y’ = “TIE”

and a = “SUP”

Implementation Note: The equation above is derived from the following equivalent equation since (-1)*(-1) = +1:

BAHourlyVirtualSupplyAwardHASPAmountBmdh=

(-1)*(-1* BAHourlyDAVirtualAwardNodalQuantity BA’aj’y’mdh )* HourlyHASPEnergyFinancialNodeLMPPrice j’h

where y’ = “TIE”

and a = “SUP”

The (-1) multiplier in front of the summation implements the payment/charge Settlements sign convention, and the (-1) multiplier in the quantity represents the liquidation of DA Virtual Awards in the HASP/RT.

The following formula was derived similarly.

3.6.3BAHourlyVirtualDemandAwardHASPAmount

BAHourlyVirtualDemandAwardHASPAmountBmdh=

BAHourlyDAVirtualAwardNodalQuantity BA’aj’y’mdh * HourlyHASPEnergyFinancialNodeLMPPricej’h

where y’ = “TIE”

and a = “DMND”

3.6.4HourlyHASPEnergyFinancialNodeLMPPrice

HourlyHASPEnergyFinancialNodeLMPPricej’mdh =

(1/4)*(HASP15minFinancialNodeLMPPricej’mdhc)

3.6.5CAISOHourlyTotalVirtualAwardHASPAmount

CAISOHourlyTotalVirtualAwardHASPAmount mdh=

BAHourlyVirtualAwardHASPSettlementAmountBmdh

Note: This is provided as part of reporting structure and is not configured as an individual charge type. This is shown as a reporting BD in the BD matrix file.

3.6.6CAISOHourlyTotalVirtualAwardHASPCongestionAmount

CAISOHourlyTotalVirtualAwardHASPCongestionAmountmdh =

BAHourlyDAVirtualAwardNodalQuantity BA’aj’y’mdh * HourlyHASPEnergyFinancialNodeMCCPricej’h

where y’ = “TIE”

3.6.7HourlyHASPEnergyFinancialNodeMCCPrice

HourlyHASPEnergyFinancialNodeMCCPricej’h =

(1/4)*(HASP15minFinancialNodeMCCPricej’hc )

3.7Output Requirements

Output Req ID / Name / Description
In addition to any outputs listed below, all inputs shall be included as outputs.
1.0 / BAHourlyVirtualAwardHASPSettlementAmountBmdh / The hourly settlement amount per BA ID Bfor its cleared DA virtual bidsassessed at HASP prices for Trading Month m, Trading Day d, Trading Hour h. ($)
1.1 / CAISOHourlyTotalVirtualAwardHASPAmountmdh / Sum of BAHourlyVirtualAwardHASPSettlementAmountBmdh across all BA IDs. ($)
1.2 / BAHourlyVirtualSupplyAwardHASPAmountBmdh / The hourly settlement amount per BA ID B per node j’ for cleared DA virtual supply bids assessed at HASP prices for Trading Month m, Trading Day d, Trading Hour h. ($)
This represents the settlement amount for DA Virtual Supply bought back in HASP as demand.
1.3 / BAHourlyVirtualDemandAwardHASPAmountBmdh / The hourly settlement amount per BA ID B per node j’ for cleared DA virtual demand bids assessed at HASP prices for Trading Month m, Trading Day d, Trading Hour h. ($)
This represents the settlement amount for DA Virtual Demand sold back in HASP as supply.
2.1 / CAISOHourlyTotalVirtualAwardHASPCongestionAmountmdh / The CAISO net total congestion revenues from cleared DA virtual bids assessed at HASP prices for Trading Month m, Trading Day d, Trading Hour h. ($)
2.2 / HourlyHASPEnergyFinancialNodeLMPPricej’h / Hourly simple average of the four 15-minute LMPs for the HASP at node j’ for Trading Hour h.
3.0 / HourlyHASPEnergyFinancialNodeMCCPricej’h / Hourly simple average of the four 15-minute MCCs for the HASP at node j’ for Trading Hour h.

4.Charge CodeEffective Date

Charge Code/
Pre-calc Name / Document Version / Effective Start Date / Effective End Date / Update Version Type
CC 6053–Convergence Bidding HASP Energy, Congestion, and Loss Settlement / 5.0 / 02/01/11 / Open3/31/14 / Configuration Impacted
CAISO, 2018 / Page 1 of 11