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. Actions
3. CDR Stream updates
4. Presentation
5. Q&A
6. Any other business

• 5 min will be allowed 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.

Type	Topic	Update
Standards	Version 1.22.0 published 23rd of December 2022	Version 1.22.0 Change Log Release video 1.22.0
Maintenance	Iteration 14 Working Group agenda and minutes for 8th of March 2023 published	Check out the agenda here
Maintenance	Iteration Candidates are in consultation	Check out the Project Board See "Iteration Candidates" column for the list
TSY Newsletter	To subscribe to TSY Newsletter	Link here
DSB Newsletter	To subscribe to DSB Newsletter	Link here
TSY Newsletter	13th of February 2023	View in browser here
DSB Newsletter	3rd of March 2023	View in browser here
Consultation	Decision Proposal 229 - CDR Participant Representation	Placeholder: no close date Link to consultation
Consultation	Decision Proposal 267- CX Standards Telco Data Language	Feedback extended with an end date to be determined pending the making of the telco rules. Link to consultation
Consultation	Decision Proposal 275 - Holistic Feedback on Telco Standards	No Close Date Link to consultation
Consultation	Noting Paper 276 - Proposed v5 Rules & Standards Impacts	No Close Date Link to consultation
Consultation	Noting Paper 279 - Accessibility Improvement Plan	No Close Date Link to consultation
Consultation	Decision Proposal 288 - Non-Functional Requirements Revision	Feedback 31st of March 2023 Link to consultation
Consultation	Noting Paper 292 - Approach to developing Data Standards for the Non-Bank Lending Sector	Feedback 24th of March 2023 Link to consultation
Survey	CDR Implementation Call over April 2023 There are a number of public holidays in the month. We would like to know if the Community would like to cancel some of the Calls during April 2023	Vote on your preferred option
Maintenance Backlog Summary	Consolidated view of current Banking change requests and potential future scope	View Issue 580
Guidance	CDR metrics and reporting by Data Holders	CDR Support Portal - CDS Guide
Tooling	Product Comparator Update Resolved & Released Product Comparator GH#226	Product Comparator Demo

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

