ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes | 3rd of November 2022

CDR Implementation Call Banner

Agenda & Meeting Notes

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

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.19.0 Published on 13th of September 2022	Link to change log here
Standards	Version 1.20.0 is being staged	View the branch here
Maintenance	Maintenance Iteration 12	Last met on 14th of September 2022 Agenda for the Final meeting here
Maintenance	Decision Proposal 259 - Maintenance Iteration 12	Changes, meeting notes and updates for the iteration can be found here
Maintenance	Maintenance Iteration 13 underway	Met 26th of October 2022 and the agenda for the meet is here)
Maintenance	Decision Proposal 272 - Maintenance Iteration 13	Changes, meeting notes and updates for the iteration can be found here
TSY Newsletter	To subscribe to TSY Newsletter	Link here
DSB Newsletter	To subscribe to DSB Newsletter	Link here
TSY Newsletter	28th of September 2022	View in browser here
DSB Newsletter	28th of October 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
Noting Paper	Noting Paper 258 - Independent Information Security Review	Link to consultation
Consultation	Decision Proposal 267- CX Standards Telco Data Language Feedback closed: 15th of September 2022 Thanks to those who provided feedback on DP267 by 15th September. With the v5 rules out for consultation, the DSB will leave this issue open for comments while considering existing feedback and developing version 2 of DP267, which is expected to be published for consultation in October.	Link to consultation
Survey	The Data Standards Body invite the CDR Community to provide feedback on the different Engineering Tools and platforms.	Link to survey
Webex	Plan to switch over to Microsoft Teams by early November 2022	Invitations to be updated tonight with Teams dial in options.
Guidance	The ACCC has published new guidance on the De-identification of CDR data under the Consumer Data Right which outlines the obligations of ADRs in relation to the treatment of de-identified and redundant data under the Rules and the Act.	Can be found here
Questions and Answers	The DSB have rotated who is the primary/secondary on each Domain. Please the following for the updated allocation: Sectors Banking - Nils/Hemang Energy - Hemang/James Telco - Brian/Hemang Customer - James/Hemang Structural Information Security - Mark/Brian, Hemang Register - James/Mark Operational - James/Nils Emerging Action Initiation - Mark/James Non-bank Lending - Nils/Hemang
Workshop	Save the date, for a workshop! Treasury and the DSB are considering opportunities to simplify the rules and standards to support a better CDR consumer experience while maintaining key consumer protections. To support this work, a virtual workshop will be held on Tuesday 22nd November, and an accompanying noting paper will be available on GitHub (see Noting Paper 273). This workshop will be of interest to current and prospective data recipients, data holders, consumer advocates, industry representatives, and other parties interested in the evolution of the consent model. Participants will be given the opportunity to comment on possible consent model changes in an interactive session. This workshop will be conducted virtually using Miro to support remote participation. We encourage stakeholders to save the date and ensure they can access the Miro platform on the day.	Register here for the workshop.

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	Michael Palmyre
DSB	Technical Standards - Energy	Hemang Rathod
DSB	Technical Standards - Telecommunications	Brian Kirkpatrick
DSB	Technical Standards - Engineering & Register	James Bligh

Presentation

The results of the CDR Implementation Call 2022 - 2023 survey

Thank you to everyone who voted on the preferred dates. Below is the outcome from the CDR Community!

20221031_cdrimpcall_20222023results

Maintenance Iteration 13 Issues

All open change requests can be found here: Standards Maintenance Issues.

The standards maintenance backlog can be found here: Data Standards Maintenance

The change requests proposed for this iteration are:

InfoSec

Energy

Banking

Issue #513: Specify if an Account is a joint account in the API response

Register

Iteration 13 Holistic Feedback

Issue #551: Iteration 13 Holistic Feedback

Q&A

