Regarding Energy Industry, we've recently been made aware of changes that AEMO have planned to make. Our reading of this is that there is no impact to the CDR. Specifically, some of their endpoints scheduled changes. Is this view shared amongst this group?

• Get Products v5
• Get Product Detail v7

• Get Products v4
• Get Product Detail v6
• Get Account Detail v4

• Change log
• Future Dated Obligations

• [email protected]

• Provider selection for white labeled brands
• change log

• 20 February 2026 Newsletter
• Subscribe

• NBL wishes to use merchant information (which is not customer specific) to categorise the transaction
• To identify the merchant the merchantName and merchantCategoryCode are passed to an Large Language Models (LLM) to make a recommendation on the likely type of transaction that would be made with that merchant
• The LLM can make can initiate a web search to find information on that merchant to assist in the recommendation

• Set jti to be 'modifiable'
• jti (may already be assumed to be modifiable to support update requests)
• Separate DCR request body schema with normative fields

• Dashboard Standards
• Specifying an existing arrangement (extract below)

  If a Data Recipient Software Product provides the cdr_arrangement_id claim in the request object to the Data Holder's PAR endpoint, the Data Holder MUST revoke any existing tokens related to the arrangement once the new consent is successfully established and a new set of tokens has been provided to the Data Recipient Software Product.

• Revocations initiated by the consumer would normally require the DH to notify the ADR of the revoked arrangement ID. As the amended authorisation would be given the same arrangement ID as the original authorisation, a typical manual revocation notification to the ADR would cause them to revoke amended consent in the scenario you described.
• As an amendment is not expected to involve manual revocation, your scenario may also impact Metrics reporting, in particular -
  • revokedAuthorisationCount: The number of revoked authorisations.
• Most importantly and directly related to the scenario you propose, the rules state:

  4.24 Restrictions when asking CDR consumer to authorise disclosure of CDR data
  When asking a CDR consumer to authorise the disclosure of CDR data or to amend a current authorisation, the data holder must not do any of the following:
  (a) add any requirements to the authorisation process beyond those specified in the data standards and these rules;
  (b) provide or request additional information during the authorisation process beyond that specified in the data standards and these rules;
  (c) offer additional or alternative services as part of the authorisation process;
  (d) include or refer to other documents.
  

1. Get Software Product Statuses (V3)
2. Get Data Recipients Statuses (V3)
3. Get Data Recipients (V4)

• MSUG - Market Systems User Group (Every 6 weeks)
• Implementation Forum (Held Monthly NEM Reform Changes)
• ITF - Industry Testing Forum WEM (Targeted dates as communications come available)
• ITDF - IT Development Forum (Gas Markets Monthly)
• AEMO Support Hub Bulletins closer to Go-Live dates
  
  

1. When there's a campaign, they'll do a duplicate product just for that campaign. And they'll put an effective date, start date and end date and give it a new name, etc. So it'll appear in the PRD for a period of time with effective date and start date related to the campaign with eligibility criteria indicating eligibility and how you can apply for it under the campaign.
2. Keep the product that is the subject of the campaign and just republish it with a new discounted rate with the appropriate additional info associated with it. And then when the campaign is over, they'll republish again and remove it. So effectively, as the campaign becomes available and then ceases to be available, the core product gets updated.