ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes | 14th of September 2023

CDR Implementation Call Banner

Agenda & Meeting Notes

When: Weekly every Thursday at 3pm-4:30pm AEST
Location: Microsoft Teams
Meeting Details: Join on your computer, mobile app or room device Click here to join the meeting
Meeting ID: 446 019 435 001
Passcode: BU6uFg
Download Teams | Join on the web
Join with a video conferencing device
[email protected]
Video Conference ID: 133 133 341 4
Alternate VTC instructions Or call in (audio only)
+61 2 9161 1229,,715805177# Australia, Sydney Phone Conference ID: 715 805 177# Find a local number | Reset PIN
Learn More | Meeting options

Agenda

Introductions
Updates
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

⭐ indicates change from last week.

Type	Topic	Update
Standards	Version 1.26.0	Published: 24th August 2023 Change log
Maintenance ⭐	Maintenance Iteration 16	Minutes for all meetings
Maintenance ⭐	Iteration 17 to commence 20th September 2023	Invitations have been sent out. Email [email protected] to request an invitation
TSY Newsletter	To subscribe to TSY Newsletter	Link here
DSB Newsletter	To subscribe to DSB Newsletter	Link here
TSY Newsletter	1st September 2023	View in browser here
DSB Newsletter ⭐	8th September 2023	View in browser here
Consultation	Decision Proposal 229 - CDR Participant Representation	Placeholder: no close date Link to consultation
Consultation	Noting Paper 276 - Proposed v5 Rules & Standards Impacts	No Close Date Link to consultation
Consultation	Noting Paper 279 - Accessibility Improvement Plan	No Close Date Link to consultation
Consultation	Noting Paper 280: The CX of Authentication Uplift	No Close Date Link to consultation
Consultation	Noting Paper 307 - LCCD Consultation Approach	No Close Date Link to consultation Video
Consultation	Noting Paper 308 - Categories of Standards	No Close Date Link to consultation
Consultation	Decision Proposal 317 - ‘Buy Now, Pay Later’ Product and Account Detail	6 October 2023 Link to consultation
Consultation	Design Paper: Consumer Data Right Consent Review	6 October 2023 Link to consultation
Consultation	Noting Paper 323 - NFR Workshops	Link to consultation

CDR Stream Updates

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

Organisation	Stream	Member
ACCC	Register and Accreditation Application Platform	Eva
ACCC	Conformance Test Suite	Callina
ACCC	Compliance	Seamus
DSB	Consumer Experience	Michael
DSB	Technical Standards - Register	James

Presentation

None this week.

Q&A

Questions on Notice

