ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes | 22nd of June 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
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.24.0 published 7th of May 2023	Version 1.24.0 Change Log
Standards	Version 1.25.0	Due out in the next two weeks.
Maintenance	Iteration 15 concluded on 14th of June 2023	See the agenda
Maintenance	Iteration 16 to commence on the 12th of July 2023	Invitations have been sent out
TSY Newsletter	To subscribe to TSY Newsletter	Link here
DSB Newsletter	To subscribe to DSB Newsletter	Link here
TSY Newsletter	26th of May 2023	View in browser here
DSB Newsletter	16th of June 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	Decision Proposal 303 - Maintenance Iteration 15	Link to consultation
Consultation	Decision Proposal 306 - Updates to Banking Product and Account Detail	Feedback closes: 28th of July 2023 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
Video	Consumer Data Standards Guide Trailer	Link to video
Decision Made	Decision Proposal 288 Non-Functional Requirements Revision has had the decision made by the Data Standards Chair	Link to the Decision
Correction	Original Question: There are ongoing concession and then there are one off grants of different types in each state. These may have been applied to customers accounts within the requested period. If so, I understand that we just add it in the totals. But for get concessions, I am unsure what types of concessions are in scope? And if they are in scope, they would be considered variable I am guessing. Grants which are a one off payment but can appear once every X interval usually - URGS - VIC HEEAS - QLD EEPS - SA EAPA - NSW Family Energy Rebate - NSW QLD Asset Dividend - QLD Upcoming federal government relief - All states, but unsure as not announced? Original Answer: We've had similar question about once off concession/rebate being in scope. Following discussions with the ACCC Regulatory Guidance team, they have clarified the following: We confirm our preliminary view that once-off rebates or concessions are within scope. In accordance with sub clause 3.2(6) of Sch 4, this information would be required to be shared if it is requested, and the rebate (transaction or event) occurred within 2 years of the time the request is made. In terms of how this information is to be shared: - It should be shared via the concessions API with the same start and finish date that corresponds with the date that the rebate was made/credited to the account of the consumer	Updated advice: Below is the correction to the previous advise on how the once off concession should be shared. Following discussions with the ACCC Regulatory Guidance team, they have clarified the following: We confirm our preliminary view that once-off rebates or concessions are within scope. In accordance with sub clause 3.2(6) of Sch 4, this information would be required to be shared if it is requested, and the rebate (transaction or event) occurred within 2 years of the time the request is made. In terms of how this information is to be shared: - The concessions API is "point in time" API. It should return concession that are valid for a given account at the time of request. - For once off concessions/rebate that have already been applied (i.e. they are now historical), they should be shared via the billing or invoice API if the concession falls within the requested date range Apologies for the confusion. Please advise if you need any further clarification.
Obligation Date: Authorisation Code Flow (ACF)	10th of July 2023 FAPI 1.0 adoption is introduced across four phases. Phase 4: Retire Hybrid Flow: Data Holders MAY retire Hybrid Flow	We are actively encouraging ADRs to test their solution for ACF during the transition window and update their client registration to only use ACF before the July 10th obligation date that permits holders to retire Hybrid Flow. The transition window provides a safer path for ADRs to update their client software in a rolling fashion across all data holders whilst ensuring they have a fall-back mechanism if any given data holder has not correctly implemented ACF.
CDR Implementation Call	Changes for the next couple of months	Change of host

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	CTS & Register	Seamus
DSB	Consumer Experience	Michael
DSB	Technical Standards - Energy	Hemang
DSB	Technical Standards - Information Security & Banking	Mark
DSB	Technical Standards - Register	James
DSB	Technical Standards - Maintenance Iteration 15	Brian
DSB	Engineering	Sumaya

Presentation

