-
Notifications
You must be signed in to change notification settings - Fork 56
ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes (3rd of June 2021)
When: Weekly every Thursday at 3pm-4.30pm AEST
Location: WebEx, quick dial +61262464433,785383900%23%23
Meeting Details:
Desktop or Mobile Devices
https://csiro.webex.com/csiro/j.php?MTID=m7c39ee9db5e5892ab35cd0bd7bbf94ce
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: 785383900@csiro.webex.com
Phones - AUDIO ONLY
- Primary Australia: +61 2 6246 4433
- Quick Dial: +61262464433,785383900%23%23
- Other Global Numbers: https://conferencing.csiro.au/Call-in.php
- Meeting Number/Access Code: 785 383 900
- Introductions
- Actions
- CDR Stream updates
- Presentation
- Q&A
- Any other business
- 5 min will be allowed for participants to join the call.
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.
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.
| Type | Topic | Update |
|---|---|---|
| Standards | Version 1.10.0 Published | Link to change log here |
| Standards | Version 1.11.0 Draft Board Created (no content yet) | Link to Version Project Board here |
| Maintenance | 7th Maintenance Iteration underway | Agenda of the backlog session |
| Maintenance | Decision Proposal 178 - Banking Maintenance Iteration 7 | Link to consultation |
| DSB Newsletter | To subscribe to DSB Newsletter | Link here |
| TSY Newsletter | To subscribe to TSY Newsletter | Link here |
| TSY Newsletter | 27th of May 2021 Edition | View in browser here |
| DSB Newsletter | 28th of May 2021 Edition | View in browser here |
| Consultations | Decision Proposal 157 Noting Paper 157 - CX Standards Arising from v2 Rules | Link to consultation |
| Consultations | Decision Proposal 160 - CX Standards - Non-individual Consumers - Business Partnerships - Secondary users | Link to consultation |
| Consultation | Decision Proposal 162 - CX Standards, Joint Accounts, Authorisation Flow | Link to consultation |
| Consultation | Decision Proposal 166 - CX metrics for Data Holders | Link to consultation |
| Consultation | Decision Proposal 180 - Energy Draft Feedback Cycle 3 | Link to consultation |
| Consultation | Decision Proposal 182 - InfoSec Uplift for Write | Link to consultation |
| Consultation | Decision Proposal 183 - Purpose Based Consents (Placeholder) | Link to consultation |
| Consultation | Decision Proposal 186 - Engineering Support | Link to consultation |
| Consultation | Decision Proposal 187 - CX Standards - Disclosure Consents | Link to consultation |
Provides a weekly update on the activities of each of the CDR streams and their workplaces
| Organisation | Stream | Member |
|---|---|---|
| ACCC | CDR Register (Technical) | Ivan Hosgood |
| ACCC | Onboarding | Chantelle Demian |
| DSB | CX Standards | Michael Palmyre |
| DSB | Technical Standards - Banking | James Bligh |
| DSB | Technical Standards - Energy & Engineering | James Bligh |
None this week.
Questions will be received by the community via WebEx chat before the questions are opened to the floor. Participants can pre-submit questions to the DSB mailing box.
We are trialling Sli.do for Question and Answer. Join our Q&A live here: https://www.sli.do/ Code: #169517
| Ticket # | Question | Answer |
|---|---|---|
| 508 | Where the consent types are concern, do we need to allow consumers to provide different duration for the different consent type or will one duration be applied to all the consent types that they have chosen | For a single authorised consent there is a single duration that applies to all scopes included in the consent. If there are multiple separate, concurrent consents, however, each can have a separate duration. |
| 516 | As a Data Holder, will we need to provide ability for consent to use and consent for collection of data separately in the consent screens? Will we also need to provide a function to separate these two consents on the dashboard for withdrawal purposes? As a non-bank DH, will these changes be applicable to us in July 2021 or in November 2021? |
Question 1: As a Data Holder, will we need to provide ability for consent to use and consent for collection of data separately in the consent screens? Data Holders only deal with authorisations to disclose, which corresponds to the ADR-side consent to collect. Data holders have no oversight of any consent-related information other than the datasets that the ADR requested and the duration of the collection consent / authorisation. Question 2: Will we also need to provide a function to separate these two consents on the dashboard for withdrawal purposes? The separation of consents in the v2 rules means that consents to collect and consents to use can operate independently of each other. As such, authorisations withdrawn using the data holder dashboard only cause the corresponding consent to collect to expire. In such a case, rule 4.18A requires that the CDR consumer is notified that they can withdraw the remaining use consent. Question 3: As a non-bank DH, will these changes be applicable to us in July 2021 or in November 2021? Can you clarify if this query relates to ADRs or DHs? The v2 provisions that separate consents provide flexibility to ADRs and do not require changes on the data holder's side. These provisions came into effect on 23 December 2020 (the day after the rules were made). |
| 533 | Can you please help define "record" in the following rule. Do you mean when the CDR consent record was first created OR when each record of change is created. "(5) Each record referred to in this rule must be kept for a period of 6 years beginning on the day the record was created." Example 1: if a CDR record was created on 1/12/20 and then an ammendment was made on 1/12/21 - Do we keep the create record till 1/12/26 and the ammendment record till 1/12/27? Example 2: if the record was created on 1/12/20 and renewed on 1/12/21 - and we have to provide records on 1/12/27 - Do we give the CDR consumer the start date of the original record OR the start date of the renewed record? |
Rule 9.3(1) requires data holders to keep and maintain records that record and explain (amongst other things) both authorisations given by CDR consumer to disclose CDR and amendments to authorisations to disclose CDR data. This means that both of these types of records must be kept for a period of 6 years beginning on the date the record was created. For example, records that record and explain an initial authorisation made on 1 December 2020 would need to be kept an maintained for 6 years from that date. Records that record and explain an amendment to that initial authorisation made on 1 December 2021 would need to be kept and maintained for 6 years from that date. Further, it is expected that records that pertain to an amendment to an authorisation should also include some description of the original authorisation. |
| 540 | If a request comes through after the eligibility period is expired and the data becomes voluntary data, it is not considered a refusal to disclose CDR data? Also - could I please get a clarification from DSB on what the expectation is from API response perspective? |
CDR Support Portal Article |
| 782 | I believe that in April there was an item raised regarding PRD Reg Reporting and that there will be an amended version that would be issued. In looking through GitHub and DSB resources I cannot see that this has been issued, could you correct me if I am wrong and where I could locate this form so that we are well placed to ensure we are compliant. |
The last change I'm aware of was the splitting of authenticated and unauthenticated rejections in v2 of the metrics API, but that was v1.5.0 and was last September. |
| 797 | We were wondering whether we could apply to have two entities accredited together as they both trade under a common branding. If this is possible, how do we complete the application form etc? | If two or more separate entities require accreditation, then each entity must apply separately for accreditation. However, as stated in section 5.6 (p. 15) of our Accreditation Guidelines, we can consider related applications together and there may be scope for efficiencies in the application assessment process if the related applicants share certain arrangements (e.g. insurance or information security) across a corporate group. We would encourage you to contact us directly at accc-cdr@accc.gov.au to set up a time to discuss your own particular circumstances with us before submitting your application(s). |
| 817 | The schema is not at all clear on this. what is the interpretation of ROLLED_OVER PAID_OUT_AT_MATURITY HOLD_ON_MATURITY please. Our assumption is that these are the meanings: ROLLED_OVER = Customer wants to roll over the principal and interest PAID_OUT_AT_MATURITY = Customer wants principal and interest to be paid out in full at maturity HOLD_ON_MATURITY = customer wants interest paid out at maturity and principal to be rolled over. Please can you confirm that this is the correct interpretation. |
your definitions are a good interpretation. The three states are indicative of the customer's instruction given the bank, or in the absence, the default instruction the bank would take based on their product disclosure statement / terms and conditions. Hold on maturity was introduced in v1.5.0 based on feedback that some banks had a different instruction when a term deposit reaches maturity whereby the funds are placed in a holding facility similar mechanism managed by the bank for a period of time until the customer provides explicit instructions or the maximum period of the hold has elapsed. During this time, the term deposit has not rolled over but continues to accrue interest. In this scenario, funds may be renewed or withdrawn upon instructions by the customer. Further context is available here: https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/153 |
Updating the table below - if your question/ ticket has not received a response yet the team continues to work on a response. We do apologise for the delay on some tickets, the teams are doing their best to get to everyone's questions.
To our valued CDR participants, We have undertaken a review of the CDR Support Portal as a channel for providing guidance on CDR Rules. Based on the volume and nature of questions we have received recently, we have decided to move to a model based on publishing guidance to the community, rather than providing individual responses to stakeholder questions. Our goal is to prioritise the provision of guidance that is accessible, transparent and has industry-wide application. We intend to develop this to meet clear community needs, which we will identify and prioritise based on questions and issues raised by stakeholders. We kindly ask for your patience as we work our way through the tickets, feedback and guidance
A work in progress - open for feedback from the community on what you would like to see.
| Organisation | Description | Link |
|---|---|---|
| OAIC | Main landing page for the Office of the Australian Information Commissioner and the Consumer Data Right | Link |
| DSB | CX Artefacts - The CX Guidelines provide optional examples of key requirements and recommendations to help organisations build best practice consent models. CDR Participants should also refer to the CDR Rules, data standards, and privacy guidelines for a complete view of obligations to facilitate compliance. | Link |
| DSB | Consumer Data Standards Main Page - About the DSB team, engaging with our consultations and Events | Link |
| DSB | The Consumer Data Standards - The technical and consumer experience standards for the Consumer Data Right | Link |
| DSB | The Banking Product Comparator - a demonstration of Product Reference Data from Data Holders as part of the Consumer Data Right | Link |
| DSB | GitHub Consultations - all public consultations from the Data Standards Body | Link |
| DSB | Java Artefacts - An Open Source Project comprised of reference implementations of both Data Holders and Data Recipients | Link |
| ACCC & DSB | The Consumer Data Right Support Portal Knowledge base for the Consumer Data Right covering Rules through to Technical articles and questions |
Link |
| ACCC | ACCC Main focus area/ landing page for the Consumer Data Right | Link |
| ACCC | GitHub Consultations - all public consultations from the ACCC Register Team | Link |
| ACCC | CDR Register Design Reference | Link |
| ACCC | Public page for the Consumer Data Right | Link |
| ACCC | Participant Portal page including sign-up and log-in | Link |
| TSY | Consumer Data Right background and historic records from the Treasury | Link |