Decision Proposal 322 - Update Get Metrics Endpoint Schedule

[CDR-API-Stream]

This consultation is being raised to address an urgent change request initiated in standards maintenance: https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/606

This change has been requested by the ACCC to align the retirement dates for the Get Metrics endpoint to their published transition plan. The Data Standards Chair has approved that this change be considered as an urgent change to reduce the need for tranche 3 energy retailers from undertaking unnecessary build for their initial November 1st go live date.

A decision proposal is attached below: Decision Proposal 322 - Update Get Metrics Endpoint Schedule.pdf

It is expected that this change will be consulted on for a truncated period as the request has been made urgent. Feedback will close on 11th August.

[perlboy]

If ACCC is able to support V5 from November 1 it would be helpful if any Holder could transition, exclusively, to that from that date (or shortly after, perhaps January 2024). Biza.io has more than 15 brands coming online in November 1 so allowing (and requiring) only those brands to go live with something other than V3 actually doesn't materially alter our overall build (i.e. we will need to build both V4 or V5 and maintain V3 for non-November holders).

The reason stated in the transition plan is "to conduct Compliance and Enforcement monitoring using the data, including ensuring that the required metrics are being correctly implemented by Data Holders". It is unclear how having two sets of the same data of which there is only a partial overlap assists in this goal or how the Regulator would be able to validate "correct implementation". In the meantime Holders are required to collect two sets of metrics, with two different forms and triggers for nearly 6 months. While it may be of little consideration to the Regulator the collection of these metrics is a non-trivial cost so duplicating them has a material dollar value.

Why is there a desire to keep V3 alive if Holders are providing newer versions? Looking back at history it was ok to go live with only V3. The cynic might suggest this is because the much vaunted CDR Dashboard would need further changes...

[cuctran-greatsouthernbank]

Great Southern Bank welcomes to opportunity to provide feedback on this urgent decision proposal. I agree with @perlboy's comment that keeping Version 3 until May 2024 seems a bit long given the maintenance effort.

As stated in the transition plan, the ACCC intends to cease calling version 3 some time in Feb 2024. Given there is no scheduled obligation milestone around January 2024, we suggest Data Holders MAY retire Version 3 of Get Metrics endpoint from 11 March 2024 to align with Y24 #1 FDO.

We support the obligation date for Version 5 to be moved forward to 11 May 2024.

[perlboy]

Happy to take a timeline shrink on V3 retirement but I'm still questioning why it is necessary to have concurrent operation on this at all. The reasoning given by the Regulator seems flawed especially in the context of forcing all 90+ Holders to sustain the cost impact of doing so.

[CDR-API-Stream]

I believe the alignment of the v3 date was to allow for contingency in case the development work takes a little longer than planned.

I'm just writing the decision proposal so I will incorporate the suggestion that v3 can be retired once it is no longer being called or by May, whichever comes first.

@perlboy, I'll refer your feedback on the transition plan to the ACCC.

[CDR-API-Stream]

Please note that the decision proposal has been attached in the issue comment

[cuctran-greatsouthernbank]

Thanks @CDR-API-Stream for the prompt response. Can we please request the ACCC finalise the exact date to cease calling version 3? Even though it might seem like a small change by the ACCC, we still need to schedule the retirement in a release with proper testing.

[CDR-API-Stream]

Hi @cuctran-greatsouthernbank, I believe that the 13th May is the exact date that the ACCC is committing to. I've accommodated in the proposal a mechanism for this to be earlier if they find they are able to hit an earlier date.

[perlboy]

I believe the alignment of the v3 date was to allow for contingency in case the development work takes a little longer than planned.

To be honest and assuming this is the reason (which it seems to be) it's a bit hypocritical that the government is effectively "coding in" contingency at the increased cost of all participants. That isn't responsible use of private money and increases the chances of behaviour bordering on malicious compliance. It would be really helpful if government agencies held themselves to, and were willing to be accountable for, the same bar of excellence they expect of all other participants rather than prioritise their fancy and non-mobile native dashboard.

Please note that the decision proposal has been attached in the issue comment

On the proposal the main feedback I'd give is the statement "Multiple options have not been identified for this change as the change is relatively simple." is incorrect. The other option would be to adopt a similar strategy as that taken during the introduction of V2 -> V3 notably:

1. Allow November activators to choose the endpoint they are going live with between V3/V4/V5 so that existing solutions being deployed can prioritise delivering quality data to Consumers rather than metrics to be incorrectly displayed by the government
2. Allow existing Holders to retire V3 from a date of their choosing before the mandated date for V4 but from 1/11/2023
3. Alter the V4 obligation to 01/03/2023
4. Leave the V5 obligation of 13/06/2023

Unfortunately I suspect the public doesn't have full visibility of why the DSB is driving so hard on forcing the uplift of an endpoint that only the government accesses on the timeline in question (<6 months from Standards publishing) so a rational conversation is probably not forthcoming.

Conversely I'm not even sure that the likes of @NationalAustraliaBank (who seem to have suggested the above in DP288 originally), @commbankoss and @anzbankau have fully realised the scope of what is deliverable by November 1 because I suspect alarm bells would already be going off with respect to the work effort required.

For it's part at least, while Biza.io DSC doesn't see much point in elaborating further than the above they have raised a number of fairly significant issues with respect to the consent metrics within V5 (previously foreshadowed and seemingly unanswered) and to a lesser extent V4 which, with an obligation that effectively applies to all of our customers, seems likely to result in further requests for emergency standards changes.

[ACCC-CDR]

The ACCC has designed the transition plan to address risks based on our past experience of changes to Get Metrics. Implementation cost was a key consideration, and the costs and benefits of all reasonable approaches were weighed in deciding on our recommendation to the DSB.

The ACCC is staging the transition to Get Metrics v5 as the prime source of performance data to ensure performance data quality. This necessitates a transition period after 1 November 2023, where v3 continues to be the version relied upon for ACCC functions. The recommended length of this transition period is based on our past experience of receiving new Metrics. As outlined in the transition plan, we expect this transition to be substantially complete in early February 2024. However, full completion of this transition is dependent on a number of variable factors, including the overall level of compliance by data holders. A period beyond the forecast completion date is desirable to mitigate compliance risk, hence the suggestion of 13 May 2024 as the V3 retirement date.

Therefore, 13 May 2024 is the date on which we are sufficiently certain that we will no longer be calling v3 Get Metrics for any purpose. We suggested this retirement date to provide certainty to participants regarding the allowed retirement date, while also ensuring operational continuity

[perlboy]

The ACCC has designed the transition plan to address risks based on our past experience of changes to Get Metrics. Implementation cost was a key consideration, and the costs and benefits of all reasonable approaches were weighed in deciding on our recommendation to the DSB.

With the greatest of respect the ACCC wouldn't have a clue as to what the implementation costs of Holders are, because if they did that would involve the solution delivery partner of a majority of an entire sector (energy) and 20% of banking being asked for input (they weren't). Let's not pretend the ACCC looked at anything but it's own infrastructure before concocting some idea of consultation with a gun in hand as the Regulator to direct the Data Standards Body to do it's bidding.

In the words of a former prime minister the ACCC should essentially say “I don’t hold a hose, mate”, at least it wouldn't be oozing with the contrite approach it's taken in this response.

The ACCC is staging the transition to Get Metrics v5 as the prime source of performance data to ensure performance data quality. This necessitates a transition period after 1 November 2023, where v3 continues to be the version relied upon for ACCC functions.

So why are we rushing towards activating V4/V5 by November? Holders are being forced to ship something the ACCC won't initially use except for the purposes of frivolous and ecosystem damaging enforcement behaviour. Perhaps the ACCC could encourage some participants to use it's test ecosystem (What a great idea!) to verify their systems rather than using their Regulator position to compensate for it's lack of agility.

To be clear the issue here isn't the introduction of new endpoints, it's the expectation that there is a requirement for concurrent support of a single data set (Metrics) with two very divergent structures for a single consumer (ACCC).

The alternative to the suggestion above is to move V4 mandate to 01/03/2023 \while allowing participants to go live with V4/V5 in November 1 if they choose. Maybe the ACCC in it's detailed "transition plan" thought to itself it was saving the next tranche effort but such an assumption is, plainly, false, because the majority of the next tranche are using existing solutions in use by existing energy holders (i.e. V3 is already built).

The recommended length of this transition period is based on our past experience of receiving new Metrics. As outlined in the transition plan, we expect this transition to be substantially complete in early February 2024.

Well that's laughable in the context and knowledge that when Metrics V3 was released the ACCC was months late in starting to make requests to it (particularly those using client authentication) for new Holders coming online (non-major banks).

However, full completion of this transition is dependent on a number of variable factors, including the overall level of compliance by data holders. A period beyond the forecast completion date is desirable to mitigate compliance risk, hence the suggestion of 13 May 2024 as the V3 retirement date.

There it is again, the Regulator oozing with entitlement using compliance risk innuendo to justify why the compliant folk should have to hold water for them supporting retired endpoints for a single consumer (in the "why not retire V3 on the spot" scenario) or to wait for the non-compliant folk (in the "activating V4/V5 in November" scenario) to be reduced to the point the performance dashboard doesn't look farcical.

[NationalAustraliaBank]

NAB welcomes the opportunity to provide the feedback on the urgent Decision Proposal 322. Upon appropriate analysis on changes proposed, NAB welcomes the following changes:

• Change the description for Get Metrics v3 to state that this endpoint version is not required for data holders for whom
• Consumer Data Sharing obligations are scheduled to commence on or after 1 November 2023.
• Set the retirement date for Get Metrics v3 to 13 May 2024 . However, NAB would like to suggest the below:
• Revise the V4 obligation date to 01/03/2024 to accommodate for the complexities involved in the solution.
• Leave the V5 obligation of 13/06/2024

[commbankoss]

CBA welcomes the opportunity to provide feedback on DP322 as follows: The obligation deadline for Bank data holders to support Get Metrics API version 4 should be closely with the date at which the ACCC will be consuming this version of the API. This would enable data holders to prioritise other compliance work accordingly and reduce the need to support both versions in parallel.

[anzbankau]

ANZ agrees with the comments made by @NationalAustraliaBank and @commbankoss regarding changing the obligation date for Get Metrics v4. Aligning this date to when consumption of the data begins makes sense, and the additional time for Data Holders would be helpful.

[CDR-API-Stream]

Thanks all for the feedback. We have confirmed with the ACCC that v4 will be consumed for all Data Holders from 1st November 2023 so aligning the v4 date with usage means that the initial obligation date will remain the same. The ACCC will continue to also call v3 for existing holders to maintain the currency of the existing dashboard.

As a result, the obligation date for v4 and v5 will not be pushed back as requested by some respondents. Feedback requesting that the dates be pushed back was addressed in DP 288 and a trade off was established in the consultation.

Based on a review of the feedback the recommendation outlined in the decision proposal, which already incorporated feedback from @cuctran-greatsouthernbank, will be put to the chair.

@perlboy, we have explicitly not considered your feedback in this consultation. The needlessly aggressive tone used indicated that the feedback was emotionally driven and therefore not objective in nature. If you would like your feedback to be considered in the future please remove the unnecessary commentary on the motives and capabilities of the regulatory teams supporting the CDR.

[CDR-API-Stream]

The Data Standards Chair has approved the attached decision as a result of this consultation: Decision 322 - Update Get Metrics Endpoint Schedule.pdf

This will be published in v1.26.0 of the standards in the next few days.

[CDR-API-Stream]

This is now published in v1.26.0 of the standards