When: Weekly every Thursday at 3pm-4.30pm 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

---

1. Introductions
2. Actions
3. CDR Stream updates
4. Presentation
5. Q&A
6. 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 [email protected] 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.16.1 Published	Link to change log here
Maintenance	DSB Maintenance Iteration 10: Agenda & Meeting Notes on 30th of March 2022	Link to the agenda and minutes
TSY Newsletter	To subscribe to TSY Newsletter	Link here
DSB Newsletter	To subscribe to DSB Newsletter	Link here
TSY Newsletter	21st of March 2022	View in browser here
DSB Newsletter	25th of March 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
Consultation	Decision Proposal 240 - ADR Metrics	Feedback closes 15th of April 2022 Link to consultation
Consultation	Decision Proposal 245 - Enhancing Data Recipient Accreditation Negotiation	Link to consultation
Design Paper	Design Paper: Consumer Data Right Rules and Standards for the Telecommunications Sector	Link to DSB GitHub Link to Treasury page

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

Organisation	Stream	Member
DSB	CX Standards	Michael Palmyre
DSB	Technical Standards - Register	Ivan Hosgood
DSB	Technical Standards - Energy	Hemang Rathod
DSB	Technical Standards - Banking	Mark Verstege
DSB	Technical Standards - Engineering	James Bligh

None.

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.

We are using Sli.do for Question and Answer. Join our Q&A live here: https://www.sli.do/ Code: #747194

The following table will be updated after the meeting.

Ticket #	Question	Answer
1365	Ok, based on the answer DSB outlined from 1281. so for whatever reason that a user loses this Secondary user account privileges to transact, this should mean that he now loses his eligibility as a secondary user. I wish to find out how that ineligibility then affects: Secondary user instruction (question 1) If he has been given Sec user instruction previously to share data, then: 1. Does this mean his Secondary user instruction will need to be removed automatically? 1(a) if not, why not? Are we allowing a secondary user instruction to remain set for a ineligible person? Wouldn't it be confusing for users? 1(a.1) If he somehow regains Secondary user eligibility (i.e. able to transact) , it somehow just works? 1(a.2) this counts as DH refusal ? 1(b) if yes, there's no rules that I can identify that indicate that DH needed to notify the account owner(s) to let them know that a a user's secondary user instruction is removed so they might not know why it doesn't allow for sharing. The DH just stops the data, and withdrawn the instructions. The CX withdrawal standards couldn't come into "play" to inform any of the account owners or secondary user since it's not a user initiated withdrawal . 1(b.1) If he somehow regains Secondary user eligibility (i.e. able to transact) , does it mean he will need to request the account owners to re setup the instruction? (without knowing he lost it in the first place) 1(b.2) assuming if yes(to remove sec user instruction), would this counts as DH refusal ? 1(b.3) considering the last statement in 1(b), the withdrawal standards only requires DH to advise consumer as part of the sec user instruction, but nothing to cover/govern in the event of a automatic removal, is there a gap? Sharing agreements (question 2 and 3) 2. Does this mean his sharing agreements that he shared on the account will stop sharing data for the account but not withdrawing the account from those sharing agreements? (essentially just pausing data flow , basically same as removing sec user (instruction) OR 3. Does this mean his sharing agreements that he shared on the account will stop and the account be withdrawn from sharing agreements?. 3(a) if accounts are withdrawn, does it count as expired? or withdrawn? it triggers different email content to the account owners i think.	Thanks again for this question. Please refer to our recently released secondary users guidance which is available here.
1370	My question is in relation to the wording change for eligible customer from "is set up in such a way that it can be accessed online by the CDR consumer" to the following: "is that the person is able to access the account online." For joint account customers, where only one of the account holders is registered for online banking (not uncommon in relationships for one party to do all the banking), and the other is not registered for online banking - BUT has the ability to register by putting in their email address and OTP, does this mean that the joint account is ineligible to data share even though they will be "pre-approved" an only require one person to start a consent?.	A CDR consumer is considered eligible in the banking sector if they satisfy the eligibility criteria in rule 1.10B and clause 2.1 of schedule 3. As you mentioned, one of the eligibility criteria is that the CDR consumer must be able to access the account online. Our knowledge article on the Definition of an eligible CDR consumer explains that the purpose of the eligibility criteria is to ensure that a data holder has some online credentials it can leverage to authenticate the customer. We consider that a CDR consumer is able to access their account online if they have credentials in place to use online banking. Please note that Treasury has confirmed that the amendment to the wording of the eligibility criteria for the banking sector resulted from some ‘housekeeping’ amendments undertaken as part of the v4 rule amendments (to move common elements of eligibility for the banking and energy sectors into new rule 1.10B, while sector specific elements remained in the sector schedules). Treasury acknowledges the amendment has resulted in inconsistent language, but has confirmed that the policy intent was for the eligibility requirements for the banking sector to remain unchanged. That is, consistent with the CDR support portal guidance, the policy view is that CDR consumers in the banking sector must have an online account set up to be eligible. Section 4 of our Revised joint account implementation guidance states that all joint account holders must be ‘eligible’ consumers in their own right in order to be able to share joint account data. Hence, each joint account holder must be aged 18 years or older and hold an account with the data holder that is open and accessible online. Please also refer to our knowledge article on Joint accounts and eligibility for more information.
1414	Within the 'Joint Accounts implementation guidance 2022 PDF' section 5.9 states Data holders must update the disclosure option management service as soon as practicable to give effect to: - any disclosure option indicated by a joint account holder - any changes to a disclosure option, and - the withdrawal of a disclosure option. we would like you to please define the term ' withdrawal of a disclosure option' in this statement. I believe this may be a error in choice of wording and that this section refers to withdrawing consent from an authorisation OR changing a disclosure option to 'Non disclosure'	Thank you for raising this with us, it's very helpful to have this kind of feedback. We have amended paragraph 9 to read: "Data holders must update the disclosure option management service as soon as practicable to give effect to any change in the disclosure option." This should be reflected in the guidance shortly.
1420	Scenario: Invoking the GET balances for specific endpoint API resource[1] with sending the meta field value as null. Sample Request Body: {"data":{"accountIds":["<account id 1>","<account id 2>"]},"meta":null} Question: What should the data holder do when it receives this? Since this is a null do DH should omit that from the request and process? or since they are sending null to a field that should use only if necessary should DH reject the request? If they should reject what is the expected error? Thanks in advance for your help. [1] https://consumerdatastandardsaustralia.github.io/standards/#get-balances-for-specific-accounts	This is at the discretion of the Data Holder. Technically the Data Holder would be within their rights to reject with error. This may create a poor customer experience, however, so the Data Holder may opt to be more tolerant and allow the request to succeed as there is nothing in the meta tag that is needed for this request.
1431	Is there a guidance document for business accounts /secondary users / authorised representatives similar to the one for joint accounts? Also, are there any wireframes for nominating an authorised representative?	Please find our recently published secondary user guidance here. We intend to publish guidance relating to non-individual / partnership accounts and the nominated representative provisions shortly, relevant updates will be contained in the CDR newsletter.

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