Questions will be received by the community via Microsoft Teams 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
2052	Are data holders required to show data access history in consumer dashboard? It's not included in any non-normative examples and I couldn't find a clear guide for it. Only Rule 9.3 states such audit records(disclosure of CDR data by data requests) are required to be kept, and Rule 9.5 states consumers shall be able to ask for a copy for them.	Q: Are data holders required to show data access history in consumer dashboard? A: Rule 7.9, which relates to Privacy Safeguard 10 (PS10), requires DHs to display 'when the CDR data was disclosed' on the dashboard. The CX Guidelines for DH Dashboards provide PS10 examples (see here, including the annotations on the second last screen in the flow). The OAIC has a guide on what this should include (see here, particularly 10.35 onwards), which provides a partial history of data access. Otherwise, we are aware of some DHs providing a complete data access history that can be accessed on the dashboard itself, as well as allowing records to be requested from the dashboard, and also providing instructions on the dashboard for how to request records. We are not aware of any rules requiring DHs to do these things to comply with rule 9.5. However, rule 1.14(3A) requires ADRs to provide a statement on the dashboard that the consumer is entitled to request further records in accordance with rule 9.5, as well as instructions for how to make that request. As such, a DH who may consider becoming an ADR in the future will be required to do this anyway, so may wish to implement this functionality voluntarily in their role as a DH, which in the DSB's opinion it would be good practice for a DHs to do regardless.
2077	I'm trying to access all of the energy plans in australia, as outlined in the following documentation: https://consumerdatastandardsaustralia.github.io/standards/#energy-apis However there doesn't appear to be a list of all of the data holders hostnames anywhere, so although I know how the data should be requested and returned, I have no idea where to obtain it. How/where can I find such?	To view the Product Reference Data for Energy. Please see the Australian Energy Regulator: https://www.aer.gov.au/consumers/energy-product-reference-data Please note the URIs are the base; you will need to follow the URI structure: https://consumerdatastandardsaustralia.github.io/standards/#uri-structure
2086	I just wanted to clarify 2 scenarios for an OPEN energy account and the endpoint GET /energy/accounts/{accountId} 1. The customers stays on the same plan but controlled load rates, solar feed in and tariffs rates are all increased/decreased (for example, due to EOFY increases). The expected result is that there is 1 record in the "plans" array but "controlledLoad", "solarFeedInTariff" and "tariffPeriod" would all have 2 records the array? (1 for the old rate and 1 for new rate) 2. Customer changes plan 3 times in the last 2 years. The expected result would be the "plan" array has 3 records?	Question 1. The customers stays on the same plan but controlled load rates, solar feed in and tariffs rates are all increased/decreased (for example, due to EOFY increases). Answer 1: For an open account and the same plan, the rates should be the most current as part of the plan. The assumption here is that the changing of rates is part of the current plant/contract (i.e. plan is not for fixed rates) and a new plan is not being setup when the rates have changed. In that case old rates do not need to be provided. Question 2. Customer changes plan 3 times in the last 2 years. Your understanding here is correct, the expectation would be 3 plan entries/records in the response
2088	Based on attached AMEO doc point 1 - Current FRMP must update/populate LCCD with-in 5 business days of becoming aware that 1) An Account Holder has started or ended at premises. From C&I perspective - Customers have contract obligations and notice periods, and we won't final bill until: o Contract ends. o Site disconnected. o Site abolished. o Another entity accepts responsibility for the site supply. o The site transfers to another Retailer ( LCCD not applicable, as Origin is no longer FRMP) In scenarios - IF there is gap between customer move out and move in i.e customer moves out prior to their contract period end date ( the outgoing customer held accountable is held to contract terms per their notice period ) Question - What is the expectation in this scenario ? Can current FRMP populate LCCD post contract end dated/ NMI final billed Note - AEMO recommend to seek clarity from the Data Standards Body about the scenario	I'm afraid these questions are outside of the scope of the CDR. These are MSATS related questions that need to go to AEMO.
2093	Just after a bit of clarification on how many digits are required after decimal point for the data type - Number? We couldn't find any reference in data standards and Zendesk regarding this, We've found for data types such as RateString, AmountString, following rules are added in standards. "At least 1 and up to a total of 16 significant digits before decimal point & up to 16 digits following the decimal point." Is this rule the same for data type - Number?	The Number format is a standard JSON number. There are no requirements for leading or trailing decimal digits. The format itself is defined more fully in the normative standard for the JSON format (https://datatracker.ietf.org/doc/html/rfc8259). See section 6.
2095	The CDS standard does not give clear guidance on the interpretation of the `purpose` enumeration of the `CommonPhysicalAddressWithPurpose` schema. Preferably, each enumerated value should include some example scenarios where that type should be used. I would also specifically like to answer these questions: - For an individual customer, should the primary residential address be transmitted as "REGISTERED" or "PHYSICAL"? - In what scenarios should "PHYSICAL" be preferred over "OTHER", and vice-versa	When we originally consulted on the address format there was no common understanding amongst banks as to the specific interpretation of the various enumeration values (although there was often general agreement). As such we have refrained from being specific and left this to data holder discretion to align to their pre-existing internal understanding. Regarding your specific questions: Q: For an individual customer, should the primary residential address be transmitted as "REGISTERED" or "PHYSICAL"? A: For the address that the bank treats as the primary the enum REGISTERED would likely be preferred. This is why there is a stipulation for only one address to have the type REGISTERED. PHYSICAL was included to support secondary addresses that represent an actual premise (as opposed to a PO Box for instance) Q: In what scenarios should "PHYSICAL" be preferred over "OTHER", and vice-versa A: PHYSICAL would always be preferred ahead of OTHER as it is more specific. OTHER was provided for corner cases or where the actual type of address was unknown. This would apply, for instance, to an address that can't be validated by the AusPost PAF file, or some other address service like Google. It could also be used for international addresses that are difficult to validate.
2096	Can you please provide answers to these questions: 1. Are Self Managed Super Fund residential mortgages in scope of the CDR PRD? 2. If so, how do the Data Standards require dataholders to show whether or not a product is suitable for a SMSF, in the PRD data ? How does a user of the PRD successfully identify whether any given product is, or is not, able to be used by a SMSF for the purchase of residential property?	All residential mortgages are in scope for the CDR as far as I am aware regardless of the customer type or purchase arrangements. The PRD currently doesn't have eligibility or constraints around whether a mortgage product can be obtained via an SMSF but a CR to include this would be welcome and would be considered for MI consultation.
2097	Reported alleged compliance issue	We appreciate the information provided regarding your customers’ experience sharing data with initial retailers. We have passed the information provided on to the ACCC Compliance Team, who may be in touch if they require any further information. Service Management Portal access is currently only available to Accredited Persons. If you wish to raise issues with data holders for resolution, please provide relevant information to your CDR Principal, and request that they raise an incident on your behalf. The ACCC monitors the Service Management Portal and will assist to escalate issues where required. We’re always considering improvements to the Service Management Portal. If you have particular feedback you’d like to give in this regard, or wish to discuss this matter please contact [email protected].
2098	Just wondering supporting two API versions for a transitional period is once off (for example, supporting get energy account v2 until sept next year), or is it re-occurring, that we will always of transitional periods for API versions?	Yes. There are always exceptions but, in general, we will always have transitional periods when new endpoint versions are defined where the old and new endpoints need to be supported in parallel. There have already been periods of time when three separate versions were all obligated at the same time for data holders. This is to prevent the need to coordinate all participants to upgrade versions on the same day which would make the CDR brittle and is why we have included both the x-v and x-min-v headers. This also aligned to one of our design principles that are included in the standards: Technical Principle 7: APIs are version controlled and backwards compatible As the API definitions evolve care will be taken to ensure the operation of existing clients are protected when breaking changes occur. Breaking changes will be protected by a well-defined version control model and by a policy of maintaining previous versions for a period of time to allow for backwards compatibility.