ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes | 18th of July 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 | Updated | Links |
|---|---|---|
| Standards ⭐ | Version 1.31.0 | Published: 3rd of July 2024 Change log |
| Maintenance ⭐ | Iteration 20 Commenced 10th of July 2024 |
Sign-up and Register Data Standards Body Events |
| Maintenance ⭐ | Iteration 20 Schedule: 24/07/2024 Consultation 7/08/2024 Consultation and new issue checkpoint 21/08/2024 Proposal Checkpoint 4/09/2024 Approvals and Documentation |
MI20 Agendas and Minutes |
| DSB Newsletter | To subscribe to DSB Newsletter | Link here |
| DSB Newsletter ⭐ | 12th of July 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 351 - LCCD Risk workshop summary | No feedback sought Link to Noting Paper |
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 |
|---|---|---|
| 2091 | The endpoints listed at https://api.cdr.gov.au/cdr-register/v1/energy/data-holders/brands/summary are out of date for several organisations. | The issue stems from the way that product reference data (PRD) is designated for energy as compared to the banking sector. Energy retailers are not designated holders of PRD; the Australian Energy Regulator (AER) and the Victorian Department of Energy, Environment and Climate Action (Victorian agency) are. This is to leverage regulatory arrangements in the energy sector outside of the CDR, where energy retailers provide data about their energy plans to the AER and Victorian agency for the purposes of the energy price comparator websites Energy Made Easy (EME) and Victorian Energy Compare. Practically, the AER publishes on its website endpoints to access the PRD that both it and the Victorian agency hold, along with instructions for accessing energy PRD. However, the base URIs of retailers cannot be used to find PRD. This is because of a known limitation for the base URI's available via the Register. Specifically, a data holder (DH) can only have one public base URI. The public base URI is used for the PRD endpoints (i.e. Get Generic Plans and Get Generic Plan Detail) as well as the DH's Status and Outage APIs. The base URIs for energy PRD would continue to point to AER/EME until the time an energy retailer is onboarded onto the Register to go-live with CDR consumer data sharing. This would result in the AER/EME's public base URI for that retailer being replaced by the retailer’s own (e.g. https://cdr.energymadeeasy.gov.au/agl/ being replaced by https://public.cdr.agl.com.au/). Treasury leads CDR policy including developing the CDR Rules and related advice to the government. Within Treasury, the Data Standards Body (DSB) is responsible for assisting the Data Standards Chair in developing data standards to support the CDR. Treasury and the DSB have been consulting on potential measures to make it easier for PRD in the energy sector to be accessed and shared. This includes through Treasury’s August 2023 consultation on exposure draft amendments to the CDR Rules and Noting Paper #248 on the DSB’s GitHub. Should you have any feedback or queries in relation to policy or CDR Rules matters, you may contact Treasury’s CDR Framework unit at [email protected]. Should you have any queries or feedback for the DSB about the data standards, you may reach out via its GitHub. CDR agencies also jointly hold a bimonthly CDR Engagement Forum to help keep CDR stakeholders up to date on work and reforms. Should you be interested to join the invitation list for this forum, please contact [email protected]. |
| 2295 | We have a query in relation to the lendingRate and lendingRates fields in the BankingAccountDetailV3 schema. We have implemented this schema in line with the guidance provided (https://cdr-support.zendesk.com/hc/en-us/articles/900003776166-Guidance-on-the-BankingAccountDetail-schema). In particular, the guidance states: “Single rate or multiple rates: - If a product only has a single applicable rate, the array is not required, and the single rate can be provided in the …Rate field.” As a number of our products only have a single lending rate, we have not implemented the “lendingRates” array for them. This implementation has been queried by an ADR as it does not provide the attributes of the lendingRate such as lendingRateType, comparisonRate etc which are part of the BankingProductLendingRateV2 schema included in the array elements only. Can you please clarify the implementation of single lending rates and how the attributes of a single rate are intended to be shared? |
A general principle of optionality in the Standards is that relevant data must be shared if available, but the guidance for this particular scenario has not been clearly aligned. We have raised the following Standards Maintenance issue to propose refining this specific guidance to state that detail for one or more accounts is expected to be shared according to the schema requirements as a way to resolve the issue raised by the ADR in your query. #642 - Update guidance for Banking account rate detail Although it only proposes a change to guidance, this issue will be considered through the usual Standards Maintenance process to allow for participant consultation on the change of wording. If you have any concerns about Compliance, you can refer to the Compliance and Enforcement Policy guidance. |
| 2348 | I see in https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/509 the ACCC mentioned plans to introducing SLOs for incidents raised in the CDR Service Management Portal, but for the life of me I cannot find any reference to them. Can you point me in the right direction? We have an angry customer who has been waiting 10+ days to resolve an issue with a DH and we need to understand what the expectations are for DHs to respond to incidents raised in the portal. |
Service Level Objectives for the Service Management Portal have not been published. Data holders are expected to respond within a reasonable timeframe, and the ACCC examines responsiveness to tickets when considering the impact of any non-compliance. We encourage customers experiencing issues to contact their data holder, and consider making use of the Internal Dispute Resolution Service outlined in the Data Holder's CDR policy. |
| 2359 | As a data holder we are currently in a journey to change our existing backend Credit card platform/system. 1. We are migrating from Master card to Visa card scheme and the new Visa card will be attached to the new account number in the new platform/system. 2. Create a new Credit Card product and move all current customers over to this new product, noting they will have a new account number in the new system under this new product. Now, open banking uses the account number as primary key for credit card CDR data sharing and assuming the existing account numbers (Old platform) will appear as “Closed” in our database, the sharing arrangement will continue until it expires or is revoked by the customer but there will be no new data available for sharing from the closure date. This will impact the current customers with credit cards using Open Banking. As a DH we are not allowed to amend the consent on customer’s behalf to include the new CC account number in their consent what is the recommendation / guidance for such a situation? | We have provided general comments below that we hope will assist. Note the ACCC cannot provide advice tailored to individual scenarios and we encourage you to seek independent advice if you require specific information about your obligations. In the situation you describe, data holders cannot unilaterally amend a CDR consumer’s authorisation to share data in order to include the new credit card account number in the authorisation. As the data holder, you may wish to notify the consumer of changes impacting their sharing arrangement/s and advise the consumer to amend these via the relevant accredited data recipient (ADR). This would allow the consumer to add new accounts to the authorisation by initiating the consent/authorisation amendment process via the ADR. Please note that the data from the closed credit card account must continue to be available for sharing. We also note that data holders have discretion to provide functionality for CDR consumers to add/remove additional accounts from their data sharing arrangement in the data holder dashboard (see CX guidelines wireframe reference 19). If you provide this functionality you could consider whether it would be useful to notify consumers of their ability to add the new account to their authorisation through this functionality. |
| 2393 | As we build our solution for the Get Metrics endpoint, we noticed that within Get Metrics, the Performance metric now requires hourly data. As no other metric previously required hourly data, and only required monthly or daily, this poses a challenge as we have designed our database to only store data values on the daily or monthly level. So, we had some follow-up questions. As of now, only Performance metrics require hourly data. Why only Performance, and should we expect that other metrics will require hourly data in the future? The aggregate data within Performance still requires a daily value, and not hourly, while the individual tiers under aggregate require hourly data. Why was this set up in this manner? Not having data in a standard format within a given metric is not the recommended approach, in our opinion. Will there in the future be a change so that data is required on an even more granular level than hourly? We certainly want to future proof our solution, so that further extensive overhauls are not needed. |
The hourly performance metrics were introduced with Get Metrics v5 in Standards version 1.25.0 in July 2023. (Change Log.) The reason for the inclusion of the hourly performance break down was in support of monitoring the requirement in the Performance Requirements section: 95% of calls per hour responded to within a nominated threshold. Aggregated figures were retained to maintain equivalent values for trend analysis through the transition from previous Metrics versions to the more detailed values in the new version. Whether there will be further changes to the Get Metrics endpoint or other reporting requirements in future will depend on agency and participant requirements, potentially to accommodate the introduction of new sectors or other changes to the rules. Participants or other interested parties may raise change requests for any detail in the Standards on the Standards Maintenance issue repository. |
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.
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |