-
Notifications
You must be signed in to change notification settings - Fork 56
ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes | 27th of October 2022
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: [email protected]
Phones - AUDIO ONLY
- Primary Australia: +61-2-9338-2221
- Quick Dial: +61-2-9338-2221,,1650705270##
- Other Global Numbers: https://treasuryau.webex.com/cmp3300/webcomponents/widget/globalcallin/globalcallin.do?MTID=m311f46c87a3ab9ae5335a6c0ea431da4&MTID=m311f46c87a3ab9ae5335a6c0ea431da4&MTID=m311f46c87a3ab9ae5335a6c0ea431da4&MTID=m311f46c87a3ab9ae5335a6c0ea431da4&serviceType=MC&serviceType=MC&serviceType=MC&siteurl=treasuryau&siteurl=treasuryau&siteurl=treasuryau&apiname=globalcallin.php&apiname=globalcallin.php&apiname=globalcallin.php&rnd=6124483603&rnd=6124483603&rnd=6124483603&tollFree=0&tollFree=0&tollFree=0&ED=1403111402&ED=1403111402&ED=1403111402&needFilter=false&needFilter=false&needFilter=false&actappname=cmp3300&actappname=cmp3300&actname=/webcomponents/widget/globalcallin/gcnredirector.do&actname=/webcomponents/widget/globalcallin/gcnredirector.do&renewticket=0
- Meeting Number/Access Code: 165 070 5270
- Introductions
- Actions
- CDR Stream updates
- Presentation
- Q&A
- Any other business
- 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, 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.
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 [email protected] 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 [email protected]. |
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. |
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 |
Miro link: https://miro.com/app/board/uXjVPJ8VyZI=/?share_link_id=178546226188
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.
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. |
View a number of informative and useful links in the Consumer Data Standards Guide on Information Links.