ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes | 18th of January 2024

CDR Implementation Call Banner

Agenda & Meeting Notes

When: Weekly every Thursday at 3pm-4:30pm AEDT
Location: Microsoft Teams
Meeting Details: Join on your computer, mobile app or room device Click here to join the meeting
Meeting ID: 446 019 435 001
Passcode: BU6uFg
Download Teams | Join on the web
Join with a video conferencing device
[email protected]
Video Conference ID: 133 133 341 4
Alternate VTC instructions Or call in (audio only)
+61 2 9161 1229,,715805177# Australia, Sydney Phone Conference ID: 715 805 177# Find a local number | Reset PIN
Learn More | Meeting options

Agenda

Introductions
Updates
CDR Stream updates
Presentation
Q&A
Any other business

Introductions

5 min will be allowed for participants to join the call.

Acknowledgement of Country

We acknowledge the Traditional Custodians of the various lands on which we work today and the Aboriginal and Torres Strait Islander people participating in this call.

We pay our respects to Elders past, present and emerging, and recognise and celebrate the diversity of Aboriginal peoples and their ongoing cultures and connections to the lands and waters of Australia.

House Keeping

Recording

The Consumer Data Right Implementation Calls are recorded for note taking purposes. All recordings are kept securely, as are the transcripts which may be made from them. No identifying material shall be provided without the participant's consent. Participants may [email protected] should they have any further questions or wish to have any material redacted from the record.

Community Guidelines

By participating in the Consumer Data Right Implementation Call you agree to the Community Guidelines. These guidelines intend to provide a safe and constructive space for members to discuss implementation topics with other participants and members of the ACCC and Data Standards Body.

Updates

⭐ indicates change from last week.

Type	Topic	Update
Standards ⭐	Version 1.29.0	Published: 21st December 2023 Change log
Maintenance ⭐	Maintenance Iteration 18 commences 7th February 2024	Invitations to come
DSB Newsletter	To subscribe to DSB Newsletter	Link here
DSB Newsletter ⭐	12th of January 2024	View in browser here
Consultation	Decision Proposal 229 - CDR Participant Representation	Placeholder: no close date Link to consultation
Consultation	Noting Paper 279 - Accessibility Improvement Plan	No Close Date Link to consultation
Consultation	Noting Paper 323 - NFR Workshops	Link to consultation
Engineering ⭐	Type Definitions Library: The GitHub Repo has been updated to align to CDS version (1.28.0).	The relevant NPM package (v7.1.4) has been released in the NPM registry.

CDR Stream Updates

Provides a weekly update on the activities of each CDR stream and their work.

Organisation	Stream	Member
ACCC	Register and Accreditation Application Platform	Eva
ACCC	Conformance Test Suite & Participant Tooling	Christian
DSB	Consumer Experience	Michael
DSB	Energy	Hemang
DSB	Register	James

Presentation

None this week.

Q&A

Questions on Notice

Questions will be received by the community via Microsoft Teams chat before the questions are opened to the floor. Participants can submit questions outside of the CDR Implementation Call to the CDR Support Portal.

In regards to topics for questions, we ask the participants on the call to consider the Community Guidelines when posing questions to the subject matter experts.

Answer provided