Organisation	Stream	Member
ACCC	CDR Register	Eva
ACCC	CTS	Andrea
DSB	CX Standards	Michael
DSB	Technical Standards - Banking & Infosec	Mark
DSB	Technical Standards - Energy	Hemang
DSB	Technical Standards - Telco	Brian
DSB	Engineering	Sumaya
DSB	Technical Standards - Register	James

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
1876	Link: https://cdr-support.zendesk.com/hc/en-us/community/posts/6326320757647-CDR-Australia-Common-API-Get-Status-API-Query- The unauthenticated API in Common APIs called Get Status ( https://consumerdatastandardsaustralia.github.io/standards/#get-status ) mentions "Obtain a health check status for the implementation" , Few queries here: What do we mean by implementation ? Does it mean we need to in real time we have to check the health of every CDR API (is it available or not based on "200" OK response) or just give information of the fact that if all the APIs (lets say Telco APIs) are implemented and available for consumption ? Also is detectionTime and expectedResolutionTime mandatory in ResponseCommonDiscoveryStatus ( https://consumerdatastandardsaustralia.github.io/standards/?examples#tocSresponsecommondiscoverystatus) if there is PARTIAL_FAILURE or UNAVAILABLE	Question 1. The Get Status endpoint mentions "Obtain a health check status for the implementation". What do we mean by implementation ? Does it mean we need to in real time we have to check the health of every CDR API (is it available or not based on "200" OK response) or just give information of the fact that if all the APIs (lets say Telco APIs) are implemented and available for consumption ? Answer 1. The Status endpoint is intended to provide detail about whether all endpoints are actually currently functioning, not whether they have been implemented. The schema for the endpoint provides a bit more detail about the possible responses - OK (implementation is fully functional). PARTIAL_FAILURE (one or more end points are unexpectedly unavailable). UNAVAILABLE (the full implementation is unexpectedly unavailable). SCHEDULED_OUTAGE (an advertised outage is in effect) You may also find more information in this article helpful - Definition of 'status' and how health check status can be determined? Question 2. In the Get Staus endpoint, is detectionTime and expectedResolutionTime mandatory in ResponseCommonDiscoveryStatus if there is PARTIAL_FAILURE or UNAVAILABLE Answer 2. The description for detectionTime states that it 'should' only be present when the status property is PARTIAL_FAILURE or UNAVAILABLE. This implies that the value is not a 'must' or 'mandatory', but it should be present where possible. The description for expectedResolutionTime states 'The date and time that full service is expected to resume (if known)'. That would imply the value remains technically optional for the PARTIAL_FAILURE or UNAVAILABLE status, as it's only expected if known. If a resolution time is known, it could be helpful to clients of the affected endpoints, because they may be able to inform consumers, and then throttle or suspend their requests during a period of interruption and recommence making requests later. You may also find more information in this article helpful - Get Status Payload Fields.
1877	Link: https://cdr-support.zendesk.com/hc/en-us/community/posts/6449312829839-CDR-Australia-Common-API-Get-Metrics-API-Query The previousDays is described to fetch only maximum 7 entries and preiousMonths is described to fetch only maximum 12 entries if available, if that is the case how does HISTORIC and ALL period be applicable ?	The Get Metrics endpoint supports multiple metrics with different timescales: The 'availability' data for example, is required to be reported at a monthly level, and fields are provided for the 'currentMonth' and up to a maximum of twelve 'previousMonths'. The 'invocations' data for example is required at a daily level, and fields are provided for the 'currentDay' and up to a maximum of seven 'previousDays'. As per the description of the 'period' parameter of the Get Metrics endpoint: The period of metrics to be requested. Values can be CURRENT (meaning metrics for current day), HISTORIC (meaning metrics for previous days or months) or ALL. If absent the default is ALL. That means the endpoint may be queried to return only the CURRENT values (currentDay, currentMonth), only the HISTORIC values (previousDays, previousMonths), or ALL (both types) The ACCC is able to form a longer historical view of these metrics by calling the endpoint every day. The collection process is defined further in some of the following articles which you may find helpful: How often does the CDR Register poll GET Metrics? CDR Register Metrics Collection Metrics reporting current day Clarification of timezones for time-based data fields
1861	The Secondary Users in the banking sector Fact Sheet states that in the event a Secondary User has either: a) Had their secondary user instruction withdrawn by the account holder OR b) Loses their account privilege for a particular account they are Secondary User for AND they continue to satisfy the CDR eligibility requirements, the person’s authorisations will not expire, and the Data Holder can no longer share data from the account on behalf of the former Secondary User. During the period that the authorisations are active and unexpired, but data sharing has ceased - Can a former Secondary User have the ability to withdraw an authorisation (consent containing an account they formerly held a Secondary user instruction/account privilege) the via the consumer dashboard in its entirety? If not - can it be withdrawn at all? by who? Or must it remain in an unexpired "floating" state for the explicit purpose of recommencing sharing in the event the Secondary User instruction/account privilege is reinstated? In addition to the question above I wanted to provide a specific scenario. Secondary User creates an authorisation containing a singular account they have a secondary user instruction for. The Secondary user chooses to share account and transaction details of the secondary user account and they also choose to share customer data (customer data shared is that of the secondary user, not the account holder). Secondary User loses account privileges, but secondary user instruction had not been withdrawn, and they remain CDR eligible in relation to the data holder Consent remains active, unexpired. Data holder must cease sharing data from the account on behalf of the former secondary user. In consideration for the fact that the former secondary user has chosen to share their customer data and the authorisation is unexpired – this customer data may continue to be disclosed to the ADR if the ADR requests the data. Should the former Secondary User have the ability to withdraw the authorisation considering the data shared at that point in time is their own?	The outcome to the authorisations in relation to your question will depend on whether the person remains eligible in relation to the data holder. If the secondary user instruction is withdrawn or expires and the secondary user does not have another open account with the data holder, they would cease to be eligible in relation to the data holder and any authorisations would expire. This means they would not be re-established if the secondary user regained their account privileges or another secondary user instruction was made for them. If the former secondary user of the account continued to satisfy the eligibility requirements (for example, the person holds another account or is a secondary user of another account with the data holder that is accessible online), the person’s authorisations will not expire. However, the data holder can no longer share data from the particular account on behalf of the former secondary user. Sharing from other accounts under the same authorisation can continue. In this case, we expect the person would continue to have access to a consumer dashboard and would be able to withdraw the applicable authorisation. In relation to your scenario, the scenario would only arise if the person remained eligible, which implies that they hold another account or are a secondary user of another account with the data holder that is accessible online. This would mean, they would have access to their consumer dashboard and would be able to withdraw the applicable authorisation if they no longer wished to share their customer data.
1871	This question relates to the secondary user factsheet https://www.cdr.gov.au/sites/default/files/2022-12/Secondary-users-in-the-banking%20sector-fact-sheet-published-20-December-2022.pdf Section 2.4. Authorising disclosures from multiple accounts “If a person is an account holder of one account and a secondary user of another, they can make a single authorisation allowing for a disclosure from both accounts.“ Our online banking system is setup so that users have multiple profiles. For example Profile A – user has own accounts Profile B – user is a secondary user to Individual A, B, C Profile C – user is a secondary user on a joint account D, E, F The user would need to switch between these 3 profiles to authorise data sharing on the accounts owned on each of these entities. We would like to understand whether the above guidance is mandatory, seeing that they are not implicit in the CDR rules.	The CX Standard Authorisation: Profile selection provides that data holders may, but are not obligated to, add a ‘profile selection’ step or equivalent prior to the account selection step if a single identifier provides access to different customer accounts. In the scenario you describe, this could allow the CDR consumer to select from Profile A, Profile B or Profile C prior to authorising data sharing from one or more accounts under the selected profile. While it is not mandatory to allow a single authorisation for disclosures from multiple accounts, data holders should consider whether adding any additional steps would impose any additional or unwarranted friction for the consumer to authorise data sharing, as rule 4.24(a) prohibits data holders from adding any requirements to the authorisation process beyond those specified in the data standards and the CDR rules. We hope this information assists you. If you have any further questions, please feel free to get in touch again.

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