Skip to content

ACCC & DSB Data Holder Working Group Agenda & Meeting Notes (23rd of July 2020)

Jump to bottom
CDR API Stream edited this page Jul 23, 2020 · 7 revisions

ACCC & DSB Data Holder Working Group Agenda & Meeting Notes (23rd of July 2020)

When: Weekly every Thursday at 3pm-4.30pm AEST
Location: WebEx, quick dial +61262464433,785383900%23%23
Meeting Details:

Desktop or Mobile Devices https://csiro.webex.com/csiro/j.php?MTID=m7c39ee9db5e5892ab35cd0bd7bbf94ce
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

Agenda

  1. Introductions
  2. Outstanding actions
  3. CDR Stream updates
  4. Q&A
  5. Any other business

Meeting notes

Introductions

  • 5 min will be allowed for participants to join the call.

Actions

Type Topic Update
Questions and Answers Please submit all new pre-submited questions to [email protected] New process to triage, assign, track and respond to questions raised by the Community. Questions and Answers can be now be found here: CDR Support
Maintenance Banking Maintenance Iteration 04

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

Maintenance Banking Maintenance Iteration 04 Link to Summary
Decision Proposal - Energy Decision Proposal 113 - Customer Data Payloads Decision Proposal 113
Decision Proposal - All Decision Proposal 120 - CDR Error Codes for Enhanced Error Handling Decision Proposal 120
Standards Version 1.4.0 Proposed Changes Board of changes is located here
Follow-up
    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."

CDR Stream Updates

Provides a weekly update on the activities of each of the CDR streams and their workplaces

  • ACCC Rules
  • ACCC CDR Register (Technical)
  • DSB CX Standards
  • DSB Technical Standards - Energy & Banking

Presentation

  • No presentation this week

Q&A

Questions will be received by the community via WebEx chat before the questions are opened to the floor. Participants can pre-submit questions to the DSB mailing box.

Currently received pre-submitted questions:

# Ticket # Question Answer
#1 Ticket #41

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:

extendedData: {
service: {}
}

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.

 Answer can be found here: CDR Support Article
#2 Ticket #42 Could you please let me know if the screens which are required to be produced for a Data Holder (the Authorisation end points), need to support both websites and mobile devices? Answer can be found here: CDR Support Article
#3 Ticket #43
    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
 Currently the URLs for the production endpoints are distributed during on-boarding. As for publishing this in the public domain, we are still discussing this internally and aim to get back to you by next week.
#4 Ticket #44

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.

scheduledPayments.nickname
scheduledPayment. 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?

 -
#5 Ticket #47

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?

Would really appreciate if the above can be clarified.
#5 Ticket #48

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?
 -

Notes

  • TBA

Question and answers

# Question Answer/ Action
#1 - -
#1 - -

Other business

  • TBA

Appendices

  • TBA

Next Steps

  • TBA

Getting Started

Meetings

Maintenance Iterations

CDR Implementation Call

Clone this wiki locally