(MM) Update Rollover Indicator
Updated: May 8, 2018
This is part of our Missing Market series for suggested additional transactions and actions
Parties should be able to change the Rollover Indicator without changing or updating the read. And this should be possible by any of the read's stakeholders, not just the original provider.
When reads are submitted, they include a rollover indicator to show whether the meter has passed back through zero. If the second meter read is lower than its previous read, CMOS needs to know whether to treat the read as positive (and having a rollover) or negative (where it is correcting a previously high reading).
What's the problem?
If the indicator is incorrect, it can have a significant effect on volume - and therefore settlement.
There are already processes in place to make the correction but these involve removing the previous read and inserting another. This can be a convoluted process and can also affect read submission performance reporting (at least in theory). Plus it requires the read owner to do all that. Let's say a retailer submits a read with the wrong indicator. A wholesaler who sees that needs to advise the retailer, who then has to make the various changes.
Any potential for gaming?
The reads and rollover indicator may have been correct at the time of submission.
Let's say we have the following reads, with the rollover indicator and subsequent volume on a 5 digit meter:
99000 (0) 
01000 (1) 
03000 (0) 
All straightforward and linear. But what if the retailer were to remove that 3rd read of 01000?
The 03000 has not needed resubmission so there is no questioning of the rollover indicator.
So, if it were deliberate and timed carefully, there could be a larger negative volume (spread over each of the intervening settlement periods), which may help their cash flows, at least. Sure, there are processes for resolving this but that takes time and effort - and good detection mechanisms.
What's the idea?
Basically, we think any stakeholder (being any market party that is affected by the read) should be able to submit a TCORR to change the Rollover indicator on a read (provided all other details are the same).
The logic on the CMOS side would be the same that CMOS applies when it gets a read: if the read would pass the usual test with the proposed rollover indicator, then proposed change goes ahead. If not, reject. This will mean that the transaction cannot work for reads that previously failed tolerance validation anyway, in which case the fuller process would need to be applied. But it would mean that significant errors can be fixed more easily, without losing the read submission history and without compromising the integrity of the validation rules. After all, the rollover indicator is not a true attribute of a read but instead a judgement relative to the previous read, which itself may not be fixed.