ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes | 28th of September 2023

CDR Implementation Call Banner

Agenda & Meeting Notes

When: Weekly every Thursday at 3pm-4:30pm AEST
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.26.0	Published: 24th August 2023 Change log
Maintenance ⭐	Maintenance Iteration 17	Commenced on the 20th of September 2023 Next meet on the 4th of October 2023
Maintenance	Maintenance Iteration 17	All agendas and meeting minutes
TSY Newsletter	To subscribe to TSY Newsletter	Link here
DSB Newsletter	To subscribe to DSB Newsletter	Link here
TSY Newsletter	1st September 2023	View in browser here
DSB Newsletter ⭐	22nd September 2023	View in browser here
Consultation	Decision Proposal 229 - CDR Participant Representation	Placeholder: 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	Noting Paper 280: The CX of Authentication Uplift	No Close Date Link to consultation
Consultation	Noting Paper 307 - LCCD Consultation Approach	No Close Date Link to consultation Video
Consultation	Noting Paper 308 - Categories of Standards	No Close Date Link to consultation
Consultation	Decision Proposal 317 - ‘Buy Now, Pay Later’ Product and Account Detail	6 October 2023 Link to consultation
Consultation	Design Paper: Consumer Data Right Consent Review	6 October 2023 Link to consultation
Consultation ⭐	Decision Proposal 276 - July 2023 Rules & Standards Impacts	20th October 2023 Link to consultation
Consultation ⭐	Decision Proposal 327 - Authentication Uplift Phase 1	24th October 2023 Link to consultation
Consultation	Noting Paper 323 - NFR Workshops	Link to consultation
Video ⭐	Maintenance Iteration 16 Video	Data Standards Body YouTube Channel
Engineering ⭐	JSON Schema Tools: The repository has been updated to align with the latest CDS version (1.26.0).	Schema Tools Link

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	Christian
ACCC	Compliance	Seamus
DSB	Consumer Experience	Michael
DSB	Register Standards	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
2102	Our company, is currently participating in the CDR as a representative. We are seeking to understand which retailers are required to share consumer data for non-complex requests on November 1, 2023. We have downloaded a list from the public 'get products' API, and currently, there are 86 retailers listed. However, when we extracted the number of customers for the last year's quarter, we discovered that 28 retailers did not have at least 10,000 customers. This means they would not be required to participate in the CDR according to the CDR rules. Is there a list you can share with us that specifies the retailers who will be participating in CDR data sharing for non-complex requests, or could you please point us in the right direction?	We've recently published a list of Energy Data Holders with Consumer Data Sharing Obligations Commencing 1 November here.
2109	Can a financial counselor call on a customers behalf? Will the financial counselor be able to receive the customers data? For example a financial counselor calling an energy retailer and requesting a customers data on a customers behalf.	The CDR does not contain any specific provisions as to how one person may act on behalf of another person and we recommend that CDR participants obtain independent advice for the varying scenarios and legal arrangements under which this may occur. However, we have developed guidance on powers of attorney which may assist (available here: https://www.cdr.gov.au/guides/powers-attorney-and-consumer-data-right). Relevantly, an attorney acting under a power of attorney on behalf of a CDR consumer may: make a decision, be asked to do a certain thing, or receive a notification or information, where doing so is within the actual or apparent authority of the attorney set out in the power of attorney document. We also note that financial counselling agencies fall within a class of trusted advisers (see rule 1.10C(2)(d)). Therefore accredited data recipients and CDR representatives of CDR data may disclose that data to financial counselling agencies through a TA disclosure consent. For further information, the OAIC has also published guidance on trusted advisors.
2116 - Part 1	GetMetrics v4 has binding date of 01-Nov-2023. What will be the x-v and x-min-v values that ACCC will pass post 01-Nov-2023 or even now. Do data holder need to support v3 version post 01-Nov-2024	In the context of Get Metrics the ACCC will be a normal client of a resource endpoint which means they have the option of calling the endpoint with whatever combination of version headers they desire and this is open to change. In this context I do not beleive the ACCC will be answering this question. To answer your question, however, I can direct you to the obligations stated in the standards at: https://consumerdatastandardsaustralia.github.io/standards/#metadata-update To quote: v3 - Implementation not required for Data Holders going live on, or after, 1st November 2023. Other Data Holders MAY retire this version from the earlier of 13th May 2024 or from the time the ACCC announce that they no longer call this version v4 - This version, or v5, MUST be implemented by November 1st 2023 Also, regarding v5: NOTE: This version MUST be implemented by May 13th 2024 In light of this it should be clear that new Data Holders that are already live before 1st November 2023 need to support both v3 and v4 (or v5 as an alternative) from 1st November 2023. Data Holders obligated to go live on or after 1st November 2023 only need to support v4 (or v5 as an alternative).
2116 - Part 2	Thanks for the response above and to clarify simply, we were planning to deprecate V3 at the same time when we go live with the latest version V4 on 1 November 2023. I.e from 1 Nov 2023 we will be live with GetMetrics V4 and will only respond to the latest version available on our side. This was based on the note that DHs could deprecate V3 earlier than 13 May 2024. Do you see any issues with the approach from a technical perspective? To quote: "v3 - Implementation not required for Data Holders going live on, or after, 1st November 2023. Other Data Holders MAY retire this version from the earlier of 13th May 2024 or from the time the ACCC announce that they no longer call this version". Unquote	The statement - "MAY retire this version from the earlier of 13th May 2024 or from the time the ACCC announce that they no longer call this version" Should be taken as meaning Data Holders may only retire v3 on the 13th May 2024 or when the ACCC announce (through their usual channels) a date from which they will no longer be calling that version. That means that Data Holders that have been live before 1 November 2023 must continue to support both v3 and v4 or v5 until the earlier of either of the dates described in that statement. Also note: v4 may be retired as soon as v5 is available. After 13th May 2024, only v5 is required. The requirement for concurrent versions is to provide the Register time to transition to the new Metrics versions, to ensure continuity of reporting. To achieve this, the Register may call each version separately every day.
2118	Can ACCC advise what will be the x-v and x-min-v values in GetMetrics invocation header while industry transition from v3 to v5. Do DH need to support v3 after they have transitioned to v4?	I don't believe the ACCC will be making this information public as they have the option of changing these headers at will. It should be noted that even if they did publish this information it will not change the obligations of data holders under the standards. I would personally recommend that data holders assume that the following values will be provided and test accordingly: x-v: 6 x-min-v: 1
2119	We are aware of the requirements around the Get Metrics endpoint that's used by the regulator to see real time statistics. However, we have not found any documentation on how the regulator should access this endpoint when it is built, or what the security measures should be, so that only the regulator can have access to it. Can you point me to somewhere that details this information?	In the standards there is a section on client authentication (https://consumerdatastandardsaustralia.github.io/standards/#client-authentication). Please refer to the sub-section in this section name CDR Register calling Data Holders. Also note that there is a blue callout under the Get Metrics endpoint with some clarifying statements.
2120	In an effort to improve our performance to meet the NFR of "95% of calls per hour responded to within a nominated threshold" we need to make the following changes. Can you please confirm if this is acceptable for CDR standards ? 1. For Get Account Details and Get Account APIs, we currently call a 3rd party (FIS) to obtain near real-time data. This causes a lot of lag. To address this, we are considering obtaining batch data from our 3rd party every 6 hours. So instead of providing near real-time data to our customer, the data will be no more than 6 hours old. 2. For Get Balance and Get Transaction APIs, we currently call a 3rd party (FIS) to obtain near real-time data. Again, this causes a lot of lag so we are considering obtaining batch data every 30 minutes. This means the data returned to our customer will be no more than 30 minutes old. The above changes will only affect credit card accounts as they are stored at FIS. Other non-credit card accounts are stored in the bank so we can continue to provide near real-time data to our customers.	The standards are generally silent on how data is obtained and cached inside a data holder's ecosystem. The only specific requirement is in the non-functional requirements section under the Data Latency heading. In summary this states that a data holder should provide data in accordance with the latency of the data they already offer the customer in other channels. If you offer real time transactions in your other digital channels but offer a six hour cache via CDR this would be a breach of this NFR. If you offer a six hour cache via both your own channels and CDR then that would be fine. I would also note that the rules have requirements with regard to providing data that is held once a request is made so you should also ensure that you are comfortable that your design meets the requirements of the rules.