Questions on Notice

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
1747	This is very interesting as it effectively means that for a given month, an ADR can only reliably use the getStatus API 99.5% of the time to determine if the DHB is not experiencing an unplanned outage, and during a planned outage, all bets are off. Because if these endpoints are part of the planned outage, the DHB is not expected to publish an estimate of when the service will be restored.	I think it would be safe to assume that, if the status API is unreachable, the data holder is down
1752	V3 of Get Data recipients has enumerated values of industry expanded to include 'banking',', energy', 'telco' and 'all'. If a DH invokes the API with industry value 'all', will register return all data recipients belonging to 'banking', 'energy' and ' telco' or will it only return DR who have registered them selves as supporting 'all' industry'. My understanding is that if a software product of a DR can support all industries, they will register themselves with industry value 'all', instead of creating 3 entries of one each for 'banking', 'energy' and 'telco'. Is that right? If it help in understanding the context, as of today banking data holder currently invokes GET https:///cdr-register/v1/{industry}/data-recipients/status with {industry}='banking' . Post 15th Nov when Industry values are expanded to 'banking', 'energy', 'telco'' and 'all', will banking data holder need to continue to invoke the API in same fashion or will they have to invoke twice , once with industry 'banking' and second time with industry 'all' so that data holder don't miss out on data recipient who registered themselves with industry 'all'. or other way to ask the question is will a Ddata recipient ever register their software product with industry value 'all' or it can only be one of 'banking', 'energy','telco'. Just adding my comments from implementation call to give you more context. When data recipient invokes GET /cdr-register/v1/{industry}/data-recipients/brands/{dataRecipientBrandId}/software-products/{softwareProductId}/ssa , in what scenario will they invoke this with industry value 'all'? I am also assuming that data recipient brand ID is unique.	Currently, I believe the industry filter actually does nothing, although it is intended that it should allow the filtering of recipients that are involved in certain industries as the regime expands and the number of ADRs increases. The intention of the standards is that the 'all' value means that all sectors should be included in the response. It should not be interpreted as limiting the response only to recipients that support all sectors. This is consistent with the usage of 'all' in query parameters elsewhere in the standards (such as filtering on open/closed accounts).
1760	Regarding EnergyPlanTariffPeriod segment (https://consumerdatastandardsaustralia.github.io/standards/#schemacdr-energy-apienergyplantariffperiod)of GET ENERGY ACCOUNT DETAIL api : the Start/end dates fields states that these are dates of the tariff period in a calendar year. Seeking clarification on interpretation i.e. Is the intent of this tariff period & details is to populate all Tariff (Price) changes and seasonal tariffs that are applied/ occurred for that customer within the calendar year? Scn1: Customer is on a PEAK tariff (say 20 cent/kWh) & midyear (01/07/2022) the PEAK price changes from 20 to 21 cent/kWh, due regulatory price change (but customers product is still the same). In this example we require to populate tariff period split as 01-01 to 06-30 for 20 cent and 07-01 – 12-31 for 21 cent in the calendar year due to price change? Scn2: Customer is on Seasonal PEAK tariff (let’s say 20 cent/kWh during winter months & 18 cents/kWh during summer months). The summer period defined as Jan to March and remaining period is winter price. In this example we need to populate tariff period split as 01-01 to 03-31 for summer PEAK price & 04-01 – 12-31 for winter PEAK?	Question: Seeking clarification on interpretation i.e. Is the intent of this tariff period & details is to populate all Tariff (Price) changes and seasonal tariffs that are applied/ occurred for that customer within the calendar year? Scn1: Customer is on a PEAK tariff (say 20 cent/kWh) & midyear (01/07/2022) the PEAK price changes from 20 to 21 cent/kWh, due regulatory price change (but customers product is still the same). In this example we require to populate tariff period split as 01-01 to 06-30 for 20 cent and 07-01 – 12-31 for 21 cent in the calendar year due to price change? DSB Answer: The view is that the structure should contain the current price (to accommodate comparison). If data holders do wish to accurately reflect changes over time it can be accommodated as the plan is an array so the new prices can be captured as a new plan entry. Question: Scn2: Customer is on Seasonal PEAK tariff (let’s say 20 cent/kWh during winter months & 18 cents/kWh during summer months). The summer period defined as Jan to March and remaining period is winter price. In this example we need to populate tariff period split as 01-01 to 03-31 for summer PEAK price & 04-01 – 12-31 for winter PEAK? DSB Answer: As long as the periods do not overlap, the representation is up to the data holder. The representation in your above example is correct as the periods do not overlap.
1768	Government rebates are posted as payments / grants (just the posting date is available and rebates generally gets reset every calendar year) therefore there is no specific start date & end date for the rebates like other concessions that is stored in our data base for rebates. Query: Seeking clarification that are we in line with the DSB obligations, if for these Government rebates we pass the fields ‘startDate’ & ‘endDate’ as ‘blank’ value in the response for EnergyConcession API to avoid any dates inconsistencies for these rebates?	The `startDate` and `endDate` in EnergyConcession are optional fields so you simply would not include them in scenarios where the concession/rebate are not time bound.
1775	Based on the availability requirements (non-functional requirements), we should log a scheduled outage with at least a week notice. "The availability requirement does not include planned outages. Planned outages should be: Commensurate in length and frequency to other primary digital channels offered by the data holder, Published to Data Recipient Software Products with at least one week lead time for normal outages, May occur without notification if the change is to resolve a critical service or security issue." In some instances, we may have outages planned with less than 7 days notice. If we log a scheduled outage with less than 7 days notice, would this normally impact the availability metrics?	Yes, if the planned outage is not advertised with the stated notice period then the outage period should be included in the availability metrics reported to the regulator. The purpose of this period is to provide enough time for ADRs to reschedule any batch operations or to put in appropriate consumer messaging as data will not be available.
1779	We are working on the Trusted Advisor build at our end and are looking to seek collection, use and disclosure consent together at only one time as specified in the consolidated CX mockup version - 1CO3-Trusted Advisor Disclosure Consent v1.16.1.2022.04.06 where its has been shown that one could combine the consent request for collection, use and disclosure as " Do you consent to us collecting, using and sharing your data?" -- in order to reduce number of clicks for the consumer and minimize duplication of certain information. Attaching the snap shot from the CX Mock up for the reference. Wanted to confirm that it does not overlap or violate the CDR rule 02 described above on the same disclosure consent guideline page where it states that : (4) The accredited person must not make: (a) the nomination of a trusted adviser; or (b) the nomination of a particular person as a trusted adviser; or (c) the giving of a TA disclosure consent; a condition for supply of the goods or services requested by the CDR consumer.?? Please help confirm.	The CX team worked on those guidelines with other CDR agencies to demonstrate an acceptable implementation example, including with respect to the rule you have referenced. The v5 rules that were recently published for consultation include the following clarification to resolve the ambiguity around how this might be implemented: (5) To avoid doubt, paragraphs (4)(a) and (c) do not apply where the only service that is requested by the CDR consumer is for CDR data to be collected from a data holder and provided to a trusted adviser. N.B. The Minister is yet to consider and/or make the above rule amendment, but the inclusion of this rule is to clarify that the ADR may implement the TA disclosure flow as per the CX guidelines.
633	Could you please provide further guidance on the below aspects of Privacy Safeguard 11 and 13 and their interplay with Rules 7.10 and 7.15. 1. Does a customer need to specifically request for their “CDR data” (and not just data) to be updated for it to be considered a correction request? 2. Are corrections to CDR Data that is held by a Data Holder but is yet to be shared to any accredited persons in scope for data corrections? 3. When we provide a customer with a written notice in response to a correction request or a change in data quality, does this written notice need to persist? If we provide this through an update to the Consumer Dashboard, can we remove this once the customer has viewed it once? Can we overwrite it if a new grouping of CDR data is corrected? 4. Can you please provide further clarity on the qualifying consideration that correct CDR data is up-to-date. How does this affect CDR data that is expected to change as part of the normal product and account lifecycle (e.g. status, credit balance changes)? To provide further clarity, could you please provide guidance on the below scenarios and outline which privacy safeguards will be triggered. - A customer calls our contact centre and requests us to update the address that they live at. They are not currently sharing this data under CDR. - A customer changes the account nickname for an account that they are sharing CDR data on with an ADR in our mobile banking application. - A customer pays down their loan balance but the account remains open. The previous loan balance has been shared with an ADR.	Thank you for your enquiry and apologies for our delayed response. We have provided inline responses to your questions below. Question 1. Does a customer need to specifically request for their “CDR data” (and not just data) to be updated for it to be considered a correction request? Answer: Privacy Safeguard 13 does not stipulate formal requirements that a consumer must follow to make a correction request, or require the consumer to state that they are making a ‘CDR data’ or ‘Privacy Safeguard 13’ request. However, Privacy Safeguard 13 only applies where a consumer has requested that a data holder correct their CDR data and the data holder was earlier required or authorised to disclose it under the CDR rules. Otherwise, APP 13 will apply to a correction request where data has not previously been disclosed under the CDR rules. We note that Privacy Safeguard 1 requires a data holder to state in its CDR policy how a consumer can correct their CDR data (see s56ED(1)(4)(a) of the Act). This should include information about: how a consumer may seek correction under Privacy Safeguard 13 (which applies once the data holder has previously been required or authorised to disclose the CDR data under the CDR system), and how a consumer may seek correction of their CDR data that is also personal information under Australian Privacy Principle (APP) 13 (which applies to the correction of CDR data in all other circumstances, including where the CDR data has not previously been disclosed). Question 2. Are corrections to CDR Data that is held by a Data Holder but is yet to be shared to any accredited persons in scope for data corrections? Answer: As mentioned in question 1 above, the correction requests under Privacy Safeguard 13 only applies when a consumer has requested that a data holder correct their CDR data and the data holder was earlier required or authorised to disclose it under the CDR rules. For information about Privacy Safeguard 13 (including when a data holder needs to comply with Privacy Safeguard 13 or APP 13), see Chapter 13 of the OAIC’s Privacy Safeguard Guidelines. Question 3. When we provide a customer with a written notice in response to a correction request or a change in data quality, does this written notice need to persist? If we provide this through an update to the Consumer Dashboard, can we remove this once the customer has viewed it once? Can we overwrite it if a new grouping of CDR data is corrected? Answer: Rules 7.10 and 7.15 specify that notices in relation to correction requests for Privacy Safeguards 11 and 13 must be given by electronic means. This notice can (but does need to) be given via the consumer dashboard. The Rules do not specify any requirement for the notice to persist for a specific length of time but we consider it best practice to allow the consumer to remove this notice themselves. However, if a data holder wishes to remove the notice from the consumer dashboard (or another electronic notification system), we recommend advising the consumer in advance, specifying the timeframe or date the notice will be removed. This will provide the consumer with an opportunity to save their own copy of the notice. Question 4. Can you please provide further clarity on the qualifying consideration that correct CDR data is up-to-date. How does this affect CDR data that is expected to change as part of the normal product and account lifecycle (e.g. status, credit balance changes)? Answer: Privacy Safeguard 11 requires data holders to take reasonable steps to ensure that CDR data is, having regard to the purpose for which it is held, accurate, up to date and complete. Privacy Safeguard 13 requires that any qualifying statement included with CDR data in response to a correction request, having regard to the purpose for which it is held, ensures that the CDR data is accurate, up to date, complete and not misleading. The meaning of ‘up to date’ (as well as the other quality and correction considerations including ‘accurate’, ‘complete’ and ‘not misleading’) is discussed in Chapters 11 and 13 of OAIC’s Privacy Safeguard Guidelines. CDR data is not up to date if it contains information that is no longer current. We note that CDR data about a past event may have been up to date at the time it was recorded but may have been overtaken by a later development. Whether that data is up to date will depend on the purpose for which it is held. If, for instance, a consumer has had their second child but their CDR data records them as only having one child, the CDR data will still be up to date if the data that records the consumer as having one child is held simply for the purpose of recording whether the consumer is a parent. CDR data may not be up to date even if it is consistent with a consumer’s instructions or if the inaccuracy is attributable to the consumer. To provide further clarity, could you please provide guidance on the below scenarios and outline which privacy safeguards will be triggered. Question: A customer calls our contact centre and requests us to update the address that they live at. They are not currently sharing this data under CDR. Answer: As the data holder has not yet disclosed the CDR data under the rules, Privacy Safeguard 13 would not apply to this scenario. However, the data holder would be required to take reasonable steps to correct the CDR data under APP 13. Question: A customer changes the account nickname for an account that they are sharing CDR data on with an ADR in our mobile banking application. Answer: Under Privacy Safeguard 11, the data holder must take reasonable steps to ensure that the CDR data is, having regard to the purpose for which it is held, accurate, up to date and complete. This means that any future discloses of that CDR data to an accredited data recipient must include the new account nickname (if that specific type of information is to be shared with the ADR). However, for any previous disclosures of that account nickname to the accredited data recipient, PS 11 does not require the data holder to ask the consumer if they want to provide the new data if the account nickname was accurate, up to date and complete for the purpose for which it was held at the time of disclosure. Question: A customer pays down their loan balance but the account remains open. The previous loan balance has been shared with an ADR. Answer: Under Privacy Safeguard 11, the data holder must take reasonable steps to ensure that the CDR data (including information about a loan balance) that is disclosed to an accredited data recipient, is accurate, up to date and complete for the purpose for which it is held. This means any future discloses of that CDR data to an accredited data recipient must include the updated loan balance. However, for any previous disclosures of that loan balance to the accredited data recipient, the data holder does not need to ask the consumer if they want to provide the updated loan balance, provided it was accurate, up to date and complete for the purpose for which it was held at the time of disclosure. Please refer to chapter 11 and chapter 13 of the OAIC’s Privacy Safeguard Guidelines for more information on Privacy Safeguards 11 and 13.
1773	Secondary User - Back to Ceasing of Sec user, one of the key points stated "This indication applies to the accredited person legal entity and all of its brands and software products." so… would it be similar to that Westpac / St George subject above where it's expected to block all of them? Yes, basically, the users see the software product names that the data is being shared to. They aren't provided with the ADR legal entity. so say for if the restriction is placed by the account owner against : ADR-X , - Brand ABC - Software ABC, - Software ABD, - Brand EFG - Software EFG - Software EFH - Software EFI (restriction placed against this software) It should block the entirety of the ADR-X and all the other brands and software altogether. Am I right in the understanding of that key point?	As provided in the Ceasing Secondary User Sharing, the reference to a particular accredited person refers to the relevant accredited legal entity, rather than a specific software product or brand of the legal entity. As such, where an account holder makes the relevant indication under rule 4.6A(a)(ii) the ‘block’ would apply to all of the brands of the legal entity if they are not separate legal entities and so your understanding of the outcome in your example in relation to ADR-X is correct. As noted in your other ticket, the ACCC has now provided correspondence to all data holders in respect of this issue. The purpose of this correspondence is to ascertain data holders’ approaches to implementing this functionality to reduce uncertainty for consumers and ADRs and to provide detail and certainty in relation to our compliance approach. We also note that the DSB, Treasury and the ACCC are actively working to address stakeholder concerns about this functionality, and Treasury is considering possible rule changes. We encourage DHs and ADRs to email the Treasury at [email protected] with their concerns. Stakeholders may consider including any risks they believe will be created due to rule 1.15(5)(b)(i) and 4.6A(a)(ii); any concerns relating to implementation timeframes and compliance; and suggestions they believe may help address any issues they have identified.
1778	I note that the https://cdr-support.zendesk.com/hc/en-us/articles/5465006047375 article for Ceasing Secondary User Sharing and the CDR rule 4.6A made no mention of notification required to account owner(s), nor secondary users when actions have been taken by an account owner to restrict ADR from data access on the account. I believe that the CDR rule 4.28 would not be relevant as it's not an amendment, withdrawal, or expiry to the authorisation given by the secondary user. Therefore when the ADR is ceased from accessing the data on the account (through account owner's indication/action), no notification is required by the rules or standards. i.e. the decision to notify customers is up to the DH to implement in this case. Can you please confirm?	Thank you for your query. Your position is correct that there are no notification requirements in the Rules that apply when an account holder indicates that they no longer approve of CDR data from their account being disclosed to a particular accredited person in response to a consumer data request made by a particular secondary user. As you have identified rule 4.28 only applies where an accredited person makes a consumer data request on behalf of a secondary user for a particular account and/or the secondary user amends or withdraws an authorisation, or an authorisation given by the secondary user expires. A data holder is not prevented from providing a notification under the Rules and so it is up to the data holder to determine if they will provide any notifications.
1786	New software or brands introduced by the ADR after the ADR is already blocked by an account ower (for a specific sec user) will be expected to be blocked altogether automatically?	Thank you for your query. We would expect that where an indication is in place in relation to an ADR under 4.6A(a)(ii) a secondary user would be prevented from sharing data from the relevant account to new software or brands that are introduced by the ADR, assuming they are registered under the same legal entity.
1787	I read that the article mentioned no reversal is required as part of the rule, can you confirm the below understanding are correct in this case? 1. Expecting that the removal of the “Secondary user instruction” would not change / reset or reverse the ADR blocking for the sec user? 2. Expecting that a change in ownership (Joint) would not change / reset or reverse the ADR blocking for the sec user?	The rules do not require a data holder to provide a functionality to ‘unblock’ the indication an account holder gives under rule 4.6A(a)(ii). We do not consider that the removal of a secondary user instruction would ‘unblock’ or reverse this indication. This is because these functions are separate. Similarly, a change in ownership for a joint account would not reset or reverse the ADR blocking for the secondary user.