ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes | 21st of July 2022

CDR Implementation Call Banner

Agenda & Meeting Notes

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

Agenda

Introductions
Actions
CDR Stream updates
Presentation
Q&A
Any other business

Introductions

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

Acknowledgement of Country

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.

House Keeping

Recording

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.

Community Guidelines

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.

Updates

Type	Topic	Update
Standards	Version 1.17.0 Published	Link to change log here
Standards	Version 1.18.0 to incorporate changes from Maintenance Iteration 11	Timing to be confirmed
Maintenance	Maintenance Iteration 12 - Has kicked off!	Agenda for 20th of July 2022
TSY Newsletter	To subscribe to TSY Newsletter	Link here
DSB Newsletter	To subscribe to DSB Newsletter	Link here
TSY Newsletter	1st of July 2022	View in browser here
DSB Newsletter	15th of July 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
Consultation	Decision Proposal 256 - Telco Endpoints Feedback closes: 5th of August 2022	Link to consultation
Consultation	Decision Proposal 257 - Customer Data Payloads for Telco Feedback closes: 5th of August 2022	Link to consultation
Noting Paper	Noting Paper 258 - Independent Information Security Review	Link to consultation
Workshop	DSB - Energy Sector: Historical Data Sharing - Workshop	Link to Registration: Eventbrite
Survey	We would like to hear from you: survey on CDR guidance needs The ACCC is working with the other CDR agencies to develop a cross-agency guidance strategy. This work recognises that there are currently different channels that CDR stakeholders use to ask guidance questions and find information. The high-level aim of the strategy is to ensure guidance is coordinated and consistent across CDR agencies.	Link to survey
Action	Question: If there is an SLA for availability	Answer: The CDR Sandbox will be supported during business hours. Any outages, during business hours, will be responded to as soon as the team is aware of the outage. Notification of an issue to the team will be provided via an automated alert or from a Sandbox Participant logging an issue. The time to resolve an outage will be dependent on the nature of the issue. There is no SLA at this stage. Providing an SLA will be re-evaluated depending on the usage and the uptake of the CDR Sandbox. However, there will be a heightened level of awareness and care given after go-live to bed in the system and the support processes needed.
Action	Question: How scheduled and unscheduled outages will be communicated	Answer: There is currently no automated external notification function within the CDR Sandbox. When and where to communicate the status of the CDR Sandbox is currently being assessed. Again, this will be re-evaluated depending on the usage and the uptake of the CDR Sandbox.
Action	Question: If there will be a status or health API provided that ensures availability of the component?	Answer: Dedicated health check APIs are currently only available internally for container orchestration. We will look into externally accessible health check APIs as a change for a future release. Once again, this will be re-evaluated depending on the usage and the uptake of the CDR Sandbox.

CDR Stream Updates

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	Amy Nussbaumer
DSB	Technical Standards - Energy	Hemang Rathod
DSB	Technical Standards - Register	Ivan Hosgood
DSB	Technical Standards - Banking	Mark Verstege
DSB	Technical Standards - Telecommunications	Brian Kirkpatrick
DSB	Technical Standards - Engineering & MI 12	James Bligh

Presentation

Title: CDR Test Documentation Presenter: Tomas Schier

Brief update on test documentation change (linking to Postman workspace)
Demonstrate the new public. DSB Postman workspace maintained in the GitHub dsb-postman repository
Introduce a technical implementation for some of the documented test cases
Demonstrate how these test cases can be run against a selected Postman environment, eg ACCC mock data holder

Q&A

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.

Answer provided

