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

We have previously submitted the following questions for Data Holder Work Group 04/06/2020, as well as Data Holder Work Group 18/06/2020:
1. Further to the item above, we are of the view that traffic throttled due to exceeding non-functional requirements does not constitute a refusal to disclose and would not be in scope for record keeping an reporting as a refusal to disclose. Throttled traffic is a reported measurement in the Get Metrics API. Could you please publish the answer in the minutes?
2. We are of the view that each refused API call constitutes a separate refusal to disclose event for the purposes of record keeping and reporting. Could you please publish the answer in the minutes?

When can we expect a response in writing, as no response has been provided to either of these items in the meeting minutes?

Answer to Question 1 - Posted on the 16th of July 2020 under Actions : "Throttled traffic due to exceeding the non-functional requirements would constitute a refusal to disclose for the purposes of reporting under rule 9.4. It would also be considered a rejection in the rejection count metrics, noting that this applies to authenticated APIs (not public APIs)."

Question 2 - was posted on the 18th of June 2020 Meeting Minutes: "From a technical perspective the reporting of a refusal to disclose means that the request is received and is valud but the data holder (for one of a variety of reasons) refuses to provide the requested data.

During a period of system instability or outage the first part of this technical definition may not be met. The initial request may not be received or may not be able to be assessed for validity. In these situations a refusal to disclose should not be recorded. This would, however, be recorded as a period of unavailability under the NFRs if the outage was unplanned. If the outage was planned and communicated with enough advance notice according to the standards then the calls would not need to recorded either as a period of unavailability or as a refusal to disclose."

If a consumer (ADR) calls the Get Transaction Details endpoint even though the isDetailAvailble was false when that particular transaction was returned with the Get Transactions for Account endpoint, should the data holder return:

HTTPS Status 200 with the following extended data block:

or

should the data holder return 4xx. Likely to be 404 at the moment based on proposals.

In terms of user experience, the 200 response would seem better. But we are unsure whether that we be considered compliant.

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

I have the following question about Scheduled Payments: In the case of multiparty scheduled payments we are looking to understand how to map the top level elements of nickname and payeeReference.

In our case we allow the customer to set a nickname and payeereference at the payee level and do not capture these fields at the top level. Our assumption is that we will leave both blank as anything else is not an accurate representation of the data entered by the customer. Can you confirm this would be DSBs recommendation or should we be using another approach?

If this is a case then we suggest that a facility is added to the standards to capture this data at the paymentSet level?

There was a question around the Occupation code/Industry code fields in the CommonPerson and CommonOrganisation schemas, that I asked Mark in last week’s WG call and the below are few more follow-up questions on the same subject. Even though the questions have referenced Occupation code in them, the same questions apply to both Occupation and Industry codes.

1. If we have occupation codes for some customers, but don’t for some other customers, can we pass a null value for the customers where the occupation code does not exist in our core systems?
2. If we have occupation codes which are not as per ANZCO standard occupation classification for some customers, as a DH, how are we expected to respond to this data request? Are we expected to somehow correct the data to align it to the ANZCO standard code and then share the data? Or can we pass a null value? Or can we send whatever string we have stored in our core systems? What is ACCC/Data61 expectation on this?
3. If we have the actual occupations listed within our core systems but not the occupation codes for some customers, as a DH, are we expected to map the occupation that we have stored in the system to ANZCO standards for Occupation code and then share the data? What is ACCC/Data61 expectation on this? Also, there will be cases where the occupation does not directly match a code within the ANZCO standard. How are DHs expected to handle this scenario?

Under the Privacy Safeguard 12, one of the corrective actions to be taken is to include a “qualifying statement” with the CDR data. The privacy safeguard guidelines state:

“CDR Rule 7.15 requires an entity that receives a correction request to either:
• correct the CDR data, or
• both:
• include a qualifying statement with the data to ensure that, having regard to the purpose for which it is held, the data is accurate, up to date, complete and not misleading, and
• where practicable, attach an electronic link to a digital record of the data in such a way that the statement will be apparent to any users of the data.”



What is the mechanism by which a data holder can correct data to the data recipients?

If by API:
• Is there any mechanism in the standards to describe such a correction, and, contain the electronic link?
• If the sharing arrangement was one-off, how should the correction be sent to the Recipient?
• If the sharing arrangement is recurring, should the corrected record be included in the next bulk refresh/access.
• How does the recipient know that the record is a correction?


If by an out of bands means:
• What means are acceptable (letter, email, other)?
• How does the data holder gain access to this mean (eg email address)? Is it in the registry?
• How could corrected personal data be sent safely by an out of bands means?