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: [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. Actions
3. CDR Stream updates
4. Q&A
5. Any other business

Meeting notes

• Meeting Notes
• Next steps

• 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.

Type	Topic	Update
Standards 1.5.1	Published	Link to change log here
Maintenance	5th Maintenance Iteration underway	List of scope and agenda(s) can be found here
Decision Proposals	Decision Proposal 112 - Usage Data Payloads	Link to Decision Proposal 112
Decision Proposals	Decision Proposal 114 - Account Payloads	Link to Decision Proposal 114
Music	Request for intro music	Trial of YouTube Audio Library
Community	New Community Module now enabled on CDR Support Portal	Link to CDR Support Portal here
Community Blog Updates	Blog post on using the Product Data APIs to explore the available data.	Link to the Community Section
Daylight Savings	First weekend of October	CDR Implementation Call remain at 3:00PM AEDT
DSB Newsletter	To subscribe to DSB Newsletter	Link here
ACCC Newsletter	To subscribe to ACCC Newsletter	Link here
ACCC Newsletter	30th of September 2020 issue	Latest issue can be found here
Banking Product Comparator	For who wish to publish their endpoints on the Banking Product Comparator Tool we have put together some tips and simple instructions to get you going	Check out the guide here at the CDR Support Portal

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

• ACCC Rules
• ACCC CDR Register (Technical)
• DSB CX Standards
• DSB Technical Standards - Banking
• DSB Technical Standards - Energy & Engineering

End Point Versioning walkthrough
Hosted by James Bligh
Read more here

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.

Current received pre-submitted questions:

Ticket #	Question	Answer
173	Appreciate if we could get some answers to these github issues. Expectations when a consumer closes their account/relationship with an ADR Issue 313	-
175	Quick question around handling of x-v and x-min-v headers in couple of scenarios. Where x-v = a supported version, and x-min-v is sent in the request, however a blank value is sent like shown below - x-v = 2 x-min-v = What should the expected response be - 200 OK or a failure response?. If the response should be a failure response, should it be a 406 or 400 response code? We have noticed 3 out of the big 4 (and few other non majors) responding differently to this scenario, and we were hoping to clarify the correct way to handle this. Another rare scenario (however still possible I guess), where x-v or x-min = 0 or a negative integer, should the error response be 406 or 400 in this instance. If the mandatory header x-v is not present in the request at all, should the response be a 406 or a 400 in this scenario? We are under the impression that this is a 400 bad request, however would like to clarify.	-
177	Hi – Just looking for an update on the required approach for use of ADR/brand/software product names and logos as requested through these issues. As the non-majors progress their builds it is becoming increasingly important to have direction on this to ensure consistency across the ecosystem. https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/222 https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/296	-
178	Do we have any metrics and other info that shows what's working well and what is not? There is no information available in the public domain. Is there a plan to publish something similar to API performance that is published by the folks in the UK? https://www.openbanking.org.uk/providers/account-providers/api-performance/	Idea taken on notice
182	The future date obligation date for PRD Phase 2 compliance is 1/2/2021 and version 3 PRD APIs are by 28/2/2021. 1. Can you please confirm that we can compliantly implement and support both v2 and v3 PRD APIs as at 1/2/2021. 2. Is there a proposed date to obsolete the v2 PRD APIs?	-
184	Can you please advise when the Register might be made available for testing purposes to the Tier 2 banks for the July 2021 release so that we can factor this into our planning? Appreciate this might be early, but some visibility on indicative timeframes would help with our planning. Thanks.	-
185	What would the purpose of this entity be for? Is the only scenario we would use this, if a consumer had a scheduled payment set up once every 28 days and therefore we return this entity with the last weekday? This scenario could also be returned under the BankingScheduledPaymentInterval entity - therefore, do we even need to use this entity? Are there any other scenarios we would use this entity for?	-
189	I have been unable to find guidance on when a CDR Policy must be made available by Data Holders. A literal reading of the regulation would suggest that it should be made available as soon as any data sharing occurred (i.e 1 October for most data holders). However, the vast majority of a typical CDR Policy is only relevant for customer data sharing. Can you confirm that a Data Holder does not need to provide a CDR Policy until they begin customer data sharing?	-
190	I am seeking guidance on how "wholesale" products are handled in the CDR. In this context I'm talking about products that are sold via alternative channels, but branded by the Data Holder. Examples would be term deposits sold through marketplaces such as Australian Money Market or Cashworkz, or loans sold through brokers. In these cases, the terms and conditions may differ from directly sold retail products. As the channels are generally not ADIs and therefore not Data Holders, I would assume any obligations would fall back on the product originating ADI. It's unclear if these products are "publicly available" under the CDR definitions as they are not sold directly by the ADIs concerned. Additionally, the terms and conditions can vary across the re-sellers and so if required, how should they be exposed in the PRD APIs? A separate entry for each re-seller, or a generic entry with, for example, no rates given? Any additional guidance around "wholesale" products sold through alternate channels would be appreciated. Thanks.	-
191	Could you please elaborate on what is meant by the agentRole? Is this referring to the job title of the individual or is it their account relationship type, e.g. signatory, business owner etc?	-
192	We, are looking for clarity on requirements that are compulsory for account & transaction data on Phase 1 & 2 products, specifically for joint accounts. We understand that ACCC provided the Joint Account Guidance where scenarios are outlined. The question we have is on the status of Joint Account Guidance document – are the requirements derived from this document compulsory to implement, or only suggested but not compulsory? Specifically the next two requirements – are they compulsory to implement for account & transaction data on Phase 1 & 2 products release: 1. ‘Pause’ via JAMS (Scenario 4a & b) If one of Joint Account Holders removes an election via JAMS for an account that is already in an active sharing arrangement with 3rd party, authorisation should not be withdrawn, but the data sharing for that account should be stopped. Removal of election via JAMS for joint account does not cause removal of this account from authorisation. It only caused the data sharing to stop for this account. 2. Resume via JAMS (Scenario 4c & 7) After the requirement above, if both Joint Account Holders elect though JAMS for this same joint account that is ‘paused’ in an active sharing arrangement to be shared back (meaning this account is marked back as ‘available for data sharing’), the data sharing should continue as this account was never removed from authorisation in the first place.	-
193	Issue: https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/327	-
195	Could you please provide clarity about what “a product that is publicly offered” (under the ACCC CDR Rules) and “products that are currently openly offered to the market” (under the CDR Standards for Banking APIs) means when it comes to sharing required PRD. Specifically, if a phase 1 product is currently only offered by direct invitation to existing customers (i.e. not through online application channels), is PRD required to be shared?	-
196	https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/329 https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/330	-
197	Could you please advise if the lastUpdateTime field relates to the information in the CommonOrganisation entity or is it the last time any information on this organisations account / profile was updated, which could be information that is not included in this entity??	-
198	Guidance required from Data61 – V1.4.0 introduced a new feeType of variable in the BankingProductFee schema. Could you please clarify if this new feeType is applicable ONLY for version 3 (Get Product Detail API) or for version 2 also? More detail below Problem statement: As a Data holder, in our case, the ‘variable’ feeType is applicable to our Home loan product suite and our data sharing obligations commence (for this product) in Feb 2021 which is in line with when version 3 needs to be implemented. However, considering we would need to support version 2 as well simultaneously, we would like to get guidance on how we should represent these ‘variable’ fees in version 2. If we represent these fees with any of the other enumerated values other than variable, then based on the standards, we would be expected to provide a value in at least one of these conditional fields – amount, balanceRate, transactionRate, accruedRate, and unfortunately none of these additional fields are applicable for these fees. (For example, Search fees or Govt Fees as these differ by state) Please provide guidance around which option mentioned below we should go with, in order to be compliant from a Rules and Data standards perspective. Use ‘variable’ feeType in version 2 and 3 – Guidance required on whether this feeType is acceptable in version 2 Use ‘variable’ feeType in version 3 and classify the same fee as another feeType in version 2 – Guidance will be required on value to be provided in one of these fields as none of them are applicable for this fee - amount, balanceRate, transactionRate, accruedRate, Use ‘variable’ feeType in version 3 and NOT provide/send this fee in version 2 Do not provide this variable fee type in both versions	-
199	Hoping to clarify this with Data61 around versioning of API/schemas - In V1.5.0 of the standards released on 16/9/20, a change was introduced to include occupationCodeVersion and industryCodeVersion into the CommonPerson and CommonOrganisation schemas respectively. However, the Get Customer API version remains unchanged at version 1 and so is the schema version. Would like to understand if this is correct? If yes, would like to get clarity on what type of change will warrant a change to the version of the API and/or schema.	-

Ticket #	Question	Answer
91	Is there a timeline for (banking) data holder's direct request service standards?	The Competition and Consumer (Consumer Data Right) Rules 2020 (CDR Rules) allow consumers to receive their own CDR data directly from a data holder in human readable form (see Part 3 of the CDR Rules). The ACCC has granted exemptions to the major ADIs, the non-primary brands of the major ADIs and non-major ADIs to defer the scheduled commencement date of direct-to-consumer obligations until 1 November 2021.
172	The CDR Rule 4.5: Data holder must ask eligible CDR consumer to authorise disclosure (1) This rule applies if: (a) a data holder receives a consumer data request under this Part; and (b) there is no current authorisation for the data holder to disclose the requested data to the person who made the request; and This sounds like it prohibits concurrent consent. Am I interpreting this incorrectly or is this in the pipeline to be updated..	Rule 4.5 requires DHs to have in place a current authorisation to disclose the requested CDR data to the person who made the request and sets out the process for doing that. If a DH receives a consumer data request from an ADR and the DH has a current authorisation in place to disclose the requested data to that ADR, the DH is not required to go through the process of asking the consumer to authorise disclosure to the ADR again. If the DH receives a consumer data request from that same ADR, but which is the subject of a new consent from the consumer, the DH will need to ask the consumer to authorise disclosure of that requested data to the ADR to the extent the request is not subject to a current authorisation. Due to the operation of the data standards, this may mean that in practice the consumer will need to authorise all requested data subject to the new consent.
174	If we have accounts that are singly owned but have another person as a signatory relationship to be able to transact (not a owner) on the account. Are we able to offer the ability to share this accounts data if the owner of the accounts requests?	The CDR Rules currently do not allow a secondary user or authorised user to share CDR data from an account of which they are not an owner. We are currently consulting on draft rules to broaden the scope of the current rules and permit anyone who: - has ‘account privileges’ in relation to the account holder’s account, as defined in each designated sector’s schedule, and - is approved by the account holder through a ‘secondary user instruction’ to share CDR data relating to the account with accredited persons. The proposed rules are intended to be flexible and recognise there are likely to be different types of secondary users between different sectors. For the banking sector, we consider someone with ‘account privileges’ should be someone who is: - an individual who is 18 years or older, and - able to transact on an account which is a phase 1, phase 2 or phase 3 product. Additionally the person with account privileges must be ‘eligible’ to ensure authentication is possible. That is, they must have access to an account with the data holder that is open and accessible online. More information about these proposed rules, our consultation process and how you can make a submission is available on the ACCC website: https://www.accc.gov.au/focus-areas/consumer-data-right-cdr-0/consultation-on-proposed-changes-to-the-cdr-rules
179	Would appreciate some guidance on whether InfoSec endpoints are in scope to be reported on as part of: 1. Metrics data in Get Metrics API. If so, should all InfoSec endpoints be considered as part of the High Priority tier? Related GitHub issue 299 2. Status information in Get Status API	Yes, InfoSec endpoints are covered under performance tiers (https://consumerdatastandardsaustralia.github.io/standards-staging/#performance-requirements). InfoSec would fall into High Priority. InfoSec also falls into status reporting. If the InfoSec endpoints are down this would impact the CDR solution so it would result in a PARTIAL_FAILURE.
183	I have seen the guide on "consumer access to copies of records". And I understand this rule is providing records in addition to the dashboard. I'm still wondering if there is a prescribed format in which the data must be produced to be provided to the consumer. From what I have seen the only condition is that it is readable "and in a form(if any) approved by the commissioner". I don't know what this form looks like? Are there CX guidelines, formatting rules, how must it be provided e.g. hard copy or email. Have you got templates ?	The ACCC has not prescribed a form for the purposes of rule 9.5(3) or (4) and has left the format for making a request and responding to a request open. However, we're open to feedback if participants believe there is a need for the ACCC to consider prescribing forms for the purposes of rule 9.5. If so, please send feedback to the ACCC's CDR mailbox at [email protected]
187	Will the cdr.gov.au website become the source of all information for CDR or do we still need to refer to the ACCC site?	The ACCC will always keep some CDR materials on accc.gov.au to meet certain reporting and archiving requirements, but the CDR website was developed to become a ‘one stop shop’ for all CDR stakeholders including participants and consumers. We are currently in a transition phase to move content from the ACCC website to cdr.gov.au and in the coming months cdr.gov.au will become the primary point for dissemination of CDR materials and content. We will continue to include all key materials and updates in the CDR newsletter, including links to relevant content on either accc.govau or cdr.gov.au throughout this transition period.
188	Could you please confirm if ID permanence is required for the following entity fields in the Scheduled Payments Schema? The standards do not advise to use ID permanence here, however in Accounts and Payee Schemas it advises to for these fields. scheduledbankingpaymentfrom - accountId bankingscheduledpaymentto - accountId	Yes these fields require ID Permanence to apply. They should be the same accountIds as associated with the consumer's consent.
-	when organisations apply for accrediation.... will there be a lead time?	An accreditation application may take approximately two months for assessment, and there is likely to be engagement with the accreditation team during that period. An applicant can minimise the time it takes to assess their application by: closely reading the guidelines, including the supplementary guidelines on insurance and information security providing a sufficient level of detail in response to all the questions in the accreditation application form (you can familiarise yourself with the questions in our sample online application). Some examples this are included in the ACCC’s CDR newsletter published on 26 August available here. ensuring you submit all requested documents responding promptly to any follow-up questions. For applicants eligible for streamlined accreditation the accreditation process should take no more than three weeks. The ACCC will continue to provide further updates on estimated timing of the accreditation process following the assessment of a larger number of accreditation applications. Once an accredited data recipient has completed accreditation, the ACCC On-boarding Team will be in contact to help initiate the on-boarding process, including enrolment in the Conformance Test Suite. Participants must meet the on-boarding requirements and pass the Conformance Test Suite before they receive an ‘active’ status on the Consumer Data Right Public Register.

• TBA

#	Question	Answer/ Action

Other business

• TBA

• TBA

• TBA