Ticket #	Question	Answer
793	Q2. Would there be scenarios (excluding technical) where required data properties would be empty or incorrect? Eg. missing or incomplete product data or a broken logoURI? If so is the data holder required to account for missing and/or incorrect data within the CX? Q3. Is or will there be a need to supply or expose DRSP numbers for a software product to consumers?	Q: Would there be scenarios (excluding technical) where required data properties would be empty or incorrect? Eg. missing or incomplete product data or a broken logoURI? If so is the data holder required to account for missing and/or incorrect data within the CX? A: This could happen. It is conceivable that a logo URI is correct one day and then the logo file is accidentally removed from a CMS so it is wrong the next. This should be an exception, however. Certainly the register is expected to provided schema compliant responses to API calls. The data holder is not required by the standards or rules to accommodate missing or incorrect required data about a software product in their dashboard or consent screens. Q: Is or will there be a need to supply or expose DRSP numbers for a software product to consumers? A: There is no requirement to display details about the software product to the consumer during authentication, authorisation, or in data holder dashboards. However, the CX Guidelines do suggest the software product name be displayed for transparency, traceability, and to aid authorisation management.
1328	The register standards initially include a requirement "Cache Refresh Metadata Request" https://consumerdatastandardsaustralia.github.io/register/#cache-refresh-metadata-request. To complement this requirement, the consumer data standards included API standard for metadata update. Ref: https://consumerdatastandardsaustralia.github.io/standards-archives/standards-1.12.0/#metadata-update It was later decided by the register team (ref Issue #53 GitHub Register) that it was not warranted and information note added to the Register standards. It appears when the CDR register and the Consumer Data Standards were merged in 1.13 release this context has been omitted. The requirement for Metadata Admin API is still retained in the Consumer Data Standards but the Cache Metadata Request dropped. Can you please confirm whether the Metadata Admin API intentionally retained or planned to be removed in the future? If it is intentionally retained what is the purpose of the API?	Yes, the metadata update API was deliberately retained and the DSB never indicated it would be removed. The issues you referred to were only applicable for the initial banking release in 2019 to reduce the implementation required on the register. The guidance around caching was removed when the standards transitioned because the DSB use the Zendesk portal for guidance. We try to keep this sort of content out of the standards themselves to avoid confusion as to what is guidance and what is obligated. This was discussed in the DP raised when the Register standards transitioned to the DSB.
1526	Where a request is sent for multiple NMI's in an AEMO API request (Get Service Points, Usage for Specific Service Points or Get DER for Specific Service Points), AEMO would not send data for any successful NMI's but would send the relevant error codes for invalid/incorrect NMI/s. With that said, should retailers intervene by either of the options of the below; 1. Identify and drop the erroneous NMI/s and resending the request for NMI's without error - fix data post the request. ADR would receive data for successful NMI's. 2. Fixing the exception internally or escalate to AEMO if a specific transaction not received from market. Would not be real time and errors would continue until internal systems aligned with the market. 3. Leave it to the ADR to amend request to eliminate NMI with error - unsure how possible this would be? • If 1. this might severely impact NFR's, would there be any lenience in respect to this occurring? or; • If 2. then this would also take time to allocate/update to fix/amend/escalate depending on error and how it is triaged. An example of error whereby a retailer would need to escalate to AEMO may be that error for Not Current FRMP but the retailer has yet to receive a transaction from AEMO to update systems. Therefore said retailer is not aware of the loss and may need intervention at AEMO to facilitate change. or; • if 3. this would be difficult especially that the error contains NMI only which an ADR may not be aware of as they are only receiving NMI on Get Service Points, no other API exposes the NMI.	The ADRs will be using servicePointIds in the API request which the retailers have to convert to relevant NMIs prior to calling AEMO endpoints. If there are errors resulting from the NMIs provided to AEMO, depending on the error, the retailer must either correct the issue and re-submit the request to AEMO or relay the error back to the ADR (for e.g. if the NMI is unavailable as it may have been disconnected). This is the expected behavior and is factored into the NFRs. Do note that the NFRs state 95% of calls per hour responded to within a nominated threshold. If the issue was with the servicePointIds in the original request , the DH would return an appropriate error code to the ADR and they would have to fix it and re-submit the request.
1571	Keen to understand if you have a CDR federation ecosystem diagram that includes AEMO APIs and touchpoints into the federation. There was an ecosystem diagram (Archived version), that was valuable on top of the live CDS website. Visual aids often help high level assessments for organisations.	We have been asked about the diagrams before, below is the summary of the response: We have produced diagrams at various points but, as the standards are legally binding, we have found that including diagrams directly in the standards can create ambiguity from an interpretation perspective We are aware that this does create problems with understanding the ecosystem (we've been told this before) and we seek to address this via our support portal. This is where we post clarification and guidance articles and field general questions. If you go there and search the articles you will find useful information that may assist We have been planning to develop an implementation guide as a companion to the CDR standards that would contain this content but we have not yet progressed to a point where we are ready to publish
1607	Earlier AEMO shared specification (attached) which has "X-initiatingParticipantId" parameter in all API request to be raised with AEMO. However, the CDS standards specification doesnt have this request parameter. Could we consider CDS specification has final and ignore this field? https://consumerdatastandardsaustralia.github.io/standards/#energy-secondary-dh-apis	The CDR standards consider AEMOs e-Hub platform and associated mechanisms a normative standard for the requesting of data from AEMO to fulfil Shared Responsibility Data Requests and have delegate the maintenance and clarification of implementation questions to AEMO. I believe the inclusion of X-initiatingParticipantId is one of the aspects which AEMO have specified as part of the e-Hub security profile requirement, which, I think this is an existing pattern for all APIs currently accessed via e-Hub. As a data holder, you would need to consume both the CDS and AEMOs CDR documentation collectively to implement CDR APIs.
1614	As per CDR rule, it says "if a non-disclosure option applies to the joint account, secondary users cannot authorise data sharing on the joint account.", - Does this mean that for secondary user consent, the data sharing stops even if the secondary user instruction is in place? - This account now becomes ineligible for consent authorisation for secondary users?	Rule 4A.5(1)(c) states that under the non-disclosure option, joint account data may not be disclosed even in response to a valid consumer data request. This means that secondary users are not able to authorise or share data for a joint account if the non-disclosure option is applied. For more information, please refer to our guidance on Joint accounts and Secondary users in the banking sector.
1620	Is there really still no public endpoint where we can get a complete list of all active PRD endpoints? - https://consumerdatastandardsaustralia.github.io/standards/#get-data-holder-brands requires authentication - https://github.com/ConsumerDataStandardsAustralia/banking-products-comparator/blob/master/public/datasources.json is out of date.	There wasn't but an end point has now been defined as of v1.17.0 of the standards. See: https://consumerdatastandardsaustralia.github.io/standards/#get-data-holder-brands-summary Unfortunately it hasn't been implemented yet. The ACCC are working on in preparation for energy go live.
1624	During last call it was mentioned that secondary user instruction and disclosure options are independent. This means if an account holder withdraws secondary instruction it will not impact disclosure option (pre-approval, non-disclosure) and vice versa. But in the Amendment rules under section " Secondary users of joint accounts From https://www.legislation.gov.au/Details/F2021L01392/Explanatory%20Statement/Text the following point is mentioned "If a non-disclosure option applies to the joint account, secondary users cannot authorise data sharing on the joint account." Does this mean non-disclosure of a joint account withdraws secondary user instruction and no data sharing is allowed for secondary users as well. Please clarify… Thanks	The withdrawal of secondary user instruction is independent of the non-disclosure option for joint accounts. An account holder must use the data holder’s online service to withdraw a secondary user instruction (see rule 1.13(1)(e) and rule 1.15(5)). This includes indicating on their consumer dashboard that they no longer approve CDR data relating to that account to be disclosed in response to a secondary user’s request (rule 4.6A). The non-disclosure option does not withdraw secondary user instruction. Once the non-disclosure option is applied, joint account data cannot be disclosed even in response to a valid consumer data request (rule 4A.5(1)(c)). This means that secondary user instructions remains but secondary users are not able to authorise or share data for a joint account. Data sharing stops because the non-disclosure option applies. If the pre-approval or co-approval options are applied afterwards, secondary users can continue authorising data sharing on the joint account providing a valid secondary user instruction remains in place. For more information, please refer to our guidance on Joint accounts and Secondary users in the banking sector.