Key Phase Dates

Phase 1: Retrospective and Backlog Grooming - 9th July 2020 commencement. 2 weeks duration

Phase 2: Consultation - 22nd July 2020 commencement. 4 weeks duration

Phase 3: Approvals and Documentation - 19th August 2020 commencement. 2 week duration

Please contact [email protected] for an invite to the series

Energy Rules Framework workshop
The ACCC will host an online workshop to consult on the energy rules framework, which was released on 8 July.

• ASAE 3402 Assurance Reports on Controls at a Service Organisation
• the International Standard on Assurance Engagements (ISAE) 3000 series
• SOC1/SOC2 reports prepared in accordance with applicable Statement on Standards for Attestation Engagements (SSAE) standards.

I am reaching out in regard to question raised during today CDR call on sharing CDR Register production URL for the following endpoints :

We have a question in regards to the re-authorisation process. In the latest version of CDS and CX guidelines we couldn’t really find anything related to it (https://consumerdatastandards.gov.au/standards/latestversion/)

However we found a Data61 prototype (both re-authorise via data recipient and data holder) below that was created a while ago:
http://559gwh.axshare.com/#g=1&p=reauthorise_via_holder

• ACCC, when re-authorisation process on the data holder side is to be delivered?
• Data61, in case of a re-authorisation initiated on the data holder side, I assume that the data recipient needs to be informed about it. Do we currently have a CDR endpoint similar to the withdrawal process as part of the data holder Dashboard?

We are seeking clarification on the definition of a ‘pre-registered payee’ that should be returned from the Get Payees and Get Payee Detail API endpoints.

Is it correct to assume this is limited to payees/billers stored within a customer’s address book? That is, excluding any payees not saved in the address book, including payees where a customer may have made an ad hoc or recurring payment?

ANZ is looking for some clarity around log retention requirements. Based on the rules section 9.3 (1)(e) and 9.3 (3) highlighted below a data holder would be required to keep logs of instances where CDR data has not been disclosed in reliance of an exemption from the obligation to disclose for 6 years.

As we understand it this exemption would include where we protect our system from malicious behaviour or high volumes (aligned to the NFRs) which would risk our platforms. Given these controls are generally performed at the first entry point to a data holder like a web application firewall (WAF) the data within these logs would be subject to the security controls of the regime. We are wondering if keeping the full log detail of these requests holds any value to the regime, we say this because at the point of capture the detail in this log cannot be tied back to a particular customer as the only thing that is present is a short lived access token which won’t have relevance to the customer until exchanged in the DH’s IDP.

We understand these records are valuable in assisting construct counts for the reports and metrics endpoints but is the whole record mandatory or could we just keep a collection of the aggregated count information?

There is also some concern from security teams over the nature of the data in these logs which may indicate attack information or potential threat vectors and this information should only be kept for a period of time (12-18 months) and then purged from the records.

Please note: regardless of the WAF records decision, all refusals subsequent to WAF (within the ANZ domain) will be recorded.

Given the concerns around the security and the real value of these logs we feel this requirement may need to be reviewed/revisited or simply clarified if we have understood this incorrectly.

• Report on the ‘number of consumer data requests received from accredited persons on behalf of eligible CDR consumers’.

A reference to 'requests you received' includes all requests you received, regardless of whether the request was successful or not.

• Report on the ‘number of times you have refused to disclose CDR data’.

A reference to a 'refusal' to disclose CDR data is intended to cover all refusals to disclose CDR data. For the avoidance of doubt, circumstances where the data holder must report on the number of refusals to disclose CDR data include for technical reasons, refusals where it is considered necessary to prevent physical or financial harm or abuse, and refusals where the data holder has reasonable grounds to believe disclosure of some or all of the requested CDR data would adversely impact the security, integrity or stability to the Register of Accredited Persons or the data holder's ICT systems, and any other reason the data holder has not disclosed CDR data in response to a request.

Back in March 2020, ACCC released some guidance for participants to gain an exemption under s56GD. We noticed there hadn't been any additions to the register for some time. Is this an indication no further exemptions have been granted or that there is a backlog of exemptions to be published?

As an example, have any Data Holders been given exemptions related to their Product Reference Data API?