Ticket #	Question	Answer
2212	As a follow-up to support request 2053 the Get Energy Account and Get Energy Account Details should include historical plans. Our question now becomes what generally consitutes a plan change from a CDR perspective, such as a rate change, tarrif type change, addition/removal of incentives, etc. Would it be possible to get some guidance to ensure we are reasonably meeting the intent of this API	The general guidance is that what constitutes a plan change is at the discretion of the retailer. Broadly speaking, you could consider any significant change resulting in re-negotiation of a plan, or changes in T&Cs which results in a consumer having to re-accept/sign up to new T&Cs as a plan change. For e.g. if the energy rates for a given plan are defined as variable, change in rates is part of the plan and would not result in as a new plan (similar to a home loan variable rate change). For bit of background, during initial phases of energy consultation we received feedback that representation of energy plans is not as standardised as, say accounts in the banking/finance sector. Some retailers noted that they consider addition/removal of a new NMI to an account a plan change for example. The standards have tried to incorporate this and allow flexibility in representation.
2224	Should the secondary holder metric be reported as the total time it took to collect all the required data from the SDH or the time per call even if it doesn't match 1:1 with the ADR call?	Secondary holder metric should be reported per individual call made to SDH by the DH. For e.g. if an ADR made a single API call (e.g. usage data) which the DH may need to break down to multiple calls to SDH, the SDH performance would be measured and reported for each respective call made to the SDH, not the sum of the multiple calls.
2227	We are reviewing the CX guidelines for DP#334 with FDO date of 01-July-2024 and have a query. - The CX shows a section on “Consent History” (refer highlighted section in the UI screenshot below) on data holder dashboard. - The requirement table on CX guideline page, shows it as ‘MAY’ (refer second screenshot of the requirements table). - The github page / CDS v1.29.0 mentions- “When a consumer amends an authorisation in accordance with rule 4.22A, which is linked to a cdr_arrangement_id supplied by the data recipient as per the amending authorisation standards, data holders MUST display the details of each authorisation’s amendment on the consumer’s dashboard.” We update the consent dashboard with relevant details (e.g. revised duration, accounts, expiry date) whenever a customer amends an authorisation. However, considering the above guidelines we wanted to check if it’s ‘mandatory’ to provide a history of consent amendment on the data holder dashboard.	Thanks for pointing this out - we're aware of the discrepancy and are yet to update the CX Guidelines to match. The rules and standards take precedence, meaning it is mandatory to display details of each authorisation's amendment from 1 July 2024 as per the rules and standards. The CX Guidelines will be updated soon, but we will look to include an interim note on the page to avoid confusion.
2230	Could you please provide guidance on the procedure for customers and data recipients when faced with missing or erroneous data from a secondary data holder/distributor? Could you confirm the correct process to follow? Are customers and data recipients expected to request data correction through the retailer, or should we directly contact the distributor? We've already made an inquiry with one of the retailers about missing DER data, but they directed us to a generic enquiries email for the distributor.	You can find the data correction procedures related to CDR energy data that is held by AEMO in OAICs Privacy Safeguard 13, specifically safeguard 13.38. It can be found here - https://www.oaic.gov.au/consumer-data-right/consumer-data-right-guidance-for-business/consumer-data-right-privacy-safeguard-guidelines/chapter-13-privacy-safeguard-13-correction-of-cdr-data. As a quick summary, for AEMO held DER data, the retailer is expected to provide information on how the consumer can contact their distributor to have data corrected. For context, DER data is collected and maintained by the customer's local Network Service Provider(NSPs)/distributor, who in turn provide it to AEMO. In other words, the distributors are the source of the DER data and hence the right point for correction.
2232	Do amountstring values require a decimal point to be compliant?	According to the Common Field Types section of the Standards: https://consumerdatastandardsaustralia.github.io/standards/#common-field-types A string representing an amount of currency. - A positive, zero or negative number - Negative numbers identified with a ‘-‘ - Currency symbols MUST NOT be supplied - At least 1 and up to a total of 16 significant digits before decimal point - Minimum 2 digits following a decimal point (more digits allowable but only if required) - No additional formatting, eg thousand separating commas and the associated examples, yes a decimal point is required, with a minimum 2 digits following it. I believe this was intended to make the display of amount strings consistent without requiring additional transformation at the receiving end. If you feel the details in that section warrant an update to provide more clarity, you could raise a CR in Standards Maintenance.
2233	Get Customer API requires ACN to be provided for business accounts if applicable. acn string optional Australian Company Number for the organisation. Required only if an ACN is applicable for the organisation type. As per ASIC, all organizations registered as companies must have an ACN. However, Momentum does not need to ask its business customer for ACN during the acquisition phase or even after the business has become its customer. Hence, we don't hold ACN for majority of our business customers. Kindly advise if this field can be left as Blank/NULL or populated as "UNDEFINED" for such customers in the Get Customer API response to the ADR.	As you noted, the ACN field is optional. As per the definition of optional in the standards, a Data Holder (DH) must supply it only if they hold the value for it. In other words, if the DH do not hold the value for an optional field, in this case the ACN, they are not required to provide it in a response (either omit the field or return a NULL). Note that populating an optional field as "UNDEFINED" is not acceptable and will result in non-compliance with the standards. You can read more about it in this guidance article - Data formats - schemas – Consumer Data Standards Australia (zendesk.com)
2235	I am writing to understand the scope of the requirement bit clearly for the abandonment by stages. While the zendesk article - https://cdr-support.zendesk.com/hc/en-us/articles/8485633822735-Get-Metrics-V5-abandonment-by-stages does a good job to explain what the specific stages and the abandonment scenario are. I am interested in getting further clarification on the additional exception scenarios for each stage like - a) Is network outage or session timeout for each stage in the scope of abandonment? b) Is the user closing the browser due to some reason to be considered as an abandonment? c) Similar user inactivity or non-responsive on each specific stage also needs to be considered as abandonment. If yes, then what are the interpretation /expectations for the activeAuthorisationCount (https://consumerdatastandardsaustralia.github.io/standards/#cdr-admin-api_schemas_tocSauthorisationmetricsv2) The implementation and catering these exceptions in the abandonment scenario impacts complexity and cost. So, it will be great to get the clarification on these exceptions.	For your questions - a) Is network outage or session timeout for each stage in the scope of abandonment? b) Is the user closing the browser due to some reason to be considered as an abandonment? c) Similar user inactivity or non-responsive on each specific stage also needs to be considered as abandonment. The answer is Yes. As demonstrated by the four 'Abandon' boxes in the diagram in that article, If the user didn't reach the next step, they are considered to have abandoned or exited the flow at that point. These may be due to a timeout while the user searches for their customer ID, closing a browser window because they don't want to continue, or simply locking their phone or laptop and not returning to continue the journey. The 'rejected' metric is different to these as it captures the active action of the user to not continue at the final step; for example by pressing 'Cancel' and directly returning to the ADR. The activeAuthorisationCount field is not part of the abandonmentsByStage section. The activeAuthorisationCount is the total number of ongoing (i.e., not 'one-time' or 'once-off') authorisations on record at the time of the Get Metrics request. For details about authorisation sharing duration and one-time or once-off consents, refer to Requesting Sharing Duration. Does this seem to provide the clarity you need, or have I misunderstood your questions?