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 22, 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
Workshop - Energy Data Language for the Energy Sector Registration Link
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?

Answers still pending

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:

# Question Answer
#1

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 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
    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
 Link:
#4

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?

 Link: Coming soon

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