None planned for 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
1902	Can you please assist with further details in regard to CDR Rules 2020, Division 1.4—General provisions relating to data holders and to accredited persons: 1.13 Consumer data request service (1) A data holder must provide: (a) an online service that: (i) can be used by eligible CDR consumers to make consumer data requests directly to the data holder; and (ii) allows a request to be made in a manner that is no less timely, efficient and convenient than any of the online services that are ordinarily used by customers of the data holder to deal with it; and (iii) enables requested data to be disclosed in human‑readable form; and iv) sets out any fees for disclosure of voluntary consumer data; and (v) conforms with the data standards; and (b) an online service that: (i) can be used by accredited persons to make consumer data requests, on behalf of eligible CDR consumers, to the data holder; and (ii) enables requested data to be disclosed in machine‑readable form; and (iii) conforms with the data standards. Note 1: See rule 3.3 for the meaning of “consumer data request” in relation to a request made by a CDR consumer directly to a data holder. Note 2: See rule 4.4 for the meaning of “consumer data request” in relation to a request made by an accredited person to a data holder on behalf of a CDR consumer. Note 3: This subrule is a civil penalty provision (see rule 9.8). (2) The service referred to in paragraph (1)(a) is the data holder’s direct request service. (3) The service referred to in paragraph (1)(b) is the data holder’s accredited person request service. (4) An accredited person does not contravene subrule (1) in relation to subparagraph (1)(a)(ii) so long as it takes reasonable steps to ensure that the online service complies with that subparagraph. Question: As a data holder we are required to enable 'direct data requests' (provide data to CDR consumer directly, in human readable format) >> are we are required to provide this service to secondary users and nominated representatives, or if only the account holder. 2. Authorisation to share data must be confirmed using an OTP >> please confirm if an OTP is also required when amending, editing authorisations to share data within the Consumer Dashboard?	Please see our comments below. Question 1 Part 3 of the Competition and Consumer (Consumer Data Right) Rules 2020 (CDR Rules) concerns consumer data requests made directly by eligible CDR consumers to data holders. Currently, Part 3 of the CDR Rules does not apply to the banking or energy sectors (see clauses 6.4 and 6.6 of Schedule 3 to the CDR Rules, and clause 8.5 of Schedule 4 to the CDR Rules). Therefore, data holders are not currently required to provide a direct request service under CDR Rule 1.13(1)(a). Question 2 Rules 4.5(2) and (3) provide that data holders must ask the CDR consumer on whose behalf a request was made to authorise the disclosure of CDR data in accordance with Division 4.4 and the data standards. Rule 4.22 (which forms part of Division 4.4) provides that a data holder’s processes for asking a CDR consumer to give or amend an authorisation must (among other things) accord with the data standards. We have received the following advice from the Data Standards Body: while the current data standards require data holders to authenticate CDR consumers with a one-time password before seeking an authorisation, a one-time password is not specifically required or prohibited when a consumer accesses the data holder's consumer dashboard for any reason. Authentication of the consumer dashboard is at the discretion of the data holder and is expected to align to the current practice of their existing digital channels. if an accredited person has initiated an authorisation amendment flow, the authentication flow is no different and as such requires a one-time password. the CX standards allow the amending authorisation flow to be simplified, but this does not occur within a data holder’s dashboard. authorisations are immutable, while accounts are dissociated. This means that a consumer cannot amend the datasets or duration for a specific authorisation, but could - if the data holder supports the functionality - add or pause sharing for accounts associated with the authorisation. We also note that rule 4.24 sets out restrictions for data holders when asking a CDR consumer to authorise the disclosure of CDR data or to amend a current authorisation (e.g. data holders cannot add any requirements to the authorisation process beyond those specified in the data standards and the CDR Rules).
1979	I want to access my banks' CDR APIs to aggregate by balances and transactions. 1) Do I need to get aggregated even for accessing my own data? 2) If I make a frontend-only app, I as a developer will not have access to anyone's data. The data will remain in the users phone, just for the duration of using the app. Is there an easier accreditation process for such a scenario?	An Accredited Data Recipient (ADR) can provide a service allowing eligible CDR consumers to access their CDR data, assuming appropriate authorisations have been provided. Direct to consumer data sharing is not currently permitted by the CDR Rules. However, r 7.5(1)(c) permits an accredited data recipient to disclose a CDR consumer’s CDR data, to the CDR consumer, if: 1. the disclosure is incidental to the provision of goods or services requested by the CDR consumer (for example, an ADR provides a budgeting service and sends a notification to a CDR consumer about their spending or other account related activity), or 2. the disclosure is the good or service requested by the CDR consumer. A list of providers accredited to offer services under Consumer Data Right (accredited data recipients), as well as the providers currently set up to share data (data holders), can be accessed here. If you want to provide services to consumers using CDR data, you will need to be accredited or become a CDR representative. The Accreditation Guidelines, accessible here, provide guidance on becoming an accredited person under the Consumer Data Right. More information about becoming a CDR representative is available here.
1999	Is it possible to query plans by postcode across multiple retailers? I’m not seeing any option to do so in the API docs, is there any way to query plans at a higher level as an API call per retailer to see what plans are available for a given location or NMI? The context is we have a platform for solar installers to provide system design and so the homeowner is giving their address, NMI and often a copy of their bill to help with a savings analysis. As electricity bills do not contain the PlanID, we are trying to make efficient the process of identifying and populating the plan rates, but also to show what other plans are available.	The APIs will provide raw data about list of plans (Get Generic Plans) or details for a specific plan (Get Generic Plan Detail). There are some filters you can apply in the request of Get Generic Plans API. Any further filtering you would have to do on your side once you get the data.
2000	We follow below method for calculating availability metrics as part of the metrics reporting. We consider requests to all banking, infosec, DCR endpoints with response codes 200, 201, 204, 302, 304, 400, 401, 403, 405, 406, 415, 422 & 429 as available response codes. For calculating availability we divide Count of available response codes/Total request count. My question is how to handle 404 error codes? The 404 error occurs when the requested resource is not found on the server. This may be due to the client providing an incorrect URL or the resource being removed. For example, in a get-account-details call if an invalid account ID is provided a 404 is thrown. In this scenario it does not show platform unavailability but user error. Do we need to 1. Exclude 404 from the list of available response codes (that is what we have implemented presently) 2. Include 404 in available response codes OR 3. Remove 404 from the availability calculation. That is remove it from both available response codes and total count and then calculate availability.	The availability is not dependent on requests, i.e. you should not be using requests to calculate availability. It is based on service availability and outages. If your system is down it would be considered as unavailable time regardless of receiving any requests or not. The below guidance article provides a formula to calculate availability: https://cdr-support.zendesk.com/hc/en-us/articles/6461435303823-CDR-metrics-and-reporting-by-Data-Holders#Availability
2002	Whether any conclusions have been made for Get Metrics V4 obligation requirements and the obligation due date? The previous CDR calls had mention of it getting added as Nov 13, 2023, obligation.	The decision for consultation 288 contains the final outcome for Get Metrics v4 and v5. You can find the decision document in this GitHub comment: https://github.com/ConsumerDataStandardsAustralia/standards/issues/288#issuecomment-1599976783 The obligation date for Get Metrics v4 was set to 1/11/2023 to align with the obligation date for the tranche 3 energy retailers.
2003	Is there any definition around the "upper limit" for number of accounts expected in the payload within the response times defined in the NFRs? For example, the "Get Bulk Billing" API allows a request of up to 24 months' of billing data for "all" accounts. For a C&I customer, "all" can be 1, 10, 100, 200+ accounts. The NFRs simply state that the DH is expected to respond within 6 secs to this API. Increasing the number of accounts will impact the ability to respond in the required response time. I expect that this will be worse with SR APIs (e.g. Get Bulk Usage-- requesting up to 24 months of meter data, for 10+ accounts, and expecting systems not to time out, never mind respond within the NFR response times). Can you please advise confirm the expectation here? Please note that the "5GWH eligibility" criteria described here (https://www.cdr.gov.au/resources/guides/eligibility-criteria-cdr-consumers-energy-sector) does not help alleviate this issue as the rule states that "if the customer has more than 1 account, and if 1 account is <5GWH, then all accounts are eligible"; i.e., it is MORE inclusive than exclusive.	There is nothing explicit in the NFRs but this situation is anticipated and has been dealt with in a couple of ways. One mechanism is the 1000 page size maximum set in the general pagination standards. Essentially, the 1000 record limit per page puts an upper bound on the size of any invocation regardless of the number of accounts. The other mechanism is the 95% compliance requirement for performance in the NFRs. This is an acknowledgement that there are sometimes corner cases that occur rarely that will exceed the thresholds.
2006	A data holder is required to report the average response time for each call in the Get Metrics endpoint, and this report will be broken out by tier. There is a difference in these tiers between "unattended" and "customer present". Our understanding is that an "unattended" API call is when the call is run by an automated script, while a "customer present" call is when a customer clicks a button on a data receipient's interface to initiate the call (for example, a customer manually refreshes their data). The question: how would a data holder recognize if a call is "unattended" versus "customer present"? A data recipient would need to include this in their API requests, but we can't see how based on the Standards	In regards to your query on customer present vs unattended API calls, please refer to the following article End points and APIs. The sub heading "Customer present and unattended calls" should assist you. Please note the article doesn't mention x-fapi-auth-date though, which is required for customer present calls, but not part of determining whether the customer is present.