Skip to content

ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes | 27th of October 2022

CDR API Stream edited this page Oct 27, 2022 · 11 revisions

CDR Implementation Call Banner

Agenda & Meeting Notes

When: Weekly every Thursday at 3pm-5pm AEDT
Location: WebEx, quick dial +61-2-9338-2221,,1650705270##

Meeting Details:

Desktop or Mobile Devices https://treasuryau.webex.com/treasuryau/j.php?MTID=m9614a7c6166155d3d950a8999e437f9f Once connected to your meeting remember to start your audio and video
Please mute when you are not speaking.

Video Conferencing (VC) Rooms
Use the remote control or touch panel and dial the number indicated below:
External VC Room: 1650705270@webex.com

Phones - AUDIO ONLY


Agenda

  1. Introductions
  2. Actions
  3. CDR Stream updates
  4. Presentation
  5. Q&A
  6. 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 contact@consumerdatastandards.gov.au 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

Type Topic Update
Standards Version 1.19.0 Published on 13th of September 2022 Link to change log here
Standards Version 1.20.0 is being staged View the branch here
Maintenance Maintenance Iteration 12 Last met on 14th of September 2022
Agenda for the Final meeting here
Maintenance Decision Proposal 259 - Maintenance Iteration 12 Changes, meeting notes and updates for the iteration can be found here
Maintenance Maintenance Iteration 13 underway Met 26th of October 2022 and the agenda for the meet is here)
Maintenance Decision Proposal 272 - Maintenance Iteration 13 Changes, meeting notes and updates for the iteration can be found here
TSY Newsletter To subscribe to TSY Newsletter Link here
DSB Newsletter To subscribe to DSB Newsletter Link here
TSY Newsletter 28th of September 2022 View in browser here
DSB Newsletter 14th of October 2022 View in browser here
Consultation Normative Standards Review (2021) No Close Date
Link to consultation
Consultation Decision Proposal 229 - CDR Participant Representation Placeholder: no close date
Link to consultation
Noting Paper Noting Paper 255 - Approach to Telco Sector Standards Link to consultation
Noting Paper Noting Paper 258 - Independent Information Security Review Link to consultation
Consultation Decision Proposal 267- CX Standards Telco Data Language
Feedback closed: 15th of September 2022
Thanks to those who provided feedback on DP267 by 15th September. With the v5 rules out for consultation, the DSB will leave this issue open for comments while considering existing feedback and developing version 2 of DP267, which is expected to be published for consultation in October.
Link to consultation
Survey The Data Standards Body invite the CDR Community to provide feedback on the different Engineering Tools and platforms. Link to survey
Survey 2022 - 2023 CDR Implementation Call
Closes Monday 31st of October 2022
Link to survey
Webex Plan to switch over to Microsoft Teams by early November 2022 Updated invitations will be sent out in the coming weeks
Video New DSB Video on CX Guidelines - narrated by Neale Morison (21/10/2022) Link here
Guidelines CX Guidelines join the Maintenance Iteration
As part of Maintenance Iteration 13 the ability to raise a change request for the Consumer Experience Guidelines has been introduced. Please note the following for the CX Guidelines:
- CX Guidelines are not standards, and are not binding.
- CX Guidelines are not intended to be comprehensive. Certain areas are out of scope.
- CX Guidelines are not part of the Consumer Data Standards maintenance cycle.
Create change request
Guide
Video on the CX Guidelines and raising a change request
Guidance The ACCC has published new guidance on the De-identification of CDR data under the Consumer Data Right which outlines the obligations of ADRs in relation to the treatment of de-identified and redundant data under the Rules and the Act. Can be found here
Secondary Users CDR participants have raised concerns about implementing the functionality required by rule 1.15(5)(b)(i) and 4.6A(a)(ii) following recent clarifications published in the Ceasing Secondary User Sharing article.
On the October 20th CDR implementation call, DHs and ADRs urgently requested that this issue be escalated given the impending obligation dates relating to rule 1.15(5)(b)(i) and 4.6A(a)(ii), and several risks relating to the functionality that would be introduced. As these issues go beyond the scope of the data standards, the DSB agreed to return with an appropriate course of action for participants.
The DSB, Treasury and the ACCC are actively working to address stakeholder concerns about this functionality, and Treasury is considering possible rule changes. We encourage DHs and ADRs to email the Treasury at data@treasury.gov.au with their concerns. Stakeholders may consider including any risks they believe will be created due to rule 1.15(5)(b)(i) and 4.6A(a)(ii); any concerns relating to implementation timeframes and compliance; and suggestions they believe may help address any issues they have identified. If stakeholders have concerns about their individual compliance status, they can contact the ACCC via ACCC-CDR@accc.gov.au.
N/A
Workshop Save the date, for a workshop!
Treasury and the DSB are considering opportunities to simplify the rules and standards to support a better CDR consumer experience while maintaining key consumer protections. To support this work, a virtual workshop will be held on Tuesday 22nd November, and an accompanying noting paper will be available on GitHub (see Noting Paper 273).
This workshop will be of interest to current and prospective data recipients, data holders, consumer advocates, industry representatives, and other parties interested in the evolution of the consent model. Participants will be given the opportunity to comment on possible consent model changes in an interactive session. This workshop will be conducted virtually using Miro to support remote participation. We encourage stakeholders to save the date and ensure they can access the Miro platform on the day.
Further details about the event and how to RSVP will be shared in the coming weeks.

CDR Stream Updates

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

Organisation Stream Member
ACCC CDR Register Emma Harvey
ACCC CTS Andrea Gibney
DSB CX Standards Michael Palmyre
DSB Technical Standards - Banking & Infosec Mark Verstege
DSB Technical Standards - Energy Hemang Rathod
DSB Technical Standards - Telecommunications Brian Kirkpatrick
DSB Technical Standards - Engineering & Register James Bligh

Presentation

Telecommunications update on the Consumer Data Standards development

Miro link: https://miro.com/app/board/uXjVPJ8VyZI=/?share_link_id=178546226188

Q&A

Questions on Notice

Questions will be received by the community via WebEx 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
1708 Can you please confirm which formula is the correct one for the performance calculation noting that the CDS NFR says "95% of calls per hour responded to within a nominated threshold"
The formula # 1 : Get the average calls per hour that are within the performance average. To calculate the daily average, take the average of the aggregated daily average. Please see attached screenshot.
The formula # 2 : total number of calls within the performance threshold per day/total number of calls per day.
Also, must we consider errornous calls (i.e. 5xx calls) in the calculation ?
I think the thing that confused us here is that the original question linked to the availability section of the NFRs and not the performance section. I will answer assuming that we are only talking about performance and not availability based on your clarification.
It is important to note at the outset that the NFRs talk about an hourly requirement (which is the obligation) but the metrics API requires daily reporting. This is because the metrics API is not designed to be NFR compliance reporting. It was designed to be a mechanism to get high level data that the ACCC that could you use for ongoing monitoring of the ecosystem and the creation of public dashboards. The rules give wide authority to the regulator to request reports from data holders so they are entitled to ask for hourly NFR compliance data on a regular basis or even ad hoc if they wish.
In summary, the requirements of the metrics API should not be considered the limit of what must be reported to the ACCC so it is essential for data holders to retain the underlying data at a granularity that they can report on their NFR compliance obligations.
In that context, the calculation for the actual NFR for performance would be as follows:
- For each of the performance tiers (unauthenticated, high priority, etc)
- Find Total Invocations, defined as the aggregated number of all invocations for all APIs in that tier for the hour to be reported on
- Including error and rejected invocations
- Excluding timed out invocations
- Find Total Exceeded, defined as the number of these invocations that exceeded the time threshold for the tier
- Calculate ( 1 - (Total Exceeded / Total Invocations) ) * 100 and report as a percentage for that tier and time period
For other time periods (current day so far, a specific 24 hour period) the calculation is the same, the period of time is simply different.
Do not create the daily metric as an average of averages as this will bias the final result to low traffic periods. The appropriate calculation is to find the total number of invocations and the total number exceeding threshold for the report period and dividing those numbers.
For instance, If you do 1000 invocations within the threshold in an hour and 1 invocation outside the threshold in the next hour you will end up with a 50% metric if you average the averages of these two hours but 99.9% if you aggregate across the two hours. The latter result is more correct.
Relating this back to your original question, the calculation provided above is closest to your option 2 (noting that I have given more specific detail in my pseudo code above).
1759 We have below queries with respective to Data Recipient, can you please help us in understanding below concepts
Data Recipient:
1) Regulatory Repots:
Is the Submission of regulatory reports on regular intervals applicable to Data Recipient? If Yes, please provide the reference link.
2) Data Cleanup:
Is Recipient needs to clean up the user data once the consent expires?
3) System Metrics:
Please provide more info related to Data Recipient System Metrics
4) Data Recipient Architecture:
Can you please share the “Data Recipient Components breakup / Architecture diagram” for reference
We note that the DSB has provided a response to relevant parts of your enquiry. Further information regarding consents can be found in Chapter C of the CDR Privacy Safeguard Guidelines published by the OAIC.
ADRs must keep and maintain records including CDR complaint data (see rule 9.3(2)). CDR complaint data’ is a defined term for the purposes of the rules (see rule 1.7). The definition includes the number of CDR consumer complaints received by the CDR participant, the number of such complaints resolved and the average number of days taken to resolve CDR consumer complaints through internal dispute resolution, amongst other things. For the purposes of rule 9.3(2) ADRs must keep and maintain records that record and explain their CDR complaint data. This could be in the form of ‘complaint logs’ which evidences information such as the following: name of the CDR consumer complainant; time/date complaint was made; complaint type; summary of the complaint; status summary of the complaint, including whether it was referred to an internal or external dispute resolution scheme, and if so, when; and if it was resolved, when it was resolved and a summary of the resolution outcome.
ADRs must also prepare a report for each reporting period which complies with the requirements set out in rule 9.4(2) and this includes summarising the relevant CDR complaint data. ADRs are required to complete and submit their reports by entering information into the CDR Participant Portal. Further information on reporting forms and a link to an example of a reporting form for ADRs can be found here.
1769 In regards to this article: https://cdr-support.zendesk.com/hc/en-us/articles/4523876174863-What-constitutes-a-refusal-to-disclose-required-data-
Can i check where would account ownership changes falls under? E.g. If an owner is removed/added to an account, so we refuse to disclose the account under the original sharing authorisation. Should that be reported to the ACCC as a refusal.
It appears you are seeking to understand the impact when an account holder is added or removed – this is most likely to happen in relation to joint accounts.
We consider that when a joint account holder is added or removed from a joint account, it does not constitute a refusal as it does not satisfy the conditions in rule 3.5 or rule 4.7. This means it does not need to be reported to the ACCC as a refusal.
If a joint account holder is added to an individually held account and a pre-approval disclosure option applies, the new joint account holder is taken to have approved existing authorisations to disclose data. However, if a co-approval disclosure option applies, sharing from the joint account under an existing authorisation must pause until the new joint account holder has given their approval.
If a joint account holder is removed and the joint account remains open, the former joint account holder’s existing authorisations and the remaining joint account holders’ authorisations will all remain current. However, the data holder cannot make new disclosures from the joint account on behalf of the former joint account holder.
Where a joint account holder is removed and a joint account is subsequently closed, the former joint account holder will not be able to access historical data from the closed joint account. However, if all account holders remain eligible consumers, data holders must continue to support data sharing for that closed account.
Please refer to our knowledge article on Authorisations when a joint account holder is removed from or added to a joint account for further information. We hope this information assists you – if you have further questions or are seeking advice in relation to a different scenario, please feel free to get in touch again with further information and we will be happy to assist you further.

Useful Links

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

Consumber Data Standards on GitHub The official Consumer Data Standards website This repository contains the binding API Standards and Information Security profile created in response to the Consumer Data Right legislation and the subsequent regulatory rules. A demonstration of Product Reference data from the Banking Sector.
Follow Data Standards Body on LinkedIn for updates and announcements Data Standards Body video channel on YouTube Helping organisations provide consumers with intuitive, informed, and trustworthy data sharing experiences. A Postman collection with a set of unit tests. It can be used as a development testing tool for Data Holders developing a DSB compliant API.
Check out our guides, browse through our FAQs, and post your own questions for Support. Digital Resources Repository on DSB's GitHub website The glossary of CDR CX terminology Data Holder server reference implementation and associated tools.
  A repository of DSB Newsletters/Blog posts since 2019 This repository is the staging repository for the Consumer Data Standards. Java Artefacts Data Holder server reference implementation
  This glossary lists terms and their definitions in the context of the Consumer Data Right and Consumer Data Standards. This repository is used to contain discussions and contributions from the community of participants and other interested parties in the Australian Consumer Data Right regime.  
Clone this wiki locally