ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes | 18th of April 2024
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
- 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.1 | Published: 28th of February 2024 Change log |
| Standards | Version 1.30.0 is being staged for release | Standards Staging |
| Maintenance ⭐ | Maintenance Iteration 18 complete | MI 18 Agendas |
| Maintenance ⭐ | Iteration 19 commenced | You can sign up here. |
| DSB Newsletter | To subscribe to DSB Newsletter | Link here |
| DSB Newsletter ⭐ | 12th of April 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 |
| Consultation | Noting Paper 345 - Data Standards Body Capability, Consultation Processes and Operating Mode | Link to consultation |
| Events | Data Standards Body new calendar Self manage the Maintenance Iterations, CDR Implementation Calls, Workshops and consultations from here. |
Data Standards Body Calendar |
| Workshop | Standards Assessment Framework Type: Physical Location: Sydney, Australia Date: 6th May 2024 Time: 12PM - 4PM The workshop will discuss a draft Standards Assessment Framework (Framework) as a mechanism the Data Standards Chair will use to formalise and demonstrate decisions on changes to the Consumer Data Standards. The Framework builds on the DSB's and the Data Standards Chair's existing open and transparent consultation and decision making practices. |
Sign up on our event calendar |
| Workshop | Standards Assessment Framework Type: Physical Location: Melbourne, Australia Date: 14th May 2024 Time: 12PM - 4PM The workshop will discuss a draft Standards Assessment Framework (Framework) as a mechanism the Data Standards Chair will use to formalise and demonstrate decisions on changes to the Consumer Data Standards. The Framework builds on the DSB's and the Data Standards Chair's existing open and transparent consultation and decision making practices. |
Sign up on our event calendar |
| Workshop | Decision Proposal 338 Workshop Type: Virtual Date: 21st May 2024 2:00PM - 4:00PM Join the Data Standards Body as they work through the prioritisation and planning of Decision Proposal 338. The workshop will be an online sorting exercise on how best to approach the Get Products, Get Product Detail and Get Account Detail endpoint changes. |
Sign up on our event calendar |
| Engineering | Postman Collections: has been updated to align the artefact to the latest CDS version (1.29.1). | Github Repository |
| Engineering | Mock Data Holder (Node JS): The has been updated to align the artefact to the latest CDS version (1.29.1). | Github Repository |
| ANZAC Day | The CDR Implementation Call for the 25th of April 2024 will be cancelled. | Cancellations sent. |
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 |
| DSB | Energy | Hemang |
| DSB | Tech Update | Mark |
None this week.
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 |
|---|---|---|
| 2326 | The current CDR product definition for Term Deposits does not align with how Term Deposits are represented within our underlying core banking system. WIthin our core banking system, it is possible to have a term deposit product which does not have any ‘active’ term deposits against it. Effectively, we have a term deposit account with $0 balance and no maturity date, lodgement date, maturity amount, currency or instructions. This happens when an existing Term Deposit has matured and been paid out, however our system maintains the Term Deposit, and allows our members to transfer funds into it, which will result in a new Term Deposit arrangement being established. In these scenarios, we are unable to provide any of the mandatory Term Deposit attributes as while the account is a Term Deposit account, there are actually not ‘active’ Term Deposits against that account. We are at a loss as to how to address this as there is a misalignment between the CDR product definition and what how underlying core platform. Can you please advise? |
If the Data Holder doesn't have the details required for the termDeposit structure, they could exclude the optional specificAccountUType field (and associated termDeposit field it relates to), thereby implying that there is no specific structure to present for the account, as explained in this guidance - https://cdr-support.zendesk.com/hc/en-us/articles/4414665094671-Values-for-termDeposit-in-BankingAccountDetailV2-response Another option could be to retain the field but provide an empty array for the termDeposit field to imply there are no deposits currently held in the account. The balance of the account should also reflect that situation. |
| 2330 Part 1 | am reaching out to seek clarification on the EnergyBillingUsageTransactionV2 requirements. Specifically, it requests a datetimestring for both the startDate and endDate, with the intent to capture the exact moments when the usage period begins and concludes. However, our current system does not retain this information in the prescribed format, and for some records, the data is not available at all. To illustrate, the usage period displayed to our customers is presented as a date range, for example, “Billing period 01/01/2024 - 31/01/2024,” without any time component. In the case of smart meters, we could, at most, infer that the period starts at 12:00 on the start date and concludes at 24:00 on the end date. Unfortunately, for basic meters, even this information is not ascertainable and assuming would be incorrect from my view. Given this context, I would like to confirm if you can provide guidance on this. I have provided two options which we have available: - Option 1 (our preferred choice) - Would it be acceptable to provide only the dates without the corresponding times? - Option 2 - If necessary, we could assume the start time to be 12:00 and the end time to be 24:00, aligning with the account’s timezone. But this would mean that the information we provide for basic meters will most definitely be incorrect as we do not store the time. |
Option 1 would be non-compliant and hence not considering. Taking a step back, I'd like to clarify my understanding of the problem. How are time of use rates charged without knowing the time? Especially for interval meters? For basic meters, wouldn't the timeOfUseType be set to ALL_DAY and the time component could to set at your discretion to note 24 hours? |
| 2330 Part 2 | Regarding the billing transactions endpoint query, it appears that regardless of the time of use input, both startDate and endDate are mandatory attributes with the type dateTimeString. However, in the case of basic meters, where the timing of the read is not available in our system, we only have the date available as to which date the read was taken. Screenshot attached. My understanding is that the request here is to provide the start of when the usage has commenced and end of when usage ends. Happy to be corrected here if I have misunderstood this. In such cases, our proposed solution then is to set a default time. For instance, if the start date is 09/04/2024 and the end date is 16/04/2024, we suggest setting the startDate response as 20240409T000000+1000 and the endDate response as 20240417T000000+1000, with the appropriate timezone. This will work for both smart meters and basic meters. Additionally, we understand that this assumption may not precisely reflect the actual reading times, as they are not typically recorded at the beginning and end of the day for basic meters. However, in the absence of exact time information, we propose proceeding with this assumption. |
Your proposed solution seems good. Keeping in mind the intent is to indicate the start and end of the transactions for which the charges apply. The time component is important for time of use based scenarios. For basic reads, if the calculation is only based on dates and time is not factored in, you can assume time to indicate a full day as per your suggestion. |
| 2332 Part 1 | Decision proposal 306 bring a bit of changes to how fees , deposit and lending products are defined. This will require DH to migrate product from v4 to v5 definitions. Once Product v5 API become binding, are data holder expected to support v4 as well for a period or just v5 . | There has not yet been a Decision as to whether, or when DP306/DP338 will be Binding, but typically when changes are made to endpoints, concurrent version support is required to allow ADRs to transition when they are ready. Details of when any new versions will be required and when older versions can be retired will be published when the decisions are final and the Standards are updated. You should expect to see overlaps in items on the Endpoint version schedule, between the 'Binding Date' of a newer version and the 'Retirement Date' of an older version. https://consumerdatastandardsaustralia.github.io/standards/includes/endpoint-version-schedule/#banking-apis |
| 2332 Part 2 | I agree, it would have been straight forward case if API were moving to add on but for products it's a transition. Let me give you an example For an existing product fee v4, DH send two values Name and Fee Type For proposed product fee v5, DH is required to send Name, fee category, fee type and fee method U type Also definition of Fee Type has been extended, more specifically Fee Type 'Variable' no longer exists in v5. DH will have to move Variable fees to new definition. So for a DH they will have to maintain two sets of definition one for v4 and one for v5. Lot of DH maintain their products via front end dashboard and it will be tricky for a DH to maintain two version of same products |
How a Data Holder meets these requirements (if necessary) is an implementation consideration they will have to make. There may be ways to simplify the management and delivery as you've stated, by maintaining them separately, having a type of mapping between them, or some other solution. If you're interested in the next steps for DP338, there will be a workshop next month to develop an approach to move forward: Workshop Sign up |
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.
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
|
 |
 |
 |