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

---

1. Introductions
2. House Keeping
3. Updates
4. CDR Stream updates
5. Presentation
6. Q&A
7. Any other business

• 5 min will be al lowed for participants to join the call.

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.

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.

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.

⭐ indicates change from last week.

Type	Topic	Update
Standards	Version 1.29.0	Published: 21st December 2023 Change log
Maintenance	Maintenance Iteration 18 commenced on the 7th February 2024	Agenda Please reach out to [email protected] for an invitation
DSB Newsletter	To subscribe to DSB Newsletter	Link here
DSB Newsletter ⭐	9th of February 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
Consultation	Noting Paper 330 - UNSW Reports	Link to consultation
Consultation	Decision Proposal 340 - Maintenance Iteration 18	Link to consultation
Consultation	Noting Paper 342 - Information Security Working Group	Link to consultation
Survey	If you are a CDR stakeholder, we want to hear about your experience finding and using CDR guidance. The ACCC has released a survey for businesses and individuals who are holder or receivers of CDR data, or who provide services to these parties. This includes, for example, data holders, accredited persons, CDR representatives and third-party service providers. Your response will help us assess the effectiveness of CDR guidance and identify potential areas for improvement.	The survey is available on the ACCC website and will remain open until 25 March 2024.
Engineering	Update to Product Comparator Demo Improved CORS error logging. Where it checks that the x-v header of the response can be read by a cross-origin web client.	Product Comparator Demo

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

Organisation	Stream	Member
ACCC	Register and Accreditation Application Platform, Conformance Test Suite & Participant Tooling	Christian
DSB	Consumer Experience	Michael
AEMO	Status and Outage APIs	John

None this week.

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.

Ticket #	Question	Answer
2224	Just to clarify further as this guidance article doesn't explicitly outline it, for calls passed through to the secondary data holder, is the calculation method for the response time EXCLUDING the secondary data holder response times? For instance if a call comes into Get Usage, requires 2 secondary data holder calls each taking 1 second and the total time end to end for the call is 2.5 seconds is the calculated response times as follows: AverageResponseMetricsV2 .primary: 2.5 seconds total - (2 x 1 second per SDH call) = 0.5 seconds? AverageResponseMetricsV2 .secondary: 2 x 1 second = 1 second ?	It’s not clear what you mean by excluding secondary data holder (SDH) times. If you mean that the primary data holder (PDH) average response times should exclude SDH times, then that is correct. An example formula would be like below: Average Response Time = response time taken by DH (if PDH, excludes SDH and vice versa) / number of API calls Using that in your example we get the following: - AverageResponseMetricsV2.secondary.primary = 0.5 / 1 = 0.5 - AverageResponseMetricsV2.secondary.secondary = 2 / 2 = 1
2246	Scenario: Consider ADR2 has received collection and use consent request from ADR1. Now here ADR2 decides to obtain a disclosure consent from the consumer in order to disclose the required CDR data to ADR1. As per the rule 4.11(ba) (rule - in the case of a disclosure consent―allow the CDR consumer to select the person to whom the CDR data may be disclosed), if our ADR2 provides the option to select the ADR to disclose CDR data and user here selects ADR3 then it will not fulfil the collection and use consent i.e. ADR2 will not be able to share data to ADR1. Could you describe/guide, what is the purpose of this rule in this scenario?	As you may be aware, the purpose of Division 4.3, as outlined in rule 4.9, is to ensure CDR consents are voluntary, express, informed, specific as to purpose, time limited, and easily withdrawn. Rule 4.11(1)(ba) is one of many provisions in Division 4.3 that is designed to facilitate these purposes by requiring the CDR consumer to actively select the person to whom they want to disclose data.
2247	Can an ADR give AP disclosure consent without collection and use consent?	Rule 4.7B lists the requirements that must be satisfied before an ADR may ask an eligible CDR consumer for an AP disclosure consent. One of the requirements is that an ADR must have received, or reasonably anticipates receiving, a relevant consumer data request under rule 4.7A before it can request a CDR consumer to give an AP disclosure consent. Rule 4.7A provides that an accredited person can only request (on behalf of a CDR consumer) that the ADR disclose data in relation to which the consumer has given a valid request under rule 4.3 or 4.3A and can only disclose “some or all of the CDR data that is the subject of the relevant collection consent and use consent”. The ACCC’s view is that an ADR cannot request an AP disclosure consent from a CDR consumer in the absence of a relevant collection and use consent because in these circumstances there would be no reasonable expectation of receiving a request under rule 4.7A. Furthermore, we note that rule 7.5(1)(i) states that disclosing CDR data to an accredited person is only a permitted use or disclosure for an ADR that has collected CDR data under a consumer data request, if the CDR consumer has given: the accredited person a relevant collection and use consent; and the ADR an AP disclosure consent to disclose the CDR data to the accredited person. Hence, the disclosure of data in response to an AP disclosure consent is not a permitted use or disclosure of CDR data if the CDR consumer has not given a relevant collection and use consent.
2265	Last year Energy Data Holder performance metrics were published alongside Banking (see https://www.cdr.gov.au/performance). This triggered a number of internal discussions as to interpretation of GetMetrics and how they align to Non-functional Requirements (NFRs). See attached JPEG for screenshot and context. Chief call out here is that the hover over from the published metrics which shows an applicable Threshold of 1 second for 'Secondary Response - Primary DH'. Question a) Can you please confirm this threshold is referencing the NFR's in the CDS, specifically: Secondary Request 1000ms (for data holders) 1500ms (for secondary data holders) If the above is true, it appears we have a misalignment of interpretation in the metrics as the published figures appear to assume that the reported response times in GetMetrics captures the time for the Primary DH only (1000ms), and not the entire round trip for the response ie. Primary DH + Secondary DH and back again, or 2500ms. Question b) Can you please confirm that the expectation for Get Metrics and therefore the published figures in CDR Performance for 'Secondary Response - Primary DH', expects only to show the time taken for a Primary Data Holder to pass the request to the Secondary Data Holder; OR Is the expectation that GetMetrics data reports the entire round trip for a given response ie. Primary DH to Secondary DH, and Secondary back to Primary? If the latter is the case the hover over on the Performance website seems to be incorrect given the threshold would be 2.5 secs, not 1 sec. If the former is correct then there is some ambiguity in the GetMetrics requirements as this is not declared specifically. I believe we are currently reporting the aggregate times, ie the Primary and Secondary DH response times together.	Question a) Can you please confirm this threshold is referencing the NFR's in the CDS, specifically: Secondary Request 1000ms (for data holders) 1500ms (for secondary data holders) Yes that is correct. The performance requirements in the NFR are noted for each data holder (Primary and Secondary) individually. Question b) Can you please confirm that the expectation for Get Metrics and therefore the published figures in CDR Performance for 'Secondary Response - Primary DH', expects only to show the time taken for a Primary Data Holder to pass the request to the Secondary Data Holder; OR Is the expectation that GetMetrics data reports the entire round trip for a given response ie. Primary DH to Secondary DH, and Secondary back to Primary? GetMetrics is aligned to the NFRs and reports the Primary Data Holder (PDH) and Secondary Data Holder (SDH) performance requirements individually. The primary data holder (PDH) average response times should exclude SDH times and vice versa. - An example formula on how it would be calculated is below: Average Response Time = response time taken by DH (if PDH, excludes SDH and vice versa) / number of API calls received by the DH. Hope this clarifies. We will update our guidance article on CDR Metrics to include the above clarification.

Attendees are invited to raise topics related to the Consumer Data Right that would benefit from the DSB and ACCCs' consideration.

View a number of informative and useful links in the Consumer Data Standards Guide on Information Links.