ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes | 14 November 2024
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
- 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 and present, 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 | Updated | Links |
|---|---|---|
| Standards | Version 1.32.0 | Published: 21st of October 2024 Change log |
| Maintenance ⭐ | Iteration 21 Schedule: |
MI 21 complete for 2024! Thank you everyone who contributed to these forums |
| Maintenance ⭐ | Iteration 21 Complete! Notes from the meet will be published soon |
MI 21 Board |
| Maintenance | Iteration 22 - to be confirmed | Aiming for February 2025 |
| DSB Newsletter | To subscribe to DSB Newsletter | Link here |
| DSB Newsletter ⭐ | 8 November 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 355 - Deceptive Patterns Independent Health Check | No feedback sought Link to Noting Paper |
| Consultation | Noting Paper 357 - LCCD Benefit Workshop Summary | No feedback sought Link to Noting Paper |
| Consultation | Noting Paper 359 - Deceptive Patterns Health Check - Next Steps | No feedback sought Link to Noting Paper |
| End of Year | Calls remaining in 2024: - - 21 November 2024 - 28 November 2024 - 5 December 2024 |
Return on 16 January 2025 |
| Video ⭐ | Noting Paper 359 - narrated by Neale Morison (13/11/2024) | NP359 Video - DSB YouTube Channel |
| News ⭐ | 12 November 2024 Consumer Data Right rule changes to drive consumer take up |
Media Link Amendment Package |
Provides a weekly update on the activities of each CDR stream and their work.
| Organisation | Stream | Member |
|---|
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 |
|---|---|---|
| 2442 Part 1 | I was looking at the candidate standards for non-bank lending - specifically at the Get Account Detail API. I had two questions for the Get Account Detail API: 1. Under instalments (BankingAccountInstalments) there is a field called "maximumPlanCount" and I am having trouble understanding how this field would be best populated. To provide an example if I have a BNPL product which allows me to pay in 6 instalments and the total limit of my account is $1,000 and the minimum purchase amount is can make using this product is $0.06. So would this mean that my maximumPlanCount would be $1,000 / $0.06 = 16,667 ? Trying to understand because the maximumPlanCount would be dependent on the limit of the spending account and how much the minimum spend value is. 2. What is the best guidance on populating the plans array? using the example of the product above - technically I could buy many small products with my $1000 limit. this would result in potentially thousands of "plans" created and even more arrays in the "schedule" which is part of the "plans" array. Trying to understand what the best way would be to represent this information as there is no way to paginate through "plans" or "schedule". I have included a link to the candidate standards and the exact page I am talking about. https://consumerdatastandardsaustralia.github.io/standards/includes/additional/candidates/non-bank-lending/banking-non-bank-lending.html?examples#cdr-banking-api_schemas_tocSbankingaccountdetailv4 |
1. The maximumPlanCount field is intended to capture the maximum number of plans a consumer can create concurrently on the account. It's not intended be be calculated from the account limit and minimum plan value. For example, if a product had an instalment plan feature that allowed up to 3 concurrent plans at a time, the value would be 3. Some accounts may allow a maximum of one plan until it is paid off in full, before a new plan can be started. In that case, the value would be 1. If an account can have an unlimited number of plans, the value could be set to a high number such as 99999 2. The plans array is expected to include one array item for each active plan on the account. Continuing the example above, if the consumer had two active plans out of a maximum of three, the array would have the two plans detailed. The schedule for each plan is expected to have one array element for each scheduled repayment against the associated plan. |
| 2442 Part 2 | A few follow up questions on point 2 - just to confirm we would only need to provide plans in the array which are active( as in the consumer is in the process of making payments or needs to make payments)? There would be no requirement to provide information on plans which have been completed (payment has been repaid in full for all instalments)? - Similar question for the schedule array – is it expected to provide information on all instalments on under the plan (regardless if they are paid or upcoming) or only information on upcoming payments? |
Q: we would only need to provide plans in the array which are active( as in the consumer is in the process of making payments or needs to make payments)? There would be no requirement to provide information on plans which have been completed (payment has been repaid in full for all instalments)? A: Correct. Details related to completed plans would be available in the transaction history of the account. Q: for the schedule array – is it expected to provide information on all instalments on under the plan (regardless if they are paid or upcoming) or only information on upcoming payments? A: Only scheduled or upcoming payments. Details related to completed payments would be available in the transaction history of the account. |
| 2443 Part 1 | I am attempting to retrieve energy plan details for all energy retailers via the unauthenticated endpoints. I can successfully retrieve the discovery/status for some of them, however I have not been able to get the energy plan data for any energy data holders. Do you have a working example that I can follow from for any of the retailers? It is very confusing as to what I might be doing incorrectly. | Our Product Comparator Demo may be a great place to start: https://consumerdatastandardsaustralia.github.io/product-comparator-demo/ You can select Energy only retailers to see the data they return. In addition, check out the Australian Energy Regulators site on the Product Reference data for the Energy sector: https://www.aer.gov.au/energy-product-reference-data they have a data list and documentation. |
| 2443 Part 2 | After having a look through that, I have a couple of follow on questions: For some energy data providers (e.g. AGL), the publicBaseUri points to one URI, but the queries that actually return plans data in the product comparator demo go somewhere else. E.g. for AGL, the publicBaseUri is https://public.cdr.agl.com.au/ But the data for the plans comes from https://cdr.energymadeeasy.gov.au/agl/cds-au/v1/energy/plans?effective=CURRENT&fuelType=ELECTRICITY Is there something that I am missing? As I don’t know how I would programmatically find out that I should be querying energymadeeasy.gov.au rather than the URI that they have provided. For others (e.g. ActewAGL, Diamond Energy, Dodo), there doesn’t seem to be any data available. E.g. https://public.cdr.actewagl.com.au/cds-au/v1/energy/plans?effective=CURRENT&fuelType=ELECTRICITY returns a 404 not found, even though their discovery status page returns OK. Is there any way to submit error reports for providers that don’t appear to be offering the required data? |
This is due to a known issue in the energy sector. As a high level summary, the problem arises because the designated data holder for energy plans is Australian Energy Regulator (AER). The publicBaseURI in register is used for data holders (i.e. retailers) status and outages endpoints along with PRD endpoints which is causing the issue. As a tactical solution, AER have published a list of energy PRD URIs which is available here - https://www.aer.gov.au/documents/consumer-data-right-energy-retailer-base-uris-and-cdr-brands. There is more helpful information here - https://www.aer.gov.au/energy-product-reference-data. I've looped in ACCC Regulatory Guidance for visibility of your concern as we hope to resolve the main issue soon so that you can acess the PRD info via the register without having to manually read a pdf file. |
| 2447 | Should a Data Holder with no active product still have an PRD endpoint or can they return an error We have a Banking Data holder that only have grandfarthered products so they are returning a 404 error in the PRD, a data recipient believes that even if they have no active product, returning a 404 error is not a valid error and they should return a empty list of products like: { "data":{ "products":[ ] }, "links":{ "self":"<public_base_uri>/cds-au/v1/banking/products", "first":null, "prev":null, "next":null, "last":null }, "meta":{ "totalRecords":0, "totalPages":0 } } Should a dataholder with no active product still be providing their PRD endpoint and return an empty list like what the data recipient had suggested or is it okay for them to return an error code? |
I think this query may require a view from the Rules Compliance team. The Rules state that a data holder must provide a product data request service meeting certain criteria - When there are no publicly available products to be shared, providing an empty array would conform with the data standards. P.S. null values do not need to be specified for fields that are not applicable. |
| 2449 | Currently, we have a series of grandfathered white labelled products under a brand that is no longer offered to market. For this white-label, all products have been grandfathered and so no Product Reference Data service has been applied as there is no requirement to provide PRD for these products as per: https://cdr-support.zendesk.com/hc/en-au/articles/360004255656-Grandfathered-products What is the expectation for error coding when there is no underlying obligation to provide Product Reference Data for a brand in its entirety? Is it expected to build out the correct error handling when there is no underlying obligation to provide the service? |
Perhaps depending on the Brand, providing a Product data request service is an obligation of the Rules -See Subdivision 1.4.2 Services for making requests under these rules -> 1.12 Product data request service. If the brand appears to be ACTIVE, I would think the service is required and must conform with the standards. The article you've referred to mentions that grandfathered products, or those that are not publicly available, do not need to appear in PRD, but that does not imply that the service in general is not required. Where the service is required, an empty array conforming to the standards could convey that there are no products currently available. |
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.
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |