When: Weekly every Thursday at 3pm-4pm AEDT (2pm-3pm 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: [email protected]

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

1. Introductions
2. COVID-19 impact for CDR program
3. Outstanding actions
4. CDR Stream updates
5. Presentation: Concurrent Consent decision proposal
6. Q&A
7. Any other business

Meeting notes

• Meeting Notes
• Next steps

• 5 min will be allowed for participants to join the call.

Information on recent events related to COVID-19 and the impact to CDR.

• Answers to the questions raised in the previous meeting refer to Issue #167 which provides clarification on questions.

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

Concurrent consent decision proposal. See Decision Proposal 99

Questions will be received by the community via WebEx chat before the questions are opened to the floor.

Currently received pre-submitted questions:

#	Question
#1	We are grappling with issues serving up data on Accounts. We have very few features that are stored in core banking systems – most are available in product collateral. As a result we are using a stand alone product reference data solution as the source for Product reference Data (PRD) and we know that this is the approach that many others have taken. In the standards the Account Detail features array states “Array of features of the account based on the equivalent structure in Product Reference with the following additional field.” Is this intended to be the features that the customer has made use of/enabled at the account or all of those available on the type of account? If the former, there is a significant risk that it will not be consumed as such and will be seen as a low feature account, when in fact it is not (eg just because an account doesn’t make use of an offset doesn’t mean it isn’t available). Further, if the direction is that it should be just those features that are ‘enabled’ then we cannot just associate with product and serve up all features – the result would mean that we would end up showing less than the full set of features actually enabled (unless we came up with some chicanery to assume certain features are always enabled whereas others have to be ‘checked.’
#2	https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/164
#3	https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/149
#4	https://github.com/cdr-register/register/issues/56

• The ACCC provided an update on the situation with COVID-19. The ACCC is aware of the situation and the impact on banks and data recipients and their business as usual.
• Currently the ACCC are liaising with participants on any impact to the rollout of the CDR will be published in due course.

Q&A responses

#	Question	Answer
#1	This question was raised in the Data Holder Working Group call on 26/03/2020. Issue 171 - Handling features relevant to an account	Answered in the issue comments
#2	Issue 164 - Error response code for x-v version headers	Answered in the issue comments
#3	Issue 149 - Admin API - Clarification regarding authentication	Answered in the issue comments
#4	Issue 56 - KID value in the JWKS	ACCC are in the process of drafting an answer. It will be responded to within the issue's comments
#5	Issue 163 - Clarifications on Metrics Requirements	Answered in the issue comments
#6	Issue 165 - Clarification of the intent of ProductName on BankingAccount response	Answered in the issue comments

Other business

• None